UC2

Building self-consumption employing Virtual Energy Storage optimisation

1. Description of the Use Case

1.1. Name of the Use Case

IDArea /Domain(s)/Zone(s)Name of the Use Case
1Energy Community/DER, Consumption/Building, Operation, Market,UC2

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 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.

1.5. Key Performance Indicatiors (KPI)

IDNameDescriptionReference to mentioned use case objectives

1.6. Use case conditions

Assumptions
UC2
Prerequisites

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

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

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/ Facility ManagerStakeholderEnd-user that consumes energy but also produces energy
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

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
S01Self-Consumption maximizationNoneSelf-Consumption maximization

Notes

4.2. Steps – Scenarios

Scenario Name:
Self-Consumption maximization
Step No.Event.Name of Process/ ActivityDescription of Process/ Activity.ServiceInformation Producer (Actor)Information Receiver (Actor)Information ExchangedRequirements, R-ID
St01RequestInitiate optimizationUser requests via the UI the optimal scheduling for the apartment/ buildingModule to ModuleCitizen Apps
St02RequestRequest optimizationRequest is passed on to the on-Demand flexibility management engineModule to ModuleCitizen Apps
St03RequestGet 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
St04RequestGet Building/ Asset informationRequest the thermal modelling and characteristics of the apartment/ building zones and the relevant equipmentModule to Module
St05ComputationRun self-consumption optimizationRun optimization algorithm based on retrieved constraintsInternal
St06ResponsePresent informationPresent the optimal schedule to the requesting actorModule to ModuleCitizen Apps
St07RequestApply schedule for building assetsRequest the optimal operation of all building assets includedModule to Module
St08ResponseMonitor EventProvide information of metered dataModule to Module
St09ResponseMonitor EventProvide information of scheduled operationModule to ModuleCitizen Apps
St10ResponseMonitor EventVisualize results of operation at community levelExternalCitizen Apps

5. Information Exchanged

Information exchanged IDName of InformationDescription of Information ExchangedRequirement

6. Requirements (optional)

Category IdentifierNameDescriptionmRID
Req_IDReq_Name‘Building self-consumption employing Virtual Energy Storage optimisation’
IdentifierNameDescriptionmRID
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 optimization is requestedInfrastructure for monitoring and control in place. Software modules for optimization
INF 03Building/asset IDThe 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 timeBIML, Citizen Digital Twin Module
INF 04Timeseries of Power consumptionInformation 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 05Comparison between scheduled and actual operationA timeseries object highlighting the requested vs actual consumption from assets at each timestepSoftware modules for optimization
INF 06Timeseries of control actionsControl actions for each specific resource in order to follow the requested consumption scheduleUI

7. Common Terms and Definitions

8. Custom Information (optional)

KeyValueRefers to Section