UC2
Building self-consumption employing Virtual Energy Storage optimisation
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 | Energy Community/DER, Consumption/Building, Operation, Market, | UC2 |
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 an optimization framework for maximizing the use of self-generated energy, having a building asset as its focus. Relevant components from the ACCEPT architecture are: Building Digital Twin, On-Demand Flexibility Management |
Objective(s) | 1. Reduce residential energy bills through increase self-consumption of renewable energy |
2. Share of total consumption is covered by local green energy. | |
Related business case(s) | UC02 is generalized by UC13 (building to community level self-consumption) |
UC02 includes UC01 (requires the monitoring and metering functionality prescribed in that UC) | |
1.4. Narrative of Use Case
Short description
This Use Case (UC) deals with the optimal scheduling of operation for HVAC resources at building/apartment level, combined with the heat energy storage capabilities offered by the building envelope or hot water storage tanks, so as to increase the consumption of self-generated electricity via renewable resources. Consequently, the UC’s objective is also to minimize the dependence of a single consumer from the grid, by making him/her self-sufficient.
Complete description
The concept of Virtual Energy Storage (VES) is tightly connected to the demand-side management on intra-building thermal loads. The building envelope and available hot water storage tanks are examined as thermal storage devices, whilst the building also serves as the energy sink. Local Power-to-Heat units operate as energy sources, and the heat generated can be either utilized directly to satisfy the occupants’ comfort needs or stored to be utilized in a later moment in time.
The significance of such functionality increases considerably when the building is equipped with Renewable Energy Resources (RES), such as Photovoltaic (PV) panels. This free resource of energy, due to its intermittent nature, does not commonly match the end-user demand and thus cannot always be readily consumed. One solution to this is energy trading to/from the grid, this though poses issues of energy balancing and management to the grid operator. Self-consumption is another way to minimize the loss of freely produced renewable energy. In this setting, the combined effect of being able to store thermal energy and modify to some extent the thermal demand leads to the best intra-building utilization of self-production.
VES is an inherent part of the building Digital Twin model and is also tightly dependent on input from the Citizen Twin module. It combines the thermal properties of the building envelope and hot water storage with the usage patterns of its occupants and their comfort perception, so as to perform a short or mid-term optimization on use of resources that maximize the use of any renewable energy generated in the premises.
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 |
Generic |
Nature of the use cases |
Technical |
Further keywords for classification |
Virtual Thermal Energy Storage, Flexibility, Model Predictive Control |
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/ Facility Manager | Stakeholder | End-user that consumes energy but also produces energy | |
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 | |
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 | Self-Consumption maximization | None | | Self-Consumption maximization | | |
Notes
4.2. Steps – Scenarios
Scenario Name: |
---|
Self-Consumption maximization |
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 | Initiate optimization | User requests via the UI the optimal scheduling for the apartment/ building | Module to Module | | Citizen Apps | | |
St02 | Request | Request optimization | Request is passed on to the on-Demand flexibility management engine | Module to Module | Citizen Apps | | | |
St03 | 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 | | | | |
St04 | Request | Get Building/ Asset information | Request the thermal modelling and characteristics of the apartment/ building zones and the relevant equipment | Module to Module | | | | |
St05 | Computation | Run self-consumption optimization | Run optimization algorithm based on retrieved constraints | Internal | | | | |
St06 | Response | Present information | Present the optimal schedule to the requesting actor | Module to Module | | Citizen Apps | | |
St07 | Request | Apply schedule for building assets | Request the optimal operation of all building assets included | Module to Module | | | | |
St08 | Response | Monitor Event | Provide information of metered data | Module to Module | | | | |
St09 | Response | Monitor Event | Provide information of scheduled operation | Module to Module | | Citizen Apps | | |
St10 | Response | Monitor Event | Visualize results of operation at community level | External | Citizen Apps | | | |
Information exchanged ID | Name of Information | Description of Information Exchanged | Requirement |
---|
6. Requirements (optional)
Category Identifier | Name | Description | mRID |
---|
Req_ID | Req_Name | ‘Building self-consumption employing Virtual Energy Storage optimisation’ | |
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 optimization is requested | Infrastructure for monitoring and control in place. Software modules for optimization |
INF 03 | Building/asset ID | The information is required for the correct communication between the modules. The key actor may have the ability to select which assets/zones should be considered each time | BIML, Citizen Digital Twin Module |
INF 04 | Timeseries of Power consumption | Information exchanged between the different modules and presenting the results of the self-consumption optimization. May be a timeseries of consumption per asset or aggregated per building. | BIML, Citizen Digital Twin Module |
INF 05 | Comparison between scheduled and actual operation | A timeseries object highlighting the requested vs actual consumption from assets at each timestep | Software modules for optimization |
INF 06 | Timeseries of control actions | Control actions for each specific resource in order to follow the requested consumption schedule | UI |
7. Common Terms and Definitions
Key | Value | Refers to Section |
---|