Consumer demand-side flexibility forecasting and optimisation taking into account comfort boundaries, activity patterns and possible requirements

1. Description of the Use Case

1.1. Name of the Use Case

IDArea /Domain(s)/Zone(s)Name of the Use Case
1Building/DER, Consumer Premises/Station, Operation, Enterprise,UC3

1.2. Version Management

Version No.DateName of author(s)ChangesApproval status
0.32021-07-06T00:00:00Hypertech, RINA-C,Final proposal of use caseFinal

1.3. Scope and Objectives of Use Case

ScopeThe scope of this UC is to establish the pipeline from monitoring and metering of building assets, to occupant and device modelling, flexibility forecasting and finally application of control actions to the flexible resources. Relevant components of the ACCEPT system are: Building Digital Twin, Building Citizen Twin, On-Demand Flexibility Management (additionally: BIML, citizen apps, community portfolio management)
Objective(s)1. Provide intra-day and day-ahead forecasts of flexibility (possibility for upwards of downwards regulation of a building/asset consumption), based on the energy resources installed in the premises.
2. Translate flexibility requests to the building into scheduling operations for the electricity resources in the building/apartment/thermal zones.
Related business case(s)UC03 includes UC01 (requires the monitoring and metering functionality prescribed in that UC)
UC03 is included in UCs 07, 08 and 13 (UC07 and UC08 and UC13 use functionality from UC03)

1.4. Narrative of Use Case

Short description

The Use Case (UC) captures one of the core functionalities to be provided by the on-demand Flexibility Management component of the ACCEPT solution. In order for consumers to participate into energy markets, it is necessary to be able to provide forecasts of their baseline demand, as well as any upwards or downwards regulations of this baseline that can be provided, at specific future time intervals. The process depends on the modelling of the characteristics of the building, combined with the installed heating/cooling, resources DHW and other small electrical resources, as well as the modelling of the occupants’ behaviour. Both of the above are translated into mathematical constraints that allow the execution of a number of numerical optimizations, that yield the quantitative forecasts in terms of baseline and flexibility offered by the asset.

Complete description

Aggregators and energy communities are anticipated to contribute significantly to the coming years in the opening of energy markets to demand flexibility. The way to do so is through aggregation of flexibility from individual consumers or district wide assets. This UC concentrated mainly on the first part and aims to enable the participation of consumers at building level to such markets. One of the first and necessary steps towards implementing this business scenario, is the forecasting of demand flexibility potential for each asset. To achieve this, individual consumer data, such as occupancy, device operational statuses, environmental conditions, metering and price data, along with occupants’ comfort preferences need to be monitored. Upon establishing this information management layer, the algorithms implemented in the citizen twin module process the data to identify the comfort and activity preferences of the occupants. In parallel, the building digital twin module must model the electricity resources and thermal characteristics of the building. These models are then fed to the flexibility demand management component, which also takes as input forecasts of the environmental conditions and is able to estimate the future requirements and flexibility, in terms of energy, of each device/apartment/building. The computed flexibility forecasts can then be sent to the community flexibility management layer for realizing the participation in the energy market.

1.5. Key Performance Indicatiors (KPI)

IDNameDescriptionReference to mentioned use case objectives

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
Further keywords for classification
Flexibility estimation/forecasting, demand side management, demand response

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
ProsumerStakeholderEnd-user that consumes and may produce energy from local RES
Aggregator/Energy CommunityStakeholderActor that trades flexibility in the energy market
Building assetsDeviceRequired infrastructure
BIML - Information/Communication LayerSystemACCEPT system for enabling building data monitoring and control
On Demand Flexibility ManagementSystemACCEPT collection of modules responsible for the management of building assets
Citizen AppsSystemACCEPT UI for interacting with the end user
Energy community toolsSystemACCEPT system responsible for community level optimization

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
S01Building Demand Flexibility EstimationNoneBuilding Demand Flexibility Estimation


4.2. Steps – Scenarios

Scenario Name:
Building Demand Flexibility Estimation
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
St01RequestRequest flexibility from a buildingUser or system requests the available flexibility of a buildingExternal
St02RequestGet end user activity/comfort constraintsRequest the information (comfort/occupancy/activity) of the occupants in order to define the required constraints for the energy optimizationModule to Module
St03RequestGet Building/ Asset informationRequest the models and characteristics of the building zones and the relevant equipmentModule to Module
St04ComputationEstimate flexibilityRun flexibility estimation algorithm based on retrieved constraintsInternal
St05ResponseReturn flexibility forecastReturn the flexibility forecast of devices to the energy community tool as well as the citizen appModule to Module
St06ResponsePresent informationPresent the optimal schedule to the requesting actorExternalProsumer

5. Information Exchanged

Information exchanged IDName of InformationDescription of Information ExchangedRequirement

6. Requirements (optional)

Category IdentifierNameDescriptionmRID
Req_IDReq_Name‘Consumer demand-side flexibility forecasting and optimisation taking into account comfort boundaries, activity patterns and possible requirements’
INF 01Request notificationNoneUI, Infrastructure for monitoring and control in place. Software modules for optimization
INF 02Datetime, horizon and timestepThe information is required in order to establish the time period for which the flexibility estimation is requestedBIML, Citizen Digital Twin Module
INF 03Building/Asset IDThe information is required for the correct communication between the modules. The energy community may have the ability to select which assets (buildings/apartments) should be considered each timeBIML, Building Digital Twin Module
INF 04Timeseries of baseline and flexibilitySet of timeseries showing the baseline consumption forecast and the available upwards and downwards flexibilitySoftware modules for optimization

7. Common Terms and Definitions

8. Custom Information (optional)

KeyValueRefers to Section