UC3
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
| ID | Area /Domain(s)/Zone(s) | Name of the Use Case |
|---|
| 1 | Building/DER, Consumer Premises/Station, Operation, Enterprise, | UC3 |
1.2. Version Management
| Version No. | Date | Name of author(s) | Changes | Approval status |
|---|
| 0.3 | 2021-07-06T00:00:00 | Hypertech, RINA-C, | Final proposal of use case | Final |
1.3. Scope and Objectives of Use Case
| |
|---|
| Scope | The 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.
| ID | Name | Description | Reference to mentioned use case objectives |
|---|
1.6. Use case conditions
| Relation to other use cases |
|---|
|
| Level of depth |
| Prioritisation |
| High |
| Generic, regional or national relation |
| Regional |
| Nature of the use cases |
|
| Further keywords for classification |
| Flexibility estimation/forecasting, demand side management, demand response |
2. Diagrams of Use Case
3. Technical Details
3.1. Actors
| Actor Name | Actor Type | Actor Description | Further information specific to this Use Case |
|---|
| Prosumer | Stakeholder | End-user that consumes and may produce energy from local RES | |
| Aggregator/Energy Community | Stakeholder | Actor that trades flexibility in the energy market | |
| Building assets | Device | Required infrastructure | |
| BIML - Information/Communication Layer | System | ACCEPT system for enabling building data monitoring and control | |
| On Demand Flexibility Management | System | ACCEPT collection of modules responsible for the management of building assets | |
| Citizen Apps | System | ACCEPT UI for interacting with the end user | |
| Energy community tools | System | ACCEPT system responsible for community level optimization | |
3.2. References
| No. | References Type | Reference | Status | Impact on Use Case | Organistaor / Organisation | Link |
|---|
4. Step by Step Analysis of Use Case
4.1. Overview of Scenarios
| No. | Scenario Name | Scenario Description | Primary Actor | Triggering Event | Pre-Condition | Post-Condition |
|---|
| S01 | Building Demand Flexibility Estimation | None | | Building Demand Flexibility Estimation | | |
Notes
4.2. Steps – Scenarios
| Scenario Name: |
|---|
| Building Demand Flexibility Estimation |
| Step No. | Event. | Name of Process/ Activity | Description of Process/ Activity. | Service | Information Producer (Actor) | Information Receiver (Actor) | Information Exchanged | Requirements, R-ID |
|---|
| St01 | Request | Request flexibility from a building | User or system requests the available flexibility of a building | External | | | | |
| St02 | Request | Get end user activity/comfort constraints | Request the information (comfort/occupancy/activity) of the occupants in order to define the required constraints for the energy optimization | Module to Module | | | | |
| St03 | Request | Get Building/ Asset information | Request the models and characteristics of the building zones and the relevant equipment | Module to Module | | | | |
| St04 | Computation | Estimate flexibility | Run flexibility estimation algorithm based on retrieved constraints | Internal | | | | |
| St05 | Response | Return flexibility forecast | Return the flexibility forecast of devices to the energy community tool as well as the citizen app | Module to Module | | | | |
| St06 | Response | Present information | Present the optimal schedule to the requesting actor | External | | Prosumer | | |
| Information exchanged ID | Name of Information | Description of Information Exchanged | Requirement |
|---|
6. Requirements (optional)
| Category Identifier | Name | Description | mRID |
|---|
| Req_ID | Req_Name | ‘Consumer demand-side flexibility forecasting and optimisation taking into account comfort boundaries, activity patterns and possible requirements’ | |
| Identifier | Name | Description | mRID |
|---|
| INF 01 | Request notification | None | UI, Infrastructure for monitoring and control in place. Software modules for optimization |
| INF 02 | Datetime, horizon and timestep | The information is required in order to establish the time period for which the flexibility estimation is requested | BIML, Citizen Digital Twin Module |
| INF 03 | Building/Asset ID | The 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 time | BIML, Building Digital Twin Module |
| INF 04 | Timeseries of baseline and flexibility | Set of timeseries showing the baseline consumption forecast and the available upwards and downwards flexibility | Software modules for optimization |
7. Common Terms and Definitions
| Key | Value | Refers to Section |
|---|