Participation in explicit Demand Response schemes

1. Description of the Use Case

1.1. Name of the Use Case

IDArea /Domain(s)/Zone(s)Name of the Use Case
1Component Layer, Communication Layer/ DER, Customer Premises/ Building, Operation,UC8

1.2. Version Management

Version No.DateName of author(s)ChangesApproval status
12021-04-27T00:00:00CERTH,First proposal of use caseDraft

1.3. Scope and Objectives of Use Case

ScopeEstablish the most appropriate sequence of actions and collaboration among the available tools, in order at both end-user level and Energy Community (LEC) Level to participate in an explicit DR event, based on flexibility potential
Objective(s)1. Provide optimal solutions at LEC Level, according to the agreed role, i.e. Aggregator, Retailer, ESCO, and based on inputs such as demand/generation flexibility, forecast etc.
2. Provide optimal solutions at end-user level, according to the agreed role of LEC, i.e. Aggregator, Retailer, ESCO, and based on inputs such as demand/generation flexibility, forecast of the particular end-user, in order for the latter to accept or reject any DR events that are offered to him/her.
Related business case(s)UC01 “Monitoring and Visualization of Metering & Sensor Energy Data in community buildings”
UC03 “Consumer demand-side flexibility forecasting”
UC04 “Demand elasticity profiling-forecasting-aggregation”
UC05 “Intra-Day district Level DER flexibility management for community self-balancing”
UC06 “Day-ahead smart charging flexibility quantification via EV usage pattern profiling and forecasting”
UC12 “Retailer day-ahead optimal pricing configuration for aggregated portfolio balancing”

1.4. Narrative of Use Case

Short description

Provide DR events at both LEC Level and end-user level, in order to provide appropriate services to the electricity market

Complete description

Regardless of their role, that is ESCO, Retailer or Aggregator, LECs can provide valuable services to both the electricity market and the local DSO, if so requested. Utilizing the appropriate assets available at the moment, their potential and forecast, the decision support system can provide the available option to the Local Energy community manager, and he/she can decide upon the appropriate course of action. This decision will trigger to send the appropriate DR signals to the assets available at that time. These assets can range from a local PV plant to an appliance connected to the grid. The availability of such assets, along with their rated power, current power, flexibility potential and forecast for that time period should be made aware to the LEC manager, in order to assign the appropriate DR signals to the appropriate assets. The availability of those assets is retrieved via notifying the end-users accordingly and having retrieved their informed consent. To that end an appropriate mathematical formulation of the optimization problem at hand will be shaped and the most suitable optimization techniques will be employed, ranging from mixed-integer linear programming to metaheuristics and robust optimization, depending on the circumstances.

1.5. Key Performance Indicatiors (KPI)

IDNameDescriptionReference to mentioned use case objectives
SR-01Number of data security incidentsNoneNone,

1.6. Use case conditions


1.7. Further information to the use case for classification/mapping

Relation to other use cases
Level of depth
Generic, regional or national relation
Nature of the use cases
Prosumer/End-User and Local Energy Community in all its roles (ESCO, Retailer, Aggregator)
Further keywords for classification
Explicit Demand Response, Aggregator, DER, prosumer, end-user

1.8. General remarks

General remarks

2. Diagrams of Use Case

3. Technical Details

3.1. Actors

Actor NameActor TypeActor DescriptionFurther information specific to this Use Case
Prosumer/ConsumerStakeholderThe end user that consumes or produces also in the case of the prosumer
Building/district ManagerStakeholderPerson who manages property or district assets, usually not the end user of electricity but is responsible for billing and maintenance.
LEC manager (Aggregator, Retailer, ESCO)StakeholderPerson who manages the whole LEC ecosystem
Aggregator, DSOStakeholderExternal Actor to the LEC strict ecosystem

3.2. References

No.References TypeReferenceStatusImpact on Use CaseOrganistaor / OrganisationLink

4. Step by Step Analysis of Use Case

4.1. Overview of Scenarios

No.Scenario NameScenario DescriptionPrimary ActorTriggering EventPre-ConditionPost-Condition
S01Receive DR requestNoneReceive DR request
S02Provide DRNoneProvide DR


4.2. Steps – Scenarios

Scenario Name:
Receive DR request
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
Scenario Name:
Provide DR
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID

5. Information Exchanged

Information exchanged IDName of InformationDescription of Information ExchangedRequirement

6. Requirements (optional)

Category IdentifierNameDescriptionmRID
Req_IDReq_Name‘Participation in explicit Demand Response schemes’
INF01No. DR Events
(integer)Number of DR events requested for the upcoming periodINF01
INF02DR duration
(float)The duration of the DR events requested for the upcoming periodINF02
INF03Energy increase/decrease
(float)The amount of energy to be in-/de-creased during the DR eventINF03
INF04End user preferences
(string)Any specific preferences the end user may pertaining the DR events, such as, preferred period for participating in a DR event, preferred appliances for engaging in a DR event (e.g. washing machine, clothe dryer etc.), his/her availability for participating in DR events for the upcoming period, etc.INF04
INF05End user energy consumption profile
(timeseries)Forecast for the end user energy consumption baseline and upper/lower boundaries.INF05
INF06End user DR engagement profile (float)A metric of how actively or non-actively engaged is the end user regarding DR events.INF06
INF07timestampA time instant, which the DR event is to start/end.INF07
INF08DR control signalAn appropriate DR signal to be sent to a particular device, in order to in-/de-creaseINF08

7. Common Terms and Definitions

8. Custom Information (optional)

KeyValueRefers to Section