Post on 26-Sep-2020
Sensible – DELIVERABLE
Use Cases and Requirements
This project has received funding from the European Union's Horizon 2020 research and innovation programme under Grant Agreement No. 645963.
Deliverable number: D1.3
Due date: 31.08.2015
Nature1: R
Dissemination Level1: PU
Work Package: WP1
Lead Beneficiary: 12 – USE
Contributing Beneficiaries: Siemens, Adevice, Armines, EDP, Empower, GPTech, INDRA, INESC, MOZES, Siemens SA, THN, UoN, USE
Editor(s): Clara Luján and Joaquín Alvarez
Reviewer(s): Henriette Cornet, K&S
1 Nature: R = Report, P = Prototype, D = Demonstrator, O = Other Dissemination level PU = Public
PP = Restricted to other programme participants (including the Commission Services) RE = Restricted to a group specified by the consortium (including the Commission Services) CO = Confidential, only for members of the consortium (including the Commission Services) Restraint UE = Classified with the classification level "Restraint UE" according to Commission Deci-sion 2001/844 and amendments Confidential UE = Classified with the mention of the classification level "Confidential UE" according to Commission Decision 2001/844 and amendments Secret UE = Classified with the mention of the classification level "Secret UE" according to Commis-sion Decision 2001/844 and amendments
DOCUMENT HISTORY
D1.3_SENSIBLE_Deliverable_final
Version Date Description
0.0 26.02.2015 Template by USE
0.1 21.04.2015 New version of the template by USE
0.2 21.06.2015 First compilation of use cases by USE
0.3 06.07.2015 First draft by USE (Contributions of all partners)
0.4 07.07.2015 Updated with last version of INESC/IN-DRA use cases
0.5 09.07.2015 Changes in requirements and updated GPTECH use cases
0.6 28.07.2015 Updates in every use case.
Section 5 and use case 12 removed
0.7 01.08.2015 Complete document for review (small changes to be done).
0.8 17.08.2015 Complete document for review
1.0 19.08.2015 Review done by H. Cornet (K&S)
1.1 24.08.2015 Review done by Clara Lujan (USE)
1.2 27.08.2015 Review by USE and compilation of final contributions from all partners
1.3 01.09.2015 Review done by the coordinator
1.4 02.09.2015 Adjustments by S.Kadlubek (K&S)
1.5 03.09.2015 Adjustments by Clara Lujan (USE)
1.6 11.09.2015 Approved by GA, final document
TABLE OF CONTENT
D1.3_SENSIBLE_Deliverable_final
1 Introduction 5
1.1 Purpose and Scope of the Deliverable ......................................................... 5
1.2 Participation and responsibilities .................................................................. 8
1.3 Overview of the document ........................................................................... 9
1.4 Acronyms .................................................................................................. 11
2 Use Cases 13
2.1 Use Case 1: Managing building energy flexibility ....................................... 13
2.2 Use Case 2: Flexibility and DSM in the market participation ...................... 22
2.3 Use Case 3: Increased percentage of self-consumption ............................ 38
2.4 Use Case 4: Optimized energy procurement ............................................. 46
2.5 Use Case 5: Microgrid PV Management .................................................... 54
2.6 Use Case 6: Enabling an independent energy community ......................... 64
2.7 Use Case 7: Microgrid energy market ........................................................ 83
2.8 Use Case 8: Optimizing the MV Distribution Network Operation using available storage resources. ............................................................................... 93
2.9 Use Case 9: Optimizing the operation of storage devices in the LV distribution network .......................................................................................... 109
2.10 Use Case 10: Islanding Operation of Low Voltage Networks ................... 119
2.11 Use Case 11: Microgrid Emergency Balance Tool ................................... 126
3 Requirements 136
3.1 Functional Requirements ......................................................................... 136
3.2 Non-functional Requirements .................................................................. 143
EXECUTIVE SUMMARY
D1.3_SENSIBLE_Deliverable_final 4/154
Executive Summary
The SENSIBLE project aims the energy storage sustainability in three different domains: Building/End-Customer, Microgrid/Community and Grid operation each of them offering different business opportunities for energy storage. Regarding these domains and busi-ness models several use cases have been proposed.
This document includes the definition of the use cases and their corresponding Func-tional and Non-Functional Requirements to be implemented in the SENSIBLE project.
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 5/154
1 Introduction
1.1 Purpose and Scope of the Deliverable
This document defines the use cases (UC) that will be addressed in the SENSIBLE pro-ject and the corresponding functional and no functional requirements of the SENSIBLE system in its implementation for the demonstrators located in Nuremberg, Évora and Nottingham. The activities developed in task 1.3 and the content of this document has served as input for tasks 1.2 and 1.4 and, consequently, to deliverables D1.2 Analysis of ICT Storage Integration Architectures and D1.4 Implementation plan for the demonstra-tors.
The SENSIBLE project aims the energy storage sustainability in three different domains: Building/End-Customer, Microgrid/Community and Grid operation each of them offering different business opportunities for energy storage. Regarding, these domains and busi-ness models, several use cases have been proposed and they are summarized in the table below:
Table 1 Proposed use cases by domain
Storage Domain Business Key Features UC nº Name of the Use Case
Building /
End Customer
• Off-grid self-consumption ca-
pacity
• Maximizing consumption of lo-
cally generated power
• Flexibility capacity for suppliers
(DSM)
• No direct involvement of Build-
ing and End-customers in open
energy markets
• Real Markets (i.e. day-ahead,
intraday) accessible to Suppli-
ers
1 Managing building energy
flexibility
2 Flexibility and DSM in the the market participation
3 Increased percentage of self-consumption
4 Optimized energy procurement
Microgrid /
Community
• Self-consumption as top priority
• Grid supply used as backup (Is-
landing operation mode most of
times)
5 Microgrid PV Management
6 Enabling an independent energy community
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 6/154
• Simulated community auto-
mated market by means of
peer-to-peer (P2P) energy trad-
ing transactions
7 Microgrid Energy Market
Grid Operation
• Storage used for MV and LV
operation optimization
• Integration of new markets (an-
cillary services)
• Power Quality and Continuity of
Service
8 Optimizing the MV Distribution
Network
9
Optimizing the operation of
storage devices in the LV net-
work
10
Islanding Operation of Low
Voltage Networks
11 Microgrid Emergency Balance
Tool
Additionally, some of the previous use cases perform functionalities aplicable in more than one of the targeted domains, therefore, certain interactions can be defined (Table 2, Figure 1).
Table 2 Domain interaction among use cases
Domain Interactions UC nº Name of the Use Case
Building / End Customer & Grid Operation
2 Flexibility and DSM in the the market participation
Building / End Customer & Microgrid / Commu-nity
3 Increased percentage of self-consumption
Microgrid / Community & Grid Operation
11 Microgrid Emergency Balance Tool
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 7/154
Fig. 1 Use case Diagram by domain
The SENSIBLE system functionalities use cases will be demonstrated in three different locations: Nuremberg (Germany), Nottingham (UK) and Évora (Portugal). Regarding these locations, the proposed use cases can be classified as follows:
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 8/154
Fig. 2 Use case Diagram by demonstration site
1.2 Participation and responsibilities
Each of the use cases will be demonstrated in collaboration among the participants of the project. The table below summarizes the participation and responsibilities for each of the proposed user stories.
Specifically:
R – Responsible (responsibility focuses on UC deployment/running on site) O – Owner (responsibility focuses on UC analysis, dissemination and documentation of the results) ✓ – Participant (partner contributing with components)
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 9/154
Fig. 3 Matrix of participation and responsibilities
UC
nº
Sie-
mens
Ade-
vice
Ar-
mines EDP
Em-
power GPTech
IN-
DRA
IN-
ESC MOZES THN UoN USE
1 ✓ ✓ ✓ ✓ R/O
2 ✓ R/O ✓ ✓ ✓
3 ✓ ✓ ✓ ✓ R/O
4 ✓ ✓ ✓ ✓ ✓ R/O ✓ ✓
5 ✓ ✓ O ✓ ✓ R ✓
6 ✓ ✓ ✓ ✓ ✓ ✓ R/O ✓
7 ✓ ✓ O ✓ R ✓
8 ✓ ✓ R O O
9 ✓ ✓ R ✓ ✓ ✓ O
10 ✓ R ✓ ✓ O
11 ✓ ✓ R ✓ ✓ O
1.3 Overview of the document
This document is structured in 3 sections: the first one includes an overview of the struc-ture of the document, content and nomenclature used. Section 2 describes each of the proposed use cases in the SENSIBLE project. Each use case has been described fol-lowing a standard approach and detailed as follows:
1. Use case identification including: use case name, relation to demonstra-tors, domain and business features derived from it.
2. Scope and Objectives of the use case 3. Use case description 4. Use case story including UC diagram 5. Actors 6. Steps including activity, sequence diagram and triggering events if appli-
cable. 7. Information exchange (if relevant)
Actors involved in each of the use cases correspond to the components in the architec-ture included in deliverable D1.2 (use this document as reference for further description of the components/actors and functionalities).
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 10/154
Additionally and within the use cases, events have been identified as well as Functional and Non-functional Requirements (Section 3) for every step and every demonstrator site. The nomenclature used is as follows:
N_FR6: for Nuremberg_Functional Requirement_Number 6
Demonstrator Requirement
N Nuremberg FR Functional Requirement
No Nottingham NFR Non-Functional Requirement
E Évora
Those requirements’ priority has been classified according to:
• Mandatory: Requirement that is strictly necessary for the implementation of the main functionality of the system.
• Needed: Requirement that is needed to implement the complete functionality of the system.
• Useful: Requirement that is linked to an optional feature of the system but which lack of compliance does not affect to the rest of its functionality.
This classification will allow, in the case of limitations during the development phase, to prioritize those requirements that need to be implemented in order to validate the SEN-SIBLE system.
Additionally, the applicability period of the requirement has been included, specifying the phase of the design in which each requirement will be taken into account.
• Initial phase of the design: Early phase of the design of the system, no longer after the definition of UC and requirements. (Q1 2016).
• Final phase of the design: Late phase of the design of the system during the installation phase but some time before first in-site tests. (Q1 2017).
Note that the simulated scenario proposed in use case 8 will lead to requirements which inclusion in the general Évora demonstrator requirements could imply the impossibility of developing the whole system. In order to avoid those specific tables for UC8 regarding FR and NFR have been including following the nomenclature:
FR_UC8_6: for Functional Requirement_UseCase8_Number 6
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 11/154
1.4 Acronyms
AMI Advanced Metering Infrastructure
AMR Automatic Meter Readings
ASM Adevice Smart Meter
ASMsm Adevice Smart Meters modified version
BEMS Building Energy Management System
CHP Combined Heat and Power
CSS Community Support Storage
DER Distributed Energy Resources
DSE Distribution State Estimation
DMS Distribution Management System
DSM Demand Side Management
DSO Distribution System Operator
DTC Distribution Transformer Controller
EEP Electrical Energy Price
EMS Energy Management System
EMSP Energy Market Service Platform
GUF Grid Usage Factor
GUT Grid Usage Tariff
HEMS Home Energy Management System
HPC High Performance Computing
HSR High Speed Response
HV High Voltage
HVAC High Voltage Alternative Current
HW Hardware
IG Integration Gateway
LV Low Voltage
MDM Meadows Data Manager
MGI Microgrid Information
MV Medium Voltage
OLTC On-Load Tap Changer
OPF Optimal Power Flow
OTS Operator Training Simulator
P2P Peer-to-peer
PCC Point of Common Coupling
INTRODUCTION
D1.3_SENSIBLE_Deliverable_final 12/154
PQ Power Quality
PV Photovoltaic power
RT Real Time
RTP Real Time Platform
RSD Residential Storage Devices
SAF System Adjusting Factor
SCADA Supervisory Control And Data Acquisition
SOC State of Charge
STATCOM Static Synchronous Compensator
SW Software
UC Use case
VPP Virtual Power Plant
USE CASES
D1.3_SENSIBLE_Deliverable_final 13/154
2 Use Cases
2.1 Use Case 1: Managing building energy flexibility
2.1.1 Use Case identification
Table 3 Use Case Identification
Name of the Use Case
Managing Building Energy Flexibility
Link to demonstrators
Nuremberg
Domain
Building/End customer
Business Key Features
Flexibility capacity for suppliers (DSM)
Real Markets (i.e. day-ahead, intraday) accessible to Suppliers
2.1.2 Scope and Objectives of the Use Case
Table 4 Short description and main objectives
Short description In this use case, part of the internal flexibility of building infra-structure is commercialized at the tertiary balancing power mar-ket via a virtual power plant (VPP). The participation at other en-ergy markets, e.g. intraday electricity market is considered op-tionally to analyse the potential benefits that may be achieved by the building operator. The grid stabilization and possible contri-butions of the building, especially in emergencies, is optionally considered in this use case.
Main Objectives The goal of this use case is to commercialize the flexibility of the building infrastructure by participating at energy markets and to optionally show that a building can support grid stability.
USE CASES
D1.3_SENSIBLE_Deliverable_final 14/154
Relation to other Use Cases
UC2: Flexibility and DSM in the market participation
2.1.3 Use Case Description
Fluctuating renewable energy sources, like wind and solar power, increase the demand for balancing power of the grid. Flexible building devices (e.g. heat pumps, chillers, HVAC, CHP) combined with storage devices (cold storage, hot storage, building inertia, electro-chemical storage) are able to provide negative or positive balancing/regulating power, which can be commercialized.
Based on incentives for providing positive and/or negative balancing power, the corre-sponding flexibility of the building is calculated and commercialized at the corresponding energy market through a VPP, which pools/combines capabilities of possibly many build-ings. During the day of operation, the promised flexibility (i.e. positive and/or negative balancing power) is released upon requests of the VPP within at most 15 minutes (before the due time/ after the request).
2.1.4 Use Case Story
This use case presents how a Building Energy Management System (BEMS) manages building devices in a way that supports the grid by providing negative or positive balanc-ing/regulating power besides fulfilling the building demands. The building devices include generation units (e.g. CHP, PV), consumers (e.g. heat pump, chiller, HVAC) and storage devices (e.g. cold storage, hot storage, battery).
The BEMS combines forecasts (weather, building demand, balancing power demand) with models of the building devices together with information from the energy provider on energy prices (e.g. energy tariff) and incentives for providing balancing power to op-timize an operation schedule for the building infrastructure. The operation schedule is optimized for a defined time period (e.g. 24 hours).
USE CASES
D1.3_SENSIBLE_Deliverable_final 15/154
Fig. 4 Use case Diagram and involved actors – Managing building energy flexibility
2.1.5 Actors
Table 5 Actors involved
Actor name Actor Type Actor Description
Forecast service pro-
vider/module
Software The Forecast service provider estimates loads for the
coming time period (e.g. 1 day, hourly curve) to the
BEMS. Load forecasts represent the thermal power
needs (heating and cooling) expected by the building
as well as the electrical load. Furthermore, it provides
a forecast of the local PV generation and the local
USE CASES
D1.3_SENSIBLE_Deliverable_final 16/154
weather conditions (irradiation & ambient tempera-
ture). The forecast service can either be obtained from
local modules integrated to BEMS or from external
service provides (e.g. Armines).
BEMS SW/HW The BEMS represents the central control component
of the building system. The BEMS receives data from
the Forecast provider and the Energy provider. This
data is combined with models of the building devices,
which are implemented in the BEMS. Possible provi-
sion of balancing/regulating power is identified and
communicated to the Energy provider. In case of flex-
ibility demand the BEMS controls the building devices
in the required manner.
Building devices Hardware The building devices are represented by generation
units (PV, CHP, heat pump, chiller), storage devices
(cold storage, hot storage) and devices for heating
and cooling (HVAC).
Energy provider (VPP) Software
interface
The Energy provider delivers energy prices for an up-
coming time period (e.g. day-ahead) and incentives
for providing balancing power.
Real-time integration
platform
SW/HW The Real-time integration platform is an integrated
platform for real-time data acquisition and processing,
with the ability to handle large volumes of information
at low latency. It will act as a communication bridge
between BEMS, the Forecast service provider (Ar-
mines) and the Energy provider (Empower).
USE CASES
D1.3_SENSIBLE_Deliverable_final 17/154
2.1.6 Steps
Fig. 5 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 18/154
Fig. 6 Sequence Diagram
Table 6 Use case steps
Step nº Name of Process
/
Activity
Main Ac-
tor
Information Exchanged Require-
ments
(Req-ID)
1. Measuring data
from building de-
vices
BEMS The BEMS collects current data
from the building devices (stor-
age levels) as well as current
building status (indoor tempera-
ture, humidity, etc.).
--
2. Sending starting
conditions
BEMS The BEMS sends the starting
conditions of the building to the
Forecast provider.
N_FR1,
N_NFR1,
N_NFR2
3a. Sending forecasts Forecast
provider
The Forecast provider sends
weather forecasts and load fore-
casts (electrical and thermal) of
the building to the BEMS.
N_FR1,
N_FR3,
N_FR4,
N_FR5,
N_NFR1,
N_NFR2,
N_NFR5
USE CASES
D1.3_SENSIBLE_Deliverable_final 19/154
3b.
Sending energy
price data and in-
centives for bal-
ancing power
Energy
provider/
VPP
The Energy provider/VPP sends
energy price data and incentives
for providing balancing power
for a defined time period to the
BEMS.
N_FR1,
N_FR6,
N_NFR1,
N_NFR2,
NFR4,
N_NFR5,
N_NFR6,
N_NFR7
4. Calculating nomi-
nal power profile
and balancing
power profiles.
BEMS The BEMS optimizes an opera-
tion schedule based on tariff
price data and incentives for
providing balancing power for
the coming period (e.g. 24h).
The resulted nominal power pro-
file at the building’s PCC and
corresponding balancing power
profiles are send to the energy
supplier / VPP.
N_FR1,
N_FR3,
N_FR4,
N_FR5,
N_FR6,
N_NFR1,
N_NFR2,
N_NFR4,
N_NFR5,
N_NFR6,
N_NFR7
(optional)
5. Operation of the
building (i.e. online
power manage-
ment)
BEMS The BEMS monitors the gener-
ation and consumption and cor-
respondingly operates the build-
ing (i.e. optimizes the operation
mode of devices) by sending the
corresponding control signals to
the building devices or the cor-
responding control units for opti-
mal operation. Disturbances,
e.g. mismatches between the
forecasted and actual power de-
mand are compensated, as
much as possible, using the
storage devices (cold storage,
hot storage, building inertia) and
local generation.
N_FR1,
N_FR6
6. Request for bal-
ancing power
Energy
supplier/
VPP
The energy provider/ VPP
sends one or more request(s)
for balancing power to the
BEMS and monitors the reaction
USE CASES
D1.3_SENSIBLE_Deliverable_final 20/154
of the building. Requests for bal-
ancing power are released
within at most 15 minutes.
7. Sending power
bids (OPTIONAL)
BEMS Participation at other energy
markets, e.g. intraday, is refined
further / specified later.
N_FR1,
N_NFR1,
N_NFR2,
N_NFR5
8. Confirming the
power bid
(OPTIONAL)
Energy
supplier/
VPP
Participation at other energy
markets, e.g. intraday, is refined
further / specified later.
N_FR1,
N_NFR1,
N_NFR2
Table 7 Triggering Events, Pre-conditions and Assumptions
Actor/
System/
Information
Triggering
event
Pre-conditions Assumptions
BEMS Constantly The BEMS collects current meas-
urement data from the building de-
vices.
BEMS Constantly Measurement
history data from
building
The BEMS sends the required
building conditions to the Forecast
module/ service provider.
Forecast service
provider/module
Request from
the BEMS
Holding fore-
casts for
weather and the
current building
conditions to
generate heat-
ing and cooling
load profiles
The Forecast provider generates
weather forecasts and load fore-
casts for heating and cooling de-
mands based on the starting con-
ditions of the building received
from the BEMS.
BEMS Periodically The BEMS optimizes an operation
schedule considering also incen-
tives for providing balancing power
for a given period (e.g. 24 hours).
The corresponding nominal power
profile at the PCC of the building is
send to the energy supplier / VPP
USE CASES
D1.3_SENSIBLE_Deliverable_final 21/154
together with the balancing power
profiles which can be provided.
Energy provider
(VPP)
Periodically Energy price
data and balanc-
ing power incen-
tives
Price data and balancing power in-
centives are used to optimize an
operation schedule for the building
devices together with the building
flexibility (i.e. balancing power)
which can be commercialized ac-
cordingly.
BEMS Periodically The BEMS operates the devices of
the building according to the opti-
mized operation schedule such
that the nominal power profile at
the PCC is maintained. The bal-
ancing power (i.e. building flexibil-
ity) is provided whenever re-
quested (15 min at the maximum
before the due time/ after the re-
quest).
Building devices Control signal
from the BEMS
The Building devices follow the
control signals sent by the BEMS.
BEMS
(Optional)
Non-regular Participation at other energy mar-
kets, e.g. intraday, is refined /
specified later.
USE CASES
D1.3_SENSIBLE_Deliverable_final 22/154
2.2 Use Case 2: Flexibility and DSM in the market participation
2.2.1 Use Case identification
Table 8 Use case Identification
Name of the Use case
Flexibility and DSM in the market participation
Link to demonstrators
Évora
Domain
Building/ End customer
Business Key Features
Flexibility capacity for suppliers (DSM)
No direct involvement of Building and End-customers in open energy markets
Real Markets (i.e. day-ahead, intraday) accessible to Suppliers
2.2.2 Scope and Objectives of the Use Case
Table 9 Short description and main objectives
Short description The scope is about LV customer flexibility usage within the market
(wholesale and retail) and grid usage optimization regarding investment
deferral.
Main Objectives There are two complementary goals under the use case scope, for the
benefit of grid and customers, by making use of LV customer’s available
flexibility. These goals can be divided into regulated and market activity
and also into day-ahead and intraday periods.
Optimizing grid operation:
USE CASES
D1.3_SENSIBLE_Deliverable_final 23/154
• Day-ahead period: Grid usage optimization in peak hours by DSO
leading to grid operation optimization, by application of day-ahead
grid usage dynamic tariffs.
• Intraday period: In case of grid contingency, DSO could send a
DSM signal directly to customers in order to mitigate such contin-
gency through client’s flexibility.
Optimizing energy costs to clients:
• Day-ahead period: Client’s flexibility will be used by retailer in order
to optimize client’s energy costs in a day ahead perspective, mini-
mizing costs for clients, retailers and system.
• Intraday period: Retailer will use customer’s flexibility to minimize
deviations between portfolio consumption forecast and real con-
sumption in intraday market, minimizing costs for clients, retailers
and system.
Relation to other
Use cases
UC1: Managing building energy flexibility
UC4: Optimized energy procurement
2.2.3 Use Case Description
Flexibility and DSM in the market participation is a use case in which it is assumed that clients are able to provide electrical load flexibility through the usage of a Home Energy Management System (HEMS), which will control some of the following equipment:
• Storage (thermal and/or electrochemical) • PV generation • Flexible loads
These components are installed behind-the-meter and their integrated management can provide the previous mentioned electrical flexibility
The equipment to be installed could be owned by the customer and the available flexi-bility negotiated with a retailer (or other player able to manage such degree of freedom) through a flexibility contract. Alternatively, the equipment can be supplied and installed by a retailer (or other player able to manage such degree of freedom) and operated by that player optimizing the energy cost of the customer by means of a contract agreed between both parts.
It is assumed that the client's Electrical Energy Price (EEP) is divided in two components:
I. Energy Tariff (including system losses, retail costs, auxiliary systems, and energy itself), which is strongly influenced by the wholesale and retail market.
II. Grid Usage Tariff (grid's cost and system global costs): a regulated fee defined by the regulator.
USE CASES
D1.3_SENSIBLE_Deliverable_final 24/154
The available flexibility will be used with two complementary purposes (Optimizing Grid Operation and Energy Management) in two different time frames (day ahead and intra-day):
• Day Ahead: o Optimizing grid operation: The DSO will optimize the grid's manage-
ment in peak hours by providing a day ahead Grid Usage Factor (GUF) which penalizes the Grid Usage Tariff (GUT) to customers in peak hours, assigning a weight in the Grid usage part of the Electrical Energy Price. This GUF is regulated and applied by the DSO under strict rules that are available to every client. This factor aims to shave the grid load diagram by reducing the grid’s peak power with several benefits to the system such as reducing losses or enabling grid investment deferral possibilities. The HEMS should be able to receive that input and optimize client's energy flexibility in order to minimize the client's Electrical Energy Price.
o Energy balance management: The retailer optimizes its market partici-pation by managing the clients’ available flexibility. The retailer then shares the profit with the customer and minimizes the Energy Tariff. In a day ahead base, that flexibility will be scheduled in the HEMS, which will manage the client's available flexibility.
Fig. 7 – Day-ahead case: conceptual diagram
• Intraday o Optimizing grid operation: Under severe grid technical constraints the
DSO can send a DSM signal directly to the client's smart meter in a certain
USE CASES
D1.3_SENSIBLE_Deliverable_final 25/154
LV grid in order to require a demand curtailment to mitigate the previous mentioned constraints. The HEMS should be able to receive that signal and manage the client's energy flexibility in order to fulfil the DSO’s cur-tailment order. If a HEMS is available to do that, this DSM signal would be managed by the HEMS and after a predefined time the customers who are able to manage that order could remain connected and the ones who do not accept it could be shut down in order to keep the grid within its technical limits.
o Energy balance management: Deviation between the retailer client’s portfolio consumption forecast and the real consumption must be bal-anced in the intraday market. This deviation leads to higher system costs in the auxiliary system market, for both retailers and customers. This cost is called System Adjusting Factor (SAF). The deviation could be mini-mized/managed by retailers (representing the customers) using their available flexibility. The minimization of this deviation will result in profit (that can be shared by customers and retailer) which derives from the non aggravation of the Energy Tariff. In an intraday basis, that retailer devia-tion would be managed sending tracking signals to HEMS which would make use of each client's flexibility and adjust it optimizing client's energy price and retailer deviation.
Fig. 8 – Intraday case: conceptual diagram
2.2.4 Use Case Story
The use case flexibility and Demand Side Management in the Market Participation con-nects distributed energy resources to energy markets on the day-ahead and intraday levels while at the same time balances both the DSO’s and the retailers interests through
USE CASES
D1.3_SENSIBLE_Deliverable_final 26/154
a Grid Usage Factor and a System Adjusting Factor. The basic and simplified diagram of the use case is illustrated below, describing also the main actuators involved in the use case.
Fig. 9 - Use case Diagram and involved actors
2.2.4.1 Use case story for the Day Ahead period
The Energy Market Service Platform (EMSP) is a key actor throughout this use case story since it simulates the market and the retailers’ actions. For starters, it receives historical data from the clients’ energy meters and then it forecasts the status of the grid for the day-ahead period. Then, the necessary DSO flexibility is worked out and the Grid Usage Factor is calculated by the EMSP. This factor, which does not currently exist, intends to be a regulated tool, which can be used by the DSO under strict rules and aims to shave the grid load diagram by penalizing the Grid Access Tariff to clients. This factor is also sent to the HEMS, which will optimize the clients´ demand taking into account their flexibility.
On the other hand, each HEMS estimates the client´s flexibility and sends it to the EMSP, where the aggregated flexibility from a retailer client portfolio is computed. Taking ad-vantage of their clients’ joint flexibility, the retailer will optimize its market participation. This is computed in the EMSP, where the day-ahead market prices are simulated and the available flexibility is used to reduce the price at the demanding hours. Then, the energy cost is built by combining the energy tariff and the grid access tariff. The EMSP informs the retailers about the optimal participation in terms of price and individual flexi-bility. Each client´s HEMS also receives the set points to execute the flexibility action according to the plan.
USE CASES
D1.3_SENSIBLE_Deliverable_final 27/154
2.2.4.2 Use case story for the Intraday Period
In the intraday period, two stories are running in parallel. On the one hand, the retailer needs to balance the deviation between a clients’ portfolio consumption forecast and the real consumption. On the other hand, the DSO has to maintain the grid under technical operation limits, preventing service failures.
Whenever a deviation is recorded between a clients’ portfolio consumption forecast and the real consumption, the difference has to be balanced in the intraday market. However, this implies a cost that is charged by the TSO to the retailers via the System Adjusting Factor, SAF, which will ultimately increase the Energy Tariff to the clients. In order to minimize the impact of the SAF, clients’ flexibility can be used to minimize such deviation. In this sense, the HEMS collect the clients´ flexibility and send it to the EMSP, where the aggregated flexibility from a clients’ portfolio is calculated. Then, the EMSP simulates the market prices and the retailers’ market participation is optimized. The EMSP informs the retailers about the optimal participation in terms of price and individual flexibility. In addi-tion, each client’s HEMS also receives the set points to execute the flexibility action ac-cording to the plan.
From the DSO side, the GUF is no longer available to manage the grid in the intraday period. Moreover, the DSO is only allowed to act under severe grid technical problems, namely imminent blackouts. For those situations, once the DSO detects a grid contin-gency situation, two warnings signals are triggered simultaneously. One signal is sent to all the smart meters indicating the new available power, with a 15 minutes maximum delay. The other signal is sent to the HEMS indicating how much the load should be reduced by each client according to fair rules taking into account their individual con-sumption profile. Taking advantage of its own flexibility, each HEMS could manage the client’s consumption to cope with the load reduction request during a pre-defined period of time. Clients who are able to manage such requirement can remain connected; other-wise, clients are disconnected from the grid via smart meters.
2.2.5 Actors
Table 10 Actors involved
Actor name Actor Type Actor Description
DSO related ac-
tors - EDP Box
(EB)
Systems of DSO EDP Box is an energy smart meter device de-
signed according to the Portuguese specifica-
tions. This equipment has remote communica-
tion capabilities for network management, AMR
(automatic meter readings) and AMI (advanced
metering infrastructure)
DSO related ac-
tors - Distribution
Systems of DSO LV Network Controller and Data concentrator de-
vice responsible for the management of the EDP
USE CASES
D1.3_SENSIBLE_Deliverable_final 28/154
Transformer Con-
troller (DTC)
Box (smart meters) infrastructure and for the
management and monitoring of the distribution
MV/LV substation and low voltage network
DSO related ac-
tors - DMS data-
base
Systems of DSO The DMS Data Base includes a number of func-
tionalities directly managed by the DSO, com-
posed by the AMI system, MV/HV SCADA sys-
tem, LV SCADA system, Data Collection and
Provision systems.
DSO related ac-
tors - Real Time
Platform (RTP IN-
DRA)
Systems of DSO Real Time Integration Platform (iSPEED) is an
integrated platform for real-time data acquisition
and processing, with the ability to handle a large
volume of information at low latency. It will act as
a middleware between the DSO services and all
SENSIBLE tools
Forecast provider -
Load Forecast
Data Analytics The tool (ARMINES prediction system) provides
forecasts for the electric and heating demand for
individual consumers.
Forecast provider -
Renewable En-
ergy Forecast
Data Analytics The tool (ARMINES prediction system) provides
forecasts for the Renewable Energy production
Distributed energy
resources - LV Cli-
ent Storage
LV client Residential storage for Évora demonstrator cor-
responds to electrochemical storage units
owned by the consumer and connected behind
the meter
Distributed energy
resources - Micro-
generation
LV client Corresponds to small scale PV units connected
to single-phase LV clients
Distributed energy
resources - Con-
trollable loads
LV clients Corresponds to electric water heaters remotely
controlled through the HEMS interface. Con-
nected to single-phase LV clients
Home energy
management sys-
tem (HEMS)
Systems of cus-
tomers
HEMS is used for real time monitoring of energy
consumption/ generation, controlling domestic
devices and electric circuits and accessing smart
meter data and real energy consumptions.
USE CASES
D1.3_SENSIBLE_Deliverable_final 29/154
HEMS is also a system where the clients can in-
troduce their flexibility settings. It has the capa-
bility of transforming the defined flexibility to set
points to the controllable devices (PV, storage,
controllable loads). The HEMS also collects the
current operational status of the above-men-
tioned flexible devices.
Energy Market
Service Platform
Systems of Ex-
ternal Roles
Platform that optimizes the retailer market partic-
ipation, considering its client joint flexibility, ac-
cording to each client’s availability. This service
platform also simulates DSM functionalities,
providing estimation for the Grid Usage Factor
(GFU), according to the grid operation point fore-
cast and the technical constraints of the grid. It
also enables the grid contingency situation, by
issuing warning and shutdown signals to the
smart meter and warning to HEMS
The input will be the flexibility of each client (from
the HEMS).
The output will be the optimal energy cost and its
respective flexibility (to be sent to the HEMS dis-
aggregated by client).
Energy Markets -
Day-ahead market
Systems of Ex-
ternal Roles
Day-ahead market is used for daily electricity
procurements. Depending on the market variant
in question, the bidding happens once a day at a
predetermined timeslot. Bids made to the market
always lead to a delivery of physical electricity.
Energy Markets -
Intraday market
Systems of Ex-
ternal Roles
Intraday market is used for correcting imbal-
ances in daily electricity procurement. Trade
takes place multiple times during the current de-
livery day. The amount of tradable hours varies
upon the market in question. Trading in intraday
market always leads to a delivery of physical
electricity.
Energy retailer Systems of Ex-
ternal Roles
Market participant actor who will buy and sell
electricity to and from the electricity users.
USE CASES
D1.3_SENSIBLE_Deliverable_final 30/154
2.2.6 Steps
2.2.6.1 Day Ahead Case
Fig. 10 - Activity diagram for the day ahead period.
USE CASES
D1.3_SENSIBLE_Deliverable_final 31/154
Table 11 Day Ahead use case steps
Step
nº
Name of
Process /
Activity
Main Actor Information
Exchanged
Requirements
(Req-ID)
1 Collect client’s flexibility HEMS Flexibility data E_FR11,
E_NFR4,
E_NFR9,
E_NFR18,
E_NFR19,
E_NFR23
2 Grid status historical assess-
ment
Energy Market
Service Plat-
form
Grid status his-
torical data
E_NFR4,
E_NFR6,
E_NFR8,
E_NFR9,
E_NFR18,
E_NFR19
3 Grid status forecast Forecast
provider
Grid status fore-
cast data
E_FR1,
E_NFR1,
E_NFR4,
E_NFR21
4 Calculate the necessary
DSO flexibility
Energy Market
Service Plat-
form
Flexibility data E_FR5,
E_NFR21,
E_NFR22
5 Calculate the Grid Usage
Factor
Energy Market
Service Plat-
form
Grid Usage Fac-
tor (Grid access
price evolution)
E_NFR4,
E_NFR22
6 Aggregate flexibility from re-
tailers client portfolio
Energy Market
Service Plat-
form
Flexibility data E_NFR18,
E_NFR19,
E_NFR24
7 Optimize market participa-
tion
Energy Market
Service Plat-
form
Market partici-
pation
E_FR12,
E_NFR21
USE CASES
D1.3_SENSIBLE_Deliverable_final 32/154
8 Build Energy Cost Energy Market
Service Plat-
form
Market partici-
pation
E_FR12;
E_NFR25
9 Send to retailers optimal par-
ticipation (price and individ-
ual flexibility)
Energy Market
Service Plat-
form
Flexibility data E_NFR4,
10 HEMS manages the flexibil-
ity according to the client’s
availability and GUF
HEMS Set points to
HEMS
E_FR4,
E_FR13,
E_NFR4,
E_NFR17,
E_NFR18,
E_NFR19,
E_NFR20
2.2.6.2 Intraday Case
As it was mentioned above, for the intraday period two stories are running in parallel, here represented by the routine A (DSO perspective) and the routine B (Clients perspec-tive).
USE CASES
D1.3_SENSIBLE_Deliverable_final 33/154
Fig. 11 - Activity diagram - routine A.
USE CASES
D1.3_SENSIBLE_Deliverable_final 34/154
Fig. 12 - Activity diagram - routine B.
USE CASES
D1.3_SENSIBLE_Deliverable_final 35/154
Table 12 Intraday use case steps
Step
nº
Name of
process/Activity
Main Actor Information Exchanged Requirements
(Req-ID)
A1 Detect DSO grid
contingency
Energy Market
Service Plat-
form
Grid status historical data
Grid status forecast data
E_FR15,
E_NFR4,
E_NFR6,
E_NFR8,
E_NFR9
A2a Send warning signal
to each Smart Meter
indicating new avail-
able power (with a
15 minute delay)
Energy Market
Service Plat-
form
Grid load warning E_FR4,
E_FR13,
E_NFR4,
E_NFR26,
E_NFR27
A2b Send warning signal
to HEMS indicating
what load should be
reduced by each cli-
ent
Energy Market
Service Plat-
form
Grid load warning E_FR4,
E_FR13,
E_NFR4,
E_NFR26
A3 HEMS manages cli-
ent’s demand ac-
cording to the DSO
request and client’s
flexibility
HEMS Grid load warning E_NFR20,
E_NFR27
A4 Disconnect clients
that are over their
available power
HEMS Grid load warning E_FR16,
E_NFR4,
E_NFR17,
E_NFR19
B1 Collect client’s de-
mand
HEMS Data is sent to the Energy
Market Service Platform
E_NFR4,
E_NFR19,
E_NFR20
B2 Deviation between
real consumption
and forecast con-
Energy market
service platform
Real and forecast con-
sumption
USE CASES
D1.3_SENSIBLE_Deliverable_final 36/154
sumption from a re-
tailer clients’ portfo-
lio
B3 Calculate the Sys-
tem Adjusting Factor
Energy market
service platform
System Adjusting factor E_FR17
B4 Collect client’s flexi-
bility
HEMS Flexibility data E_FR11,
E_NFR4,
E_NFR9,
E_NFR18,
E_NFR19,
E_NFR23
B5 Aggregate flexibili-
ties from retailers cli-
ent portfolio
Energy Market
Service Plat-
form
Flexibility data E_NFR18,
E_NFR19,
E_NFR24
B6 Optimize market
participation
Energy Market
Service Plat-
form
Market participation E_FR12,
E_NFR21
B7 Build Energy Cost Energy Market
Service Plat-
form
Market participation E_FR12;
E_NFR25
B8 Send to retailers op-
timal participation
(price and individual
flexibility)
Energy Market
Service Plat-
form
Flexibility data E_NFR4,
B9 HEMS manages the
flexibility according
to the client’s availa-
bility
HEMS Set points to HEMS E_FR4,
E_FR13,
E_NFR4,
E_NFR17,
E_NFR18,
E_NFR19,
E_NFR20
Note: The A and B routines run in parallel. A2a and A2b represent two signals that are triggered simultaneously when the DSO detects a grid contingency situation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 37/154
2.2.7 Information Exchange
Table 13 Information Exchange
Name of Information (ID) Description of Information Exchanged
Net-load_forecast
Net-load forecasts for each node of the LV grid, which is provided
by the ARMINES prediction system. Time horizon ranging be-
tween 15 minutes and 48 hours; hourly resolution of 15 and 60
minutes; hourly update rate.
REG_forecast
Renewable generation forecasts of micro-generation which is
provided by the ARMINES prediction system. Time horizon rang-
ing between 15 minutes and 48 hours; hourly resolution of 15 and
60 minutes; hourly update rate.
FlexClt_Forecast Flexibility capacity forecast for each client. The data is sent once
a day; data resolution 15 or 60 minutes.
FlexCltPortfolio_Forecast
Flexibility capacity forecast for retailer client portfolio, which cor-
respond to the clients‘ joint flexibility. The data is sent once a day;
data resolution 15 or 60 minutes.
ControlableLoads Availability of controllable loads, namely the active power con-
sumption, curtailment power and time. Update every 15 minutes.
ElectPrice_DayAhead Day-ahead electricity wholesale market price. The data is sent
once a day; data resolution 60 minutes.
ElectPrice_Intraday Intraday electricity wholesale market price. The data is sent every
4 hours; data resolution 60 minutes.
DER Distributed energy resources control commands. Ad-hoc or
scheduled commands based on the market/balance situation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 38/154
2.3 Use Case 3: Increased percentage of self-consumption
2.3.1 Use Case identification
Table 14 Use case Identification
Name of the Use case
Increased percentage of self-consumption
Link to demonstrators
Nuremberg
Domain
Building/End customer
Business Key Features
Off-grid self-consumption capacity
Maximizing consumption of locally generated power
2.3.2 Scope and Objectives of the Use Case
Table 15 Short description and main objectives
Short description This use case demonstrates the ability of the BEMS to increase self-con-
sumption of locally generated power in an energy-efficient manner by
utilizing the flexibility of building devices and infrastructure (e.g. flexible
loads, generation units, storage units).
Main Objectives The main goal of this use case is to maximize the self-consumption of
locally generated power and correspondingly to operate the building in-
frastructure with the optimal proportion and distribution of different en-
ergy sources to be consumed (electrical vs. thermal power consump-
tion).
Therefore, this use case enables most efficient usage of “electricity gen-
erating capacity” during periods of “maximum power generation” by the
renewable energy sources (RES).
USE CASES
D1.3_SENSIBLE_Deliverable_final 39/154
Relation to other
Use Cases
UC6: Enabling an independent energy community
The main difference between this use case and UC6 lays on the fact that
UC6 considers the benefit (reduce of cost) at community level while pre-
sent use case aims benefits at commercial building level.
2.3.3 Use Case Description
The BEMS aims to operate the building infrastructure in such a way to minimize the power obtained from power grids by utilizing locally generated power efficiently. This reduces the energy obtained from power grids and ensures maximum energy efficiency during operation. For that purpose, BEMS maximizes the consumption of locally gener-ated (thermal and electrical) energy. Furthermore, the electrical-thermal energy interac-tion/conversion is jointly optimized to maximize energy efficiency when operating the entire infrastructure of the building. On-site energy storage units (e.g. electro-chemical and thermal storage) are deployed and managed accordingly for that purpose. For ex-ample, the self-consumption of locally generated power is maximized by optimizing an operation schedule and by accordingly controlling the operation of on-site energy storage units appropriately. As a result, the power demands (both electrical and thermal) ob-tained from external providers are reduced.
Electrical and thermal loads (demands) as well as the expected local energy generation are estimated by BEMS using forecasting algorithms. In order to realistically estimate the future energy requirements (thermal and electrical) of the building as well as the ex-pected energy generation (e.g. PV and CHP), weather forecast is used as well. Com-bined with technical parameters extracted from the building infrastructure, these fore-casts are then used by a model-based optimization kernel to calculate the most energy efficient operation of the building infrastructure.
2.3.4 Use Case Story
The use case will demonstrate that the energy efficient operation of a building containing on-site (electrical and thermal) energy generation and storage units can reduce the total energy demand from power grids. The combined optimization of electrical and thermal devices enhances the energy efficiency when operating the building infrastructure. A good example of this is to consider the electricity generated by locally installed PV in the building and an on-site CHP. When using the CHP, the additional heat generated as a by-product is further used directly for heating/cooling purposes in the building. Instead of selling the locally generated energy, it is either immediately used locally or stored for later use.
USE CASES
D1.3_SENSIBLE_Deliverable_final 40/154
Fig. 13 Use case Diagram and involved actors – Increased percentage of self-consumption
2.3.5 Actors
Table 16 Actors involved
Actor name Actor Type Actor Description
Forecast ser-
vice provider/
module
Software The Forecast service provider estimates loads for the com-
ing time period (e.g. 1 day, hourly curve) to the BEMS.
Load forecasts represent the thermal power needs (for
heating and cooling) expected by the building as well as
the electrical load. Furthermore, it provides a forecast of
the local PV generation and the local weather conditions.
The forecast service can either be obtained from local
USE CASES
D1.3_SENSIBLE_Deliverable_final 41/154
modules integrated to BEMS or from external service pro-
viders (e.g. Armines).
Building Energy
Management
System
HW/SW Represents the central control component of the building
system. The BEMS receives forecasts from the Forecast
provider. These forecasts are used to operate the building
infrastructure in order to maximize the consumption of the
locally generated power by using available flexibilities
(floating set points, storage devices, building inertia) and to
maximize energy efficiency. The energy efficiency in the
entire building infrastructure is maximized by jointly man-
aging the electrical and thermal devices and/or the combi-
nation of both.
Building de-
vices
Hardware The building devices include generation units (PV, CHP,
heat pump, and chiller), storage devices (cold storage, hot
storage, building inertia) and devices for heating and cool-
ing (e.g. HVAC). The building devices are operated by the
BEMS to maximize the self-consumption and to maximize
the energy efficiency of the total infrastructure in the build-
ing.
Energy pro-
vider (VPP)
Software inter-
face
The Energy provider delivers energy price for an upcoming
time period (e.g. day-ahead, hourly curve).
Real-time inte-
gration platform
HW/SW Real-time integration platform for real-time data acquisition
and processing, with the ability to handle a large volume of
information at low latency. It will act as a communication
bridge between BEMS, the Energy provider (Empower)
and the Forecast service provider (Armines).
USE CASES
D1.3_SENSIBLE_Deliverable_final 42/154
2.3.6 Steps
Fig. 14 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 43/154
Fig. 15 Sequence Diagram
Table 17 Use case steps
Ste
p nº
Name of
Process /
Activity
Main Ac-
tor
Information
Exchanged
Require-
ments
(Req-ID)
1. Measuring
data from
building de-
vices
BEMS The BEMS collects current data from the
building devices. (Room temperature, stor-
age levels, etc.)
--
2. Sending
starting con-
ditions to
Forecast
provider
BEMS The BEMS sends the required data to the
Forecast provider.
N_FR-1
3. Generation
of forecasts
Forecast
provider
The Forecast provider sends weather and
load forecasts for heating and cooling to the
BEMS.
N_FR-3,
N_FR-4,
N_FR-5,
N_NFR-3,
N_NFR-4
USE CASES
D1.3_SENSIBLE_Deliverable_final 44/154
4. Optimizing
the opera-
tion sched-
ule of the
building de-
vices
BEMS The BEMS optimizes an operation schedule
for the coming period (e.g. 24h) to maximize
the self-usage and to maximize energy effi-
ciency, i.e. to reduce energy demand from
power grids.
For that purpose, models of the different ag-
gregates (e.g. heat pump, HVAC, CHP,
etc.) are used together with the forecast in-
formation.
N_FR-1,
N_FR-6,
N_NFR-1,
N_NFR-2,
N_NFR-3
5. Operation of
building de-
vices:
Online
power man-
agement
BEMS The BEMS monitors the status of genera-
tion and consumption and correspondingly
operates the building (i.e. optimizes the op-
eration mode of devices) by sending the
corresponding control signals to the building
devices or the corresponding control units
for optimal operation. Disturbances such as
mismatches between forecasted and actual
values, e.g. base load, are compensated, as
much as possible, using the storage devices
(e.g. cold storage, hot storage, battery ...).
--
Table 18 Triggering Events, Pre-conditions and Assumptions
Actor /
System /
Information
Triggering
event
Pre-conditions Assumptions
BEMS Constantly The BEMS measures the current
building conditions.
BEMS Periodically Measurement
data
The BEMS sends the required build-
ing conditions together with the histor-
ical data about the thermal and elec-
trical energy consumption to the fore-
casting service provider or an inte-
grated forecasting-module.
Forecast
service pro-
vider/mod-
ule
Request from
the BEMS
The forecast ser-
vice provider gets
the necessary in-
formation about
The Forecast provider/module sends
the forecasts to the BEMS (e.g. solar
irradiation, building loads etc.)
USE CASES
D1.3_SENSIBLE_Deliverable_final 45/154
the weather con-
dition as well as
historical de-
mands of the
building. Also
starting condi-
tions of the build-
ing are neces-
sary.
Energy pro-
vider/ VPP
Constantly
(day-ahead,
hourly curve)
Price data Although, no price data is necessary
for this use case, fixed price data (e.g.
12 Cent per kWh) leads to an equiva-
lent solution.
BEMS Periodically /
constantly
The BEMS optimizes an operation
plan for operating the building devices
based on the forecasts to increase
self-consumption and to maximize en-
ergy efficiency in the entire infrastruc-
ture of the building. The BEMS oper-
ates the building devices in a way that
maximizes energy efficiency even if a
disturbance occurs during operation.
Building de-
vices
Control signal
from the
BEMS
The building devices follow the control
signals sent by the BEMS.
USE CASES
D1.3_SENSIBLE_Deliverable_final 46/154
2.4 Use Case 4: Optimized energy procurement
2.4.1 Use Case identification
Table 19 Use case Identification
Name of the Use Case
Optimized energy procurement
Link to demonstrators
Nuremberg
Domain
Building/End Customer
Business Key Features
Off-grid self-consumption capacity
Maximizing consumption of locally generated power
Real Markets (day-ahead) accessible to Suppliers
2.4.2 Scope and Objectives of the Use Case
Table 20 Short description and main objectives
Short description This use case aims at minimizing energy procurement costs by us-
ing flexibilities of the building in combination with flexible energy tar-
iffs.
Main Objectives Minimizing the energy procurement costs for building operation.
Relation to other Use
Cases
UC 6: Enabling an independent energy community
The main difference between this use case and UC6 lays on the fact
that UC6 considers the benefit (reduce of cost) at community level
while present use case aims benefits at commercial building level.
USE CASES
D1.3_SENSIBLE_Deliverable_final 47/154
2.4.3 Use Case Description
Minimizing energy procurement costs is an important task for building operators nowa-days. Variable electricity prices (e.g. off-peak-/peak-tariff, hourly electricity prices) com-bined with flexible building devices and storage units open up new opportunities to re-duce building operation costs. The intention is to demonstrate the benefits of using flex-ible energy tariffs with time-varying energy prices to reduce the energy cost based on production/consumption forecast.
This use case describes the process of generating forecasts of electric and thermal power demands and tracking these forecasts by managing consumption, storage and generation units to reduce energy procurement costs.
2.4.4 Use Case Story
In this use case, the BEMS manages the building devices in a way to reduce the energy procurement costs for the building operation. Forecasts of weather conditions, energy prices and the building demand for a defined time period are used to optimize the oper-ation of the building devices. Therefore, prediction models of the building devices, which are combined with the forecasts, enable the BEMS to predict the so-called nominal power profile at the buildings PCC. Available flexibilities (storage units, floating set points, building inertia) are used to minimize the energy procurement costs for building operation based on day-ahead market.
USE CASES
D1.3_SENSIBLE_Deliverable_final 48/154
Fig. 16 Use case diagram and involved actors – Optimized energy procurement
2.4.5 Actors
Table 21 Actors involved
Actor name Actor Type Actor Description
Forecast ser-
vice pro-
vider/module
Software The Forecast service provider estimates loads for the com-
ing time period (e.g. 1 day, hourly curve) to BEMS. Load
forecasts represent the thermal power needs (heating and
cooling) expected by the building as well as the electrical
load. Furthermore, it provides a forecast of the local PV
generation and the local weather conditions (irradiation &
USE CASES
D1.3_SENSIBLE_Deliverable_final 49/154
ambient temperature). The forecast service can either be
obtained from local modules integrated to BEMS or from
external service provides (e.g. Armines).
Energy pro-
vider (VPP)
Software inter-
face
The Energy provider delivers energy price forecasts for an
upcoming time period (day-ahead, hourly curve).
BEMS Software/
Hardware
Represents the central control component of the building
system. The BEMS receives data from the Forecast pro-
vider and the Energy provider. This data is combined with
models of the building devices, which are implemented in
the BEMS. They are used to optimize the operation sched-
ule of the building devices and to minimize the energy
costs by using available flexibilities (floating set points,
storage devices, and building inertia) of the building.
Building de-
vices
Hardware The building devices are represented by generation units
(PV, CHP, heat pump, chiller), storage devices (cold stor-
age, hot storage, building inertia) and devices for heating
and cooling (HVAC). The building devices operate in a
cost-efficient way managed by the BEMS. At the same time
the effect on the building climate should be as low as pos-
sible.
Real-time inte-
gration platform
Hard-
ware/software
The Real-time integration platform is an integrated platform
for real-time data acquisition and processing, with the abil-
ity to handle large volumes of information at low latency. It
will act as a communication bridge between BEMS, the En-
ergy provider (Empower) and the Forecast service provider
(Armines).
USE CASES
D1.3_SENSIBLE_Deliverable_final 50/154
2.4.6 Steps
Fig. 17 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 51/154
Fig. 18 Sequence Diagram
Table 22 Use case steps
Ste
p nº
Name of
process/Activ-
ity
Main
Actor
Information Exchanged Require-
ments
(Req-ID)
1. Measuring data
from building de-
vices
BEMS The BEMS requests current data from
the building devices (e.g. storage levels)
as well as the current status (indoor tem-
perature, humidity X).
--
2a. Sending starting
conditions
BEMS The BEMS sends the starting conditions
of the building to the Forecast provider.
N_FR-1,
N_NFR-1,
N_NFR-2
2b. Sending history
data
BEMS BEMS sends the history data to forecast
service provider/module
N_FR-1,
N_NFR-1,
N_NFR-2
3a. Sending fore-
casts
Fore-
cast
provider
The Forecast provider sends weather
forecasts and load forecasts for heating
N_FR-1,
N_NFR-1,
N_NFR-2
USE CASES
D1.3_SENSIBLE_Deliverable_final 52/154
and cooling to the BEMS. The load fore-
casts are based on the starting condi-
tions.
3b. Sending energy
price information
Energy
provider
The Energy provider sends energy price
data for a defined time period to the
BEMS.
N_FR-1,
N_FR-6,
N_NFR-1
4. Optimization of
the operation
mode of the
building devices
BEMS The BEMS optimizes an operation
schedule for the upcoming period (e.g.
24h) to minimize the energy procurement
costs. For that purpose, models of the dif-
ferent aggregates (e.g. heat pump,
HVAC, CHP, etc.) are used together with
the forecasts and price data.
The corresponding nominal power profile
at the point of common coupling (PCC) of
the building is sent to the energy pro-
vider/VPP.
--
5. Operation of
building: Online
power manage-
ment
BEMS The BEMS monitors the generation and
consumption and correspondingly oper-
ates the building (i.e. optimizes the oper-
ation mode of devices) by sending the
corresponding control signals to the
building devices or the corresponding
control units for optimal operation. Dis-
turbances such as mismatches between
the forecasted and actual values, e.g.
base load, are compensated, as much as
possible, using the storage devices (cold
storage, hot storage, building inertia).
--
USE CASES
D1.3_SENSIBLE_Deliverable_final 53/154
Table 23 Triggering Events, Pre-conditions and Assumptions
Actor/ System /
Information
Triggering
event
Pre-conditions Assumptions
BEMS Constantly The BEMS collects current meas-
urement data from the building de-
vices.
Energy provider
(VPP)
Constantly
(day-ahead,
hourly curve)
Price data Price data are used to optimize en-
ergy procurement using building
flexibility.
BEMS periodically Measurement
data
The BEMS sends the required build-
ing conditions to the Forecast pro-
vider together with the historical data
about the thermal and electrical en-
ergy consumption to the forecasting
service provider or an integrated
forecasting-module.
Forecast service
provider/module
Request
from the
BEMS
Holding fore-
casts for
weather and
current building
conditions.
The Forecast provider sends
weather and load forecasts for heat-
ing and cooling based on the starting
conditions of the building.
BEMS Periodically /
constantly
The BEMS optimizes an operation
schedule for operating the building
devices based on the forecasts to
minimize energy procurement costs.
The BEMS operates the building de-
vices in a way that minimizes energy
procurement costs even if disturb-
ances occur during operation.
Building devices Control sig-
nal from the
BEMS
The building devices follow the con-
trol signals sent by the BEMS.
USE CASES
D1.3_SENSIBLE_Deliverable_final 54/154
2.5 Use Case 5: Microgrid PV Management
2.5.1 Use Case identification
Table 24 Use case Identification
Name of the Use Case
Microgrid PV Management
Link to demonstrators
Nottingham
Domain
Microgrid / Community
Business Key Features
Self-consumption as top priority
Grid supply used as backup (Islanding operation mode most of times)
Simulated community automated market by means of P2P energy trading transactions
2.5.2 Scope and Objectives of the Use Case
Table 25 Short description and main objectives
Short description In this use case we will present several situations where the system has
to deal with the limitation of PV penetration or with stability issues in the
internal grid due to the over production of PV or with the lack of PV gen-
eration. This use case will allow us to demonstrate how the microgrid
control system will manage the different situations.
Main Objectives Show the capacity of the Energy Management System, the e-Broker sys-
tem and the Real Time Integration Platform to manage the different
power sources, to create a common power market matching microgrid
needs.
Relation to other
Use Cases
UC6: Enabling an independent energy community
UC7: Microgrid Energy Market
USE CASES
D1.3_SENSIBLE_Deliverable_final 55/154
2.5.3 Use Case Description
The goal of this use case is to analyse the response of the system to three different scenarios. In the first scenario, we will be able to study how the PV penetration limit could be extended thanks to the distributed storage system. In the second scenario, the ca-pacity of the distributed storage system to stabilize the microgrid and to maintain the quality of the power while the PV production excesses the load demand will be tested. Finally, the third scenario will show the situation where a lack of PV production obliges the system to inject power from the distributed stored system.
Nowadays, there are a set of requirements and standards which establish the limit of the PV penetration where the electrical grid, due to its characteristics, does not allow to have unlimited PV penetration. The first case will be useful to show how the system as it is design in this project could help to extend the current PV penetration. This would allow the creation of communities with a highly reduced dependence of the utilities.
One of the main negative aspects of the PV power supply is the quality of the power and the stability of the supply. This has a direct effect on the lifespan of the loads fed by PV power production plants. The success in the second case would show the capacity of the system to maintain the quality of the power and to be stable by itself. And this would assure the reduction of the impact on the lifespan of the loads.
One of the objectives of the project is to create a system that would allow the creation of sustainable communities. The distributed storage system designed in this project would allow the reduction of the utility community dependence. A positive result in the third case would show the capacity of the system to be independent of the electric supplier under certain circumstances.
This use case will be tested in a system composed by a distributed PV generation plant, a distributed storage system, a real time distributed control of the microgrid with a central monitoring node, which is performed by the Energy Management System, the e-brokers and the Real Time Integration Platform. Those tools will ensure the microgrid stability and operation when possible.
The main devices and systems taking part in this use case are:
• Distributed PV generation plant: it is composed of PV panels located in different properties where the Nottingham demonstrator is located.
• Distributed storage system consists of batteries located in Nottingham demon-strator’s facilities.
• Energy Management System (EMS): it is a device, which allows monitoring the state of the microgrid elements (storage system, PV solar plant, power electron-ics devices, grid interface, etc).
• E-Broker: it is a distributed management and control system.
• Integration Gateway (IG): Required HW/SW to ensure communication and inter-faces the E-broker and the Real-time platform.
• Real Time Integration Platform: it is a platform, which allows sharing the infor-mation among the elements of the microgrid.
USE CASES
D1.3_SENSIBLE_Deliverable_final 56/154
• Distributed Storage System: it has the capacity of storing energy as well as providing it afterwards.
• Microgrid load: load to be fed by the microgrid power sources • Grid: it represents the main grid.
2.5.4 Use Case Story
The phases compounding this use case are chronologically exposed and described be-low:
The distributed PV plant begins to produce power shortly after the dawn and the house-holds located in the Meadows will use this power. According to the lifestyle in the area, the power consumption will dramatically decrease and the PV power production will ex-ceed the demand. This will imply a potential destabilization if no action is taken by the system.
• PV production begins after dawn and it is dedicated to feed the loads.
• Load demand decreases and PV production exceeds the demand. This infor-mation will be acquired by the e-brokers of the load and of the PV installations. The information will be shared with the Real Time Integration Platform. EMS and the others e-brokers will have access to the information.
• Potential destabilization and power quality issues appear.
To avoid this situation the system will analyse the situation and it will decide to store as much power as it can be stored in the distributed system (it will depend on the pre-exist-ing state of charge of the storage system). The surplus of power will be sold to the ex-ternal network.
• The system analyses the situation and derives the power to the distributed stor-age system. The surplus will be sold to the external electrical network. The EMS is the responsible for setting the working conditions of the elements of the sys-tems. According to EMS commands, the e-brokers will coordinate themselves and will direct on the distributed storage system, PV installations, microgrid – grid interface, etc.
One of the limits established by regulations and standards is related to the PV penetra-tion. The main reasons for this limitation are the quality and stability problems whenever the PV production exceeds the load consumption. This Use-Case will demonstrate how SENSIBLE system would prevent these issues and, therefore, increment the PV pene-tration. Specifically, when the load demand increases and the PV production decreases, this situation will trigger the system action and the power deficit will be covered by the stored energy or by the grid if there is not enough power in the batteries.
This action will be responsibility of the e-brokers that will share through the integration gateway with the Real Time Integration Platform ordering the injection of power from the batteries (the power converters will command the batteries). After that if the demand has not been totally covered the EMS will increase the power purchased from the grid and it will send the corresponding command to grid-microgrid interface.
USE CASES
D1.3_SENSIBLE_Deliverable_final 57/154
The successful implementation of this use case will allow the system to maintain the stability and energy quality in the case of a drop in the PV production.
Fig. 19 Use case diagram with involved actors
2.5.5 Actors
Table 26 Actors involved
Actor name Actor Type Actor Description
E-Broker
HW/SW It is a distributed management and control system capable
of making autonomous decisions, improving dynamically
the quality of a microgrid or a smart grid, contributing to its
stability and computing the price of the energy to be sold
or bought by the commanded element.
The system allows power exchanging, practically in real
time, between the different power devices connected to the
microgrid, without a central control system, a central en-
ergy manager or system operator.
USE CASES
D1.3_SENSIBLE_Deliverable_final 58/154
Energy Man-
agement Sys-
tem / Mead-
ows Data
Manager
(MDM)
HW/SW It is a device, which allows monitoring the state of the mi-
crogrid elements (storage system, PV solar plant, power
electronics devices, grid interface, etc.). This equipment is
connected to the rest of microgrid devices. It is hierarchi-
cally superior to the distributed control system (e-broker)
so it can command it. It is the responsible for determining
the operation conditions and the price range of the
sold/bought energy to the elements of the microgrid. This
hardware is also responsible as the LV Network Controller
and Data concentrator. It is able to send command and
control data to the devices in the demonstrator (inverters,
controllable loads, distributed storage devices) and can act
as an energy management system. This device also has
the function of the management and visualisation of the in-
formation from the demonstrator from the smart meter in-
frastructure and the monitoring of the distributed storage
devices and low voltage network and auxiliary data col-
lected. This equipment may also be used as a data con-
centrator and can be used to re-distribute data to other ac-
tors after data has been concentrated into a ‘virtual mi-
crogrid’. The hardware may also be used to implement the
analysis for the market driven control and cost benefit cal-
culation.
Integration
Gateway (IG)
HW/SW The gateway will provide the required communication,
computing and storage capabilities to integrate data and
will allow making independent the measuring process de-
sign from the platform development.
Real Time In-
tegration Plat-
form (RTP)
HW/SW It is a platform, which allows sharing the information among
the elements of the microgrid.
ADEVICE
Smart meter
Modified ver-
sion (ASM)
Systems of
DSO
ADEVICE Smart meter is an power smart meter. This
equipment has remote communication capabilities for net-
work management, AMR (automatic meter readings), data
gathering. This equipment gives measurements of 3 indi-
vidual phase nodes on a single-phase power system. This
enables the energy meter to measure generation, storage,
usage and grid power variables with a single meter.
USE CASES
D1.3_SENSIBLE_Deliverable_final 59/154
Distributed
Storage Sys-
tem E-Broker
HW/SW The distributed storage system is compound of real-model
batteries.
As a bidirectional device, the battery simultaneously par-
ticipates in the exchanges of power as a consumer and a
producer. Its offer and demand power value depends on
its own state of charge (SoC) so as to keep a convenient
health state of the device.
The produced or consumed total power by this device is
small so the influence of the battery over the global behav-
iour of the microgrid is practically negligible.
Distributed
Photovoltaic
Plant E-Bro-
ker
HW/SW The photovoltaic solar plant is a system mainly compound
of different solar arrays of photovoltaic panels located in
the properties of the Nottingham Demonstrator and a cer-
tain number of inverters. The aim of the PV plant is to pro-
vide electric power to the microgrid.
It starts providing power at dawn. The power available de-
pends on the irradiance in the photovoltaic panels. The
produced power increases over time and reaches the max-
imum value about 15:00 hours. Then the value of power
decreases until the sunset when the available power falls
to 0.
As it is a renewable source of power and due to its nature,
this device always has a high value of priority and it is nor-
mal that its offers achieve exchange agreements, that is to
say, it is usual that the entire power produced is consumed
(or stored by a storage system).
Load E-broker HW/SW It represents the entire consumption of the microgrid. It
could be represented as an intelligent building, an office
building, a business park, a residential area, city lighting,
etc. It is overall presented as the load of the microgrid. The
demands and the established prices depend on the con-
sumption during the different hours of the day and some
events which are described in detail in the storyline.
Microgrid –
Grid Interface
E-Broker
Facility It represents the point of interconnection or the point of
common coupling (PCC) between the microgrid and the
main grid. At this point, the associated intelligent device
manages this interface, that is to say, for the e-Broker sys-
tem the main grid is just another system with the same sort
of parameters to participate in the power exchanges.
USE CASES
D1.3_SENSIBLE_Deliverable_final 60/154
For this use case, the local consumption (exchanges) of
power is considered a priority when possible. In general, if
there is an excess of produced power in the microgrid it is
sold to the grid. Similarly, the power of the main grid will be
purchased if the power generated in the microgrid is not
enough to supply itself or if between the microgrid devices
have not been achieved economic agreements.
2.5.6 Steps
Fig. 20 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 61/154
Fig. 21 Sequence Diagram
Table 27 Use case steps
Step
nº
Name of
Process / Activity
Main Actor Information Exchanged /
process performed
Requirements
(Req-ID)
1 Measuring data from
the network and Auxil-
iary data collection /
weather forecast
RTP / MDM RTP_Info
Change_load
Change_PV production
Storage_charge
Power_exchanged
Power_loads
No_FR2
2 Use-Case Initialization MDM EMS/MDM command
USE CASES
D1.3_SENSIBLE_Deliverable_final 62/154
3 Benchmark data gath-
ering
RTP » IG »
ASMs
RTP_info:
MGI
No_FR2
4 Computing control
commands
MDM EMS/MDM No_FR1
5 Initiation of high speed
data acquisition and
buffering
MDM »
RTP » IG »
ASM
RTP_Info No_FR2
6 Sending control com-
mands for execution
RTP » E-
Broker
RTP_Info No_FR2
7 MDM command exe-
cution
E-Brokers
» PV Plant,
Storage
system,
Loads, MGI
Command execution:
Storage system power ex-
changed Transferred PV energy Fed load
Power exchange with the
network
No_FR3
8 Suspension of high
speed data acquisition
and buffering
MDM »
RTP »
ASM
RTP Exchanged Information:
EMS/MDM commands
ASM
No_FR2
9 Sending control com-
mands for suspension
of test
MDM »
RTP
RTP Exchanged Information:
EMS/MDM commands
No_FR2
10 Data gathering RTP / IGs /
ASMs
UC_data No_FR4
USE CASES
D1.3_SENSIBLE_Deliverable_final 63/154
2.5.8 Information Exchange
Table 28 Information Exchange
2.5.9 Name of Information
(ID)
2.5.10 Description of Information Exchanged
Change_load The change in the power and, therefore, a change in the cur-
rent demanded by the load will be share among the ele-
ments of the system.
Power_loads Quantity of power fed to the demonstrator loads.
Change_PV production The change of the PV production will be detected and share
among the elements of the system.
Storage_charge The state of charge of the distributed storage system will be
shared with the rest of the elements of the system.
Power_exchanged Incoming and outcoming storage system power.
RTP_Info RTP collects real time data (measurements and status
from):
- Residential Storage Devices.
- Adevice Smart Meter (ASM) Residential & community
Power flow Import / Export.
- ASM - Node voltages around the demonstrator
- Community Storage Devices.
- EMS / MDM Commands
EMS / Meadows Data Manager
(MDM) command
The Energy Management System will send the commands
to the concerned elements of the system to maintain the sta-
bility and the quality of the service in the microgrid.
MGI This information is related to the power exchanged with the
external electrical grid in terms of quantity and quality.
ASM Measurements coming from Adevice Smart Meters
UC_data Data to be gathered after the completion of the use case:
Network Node voltages, PV export data
USE CASES
D1.3_SENSIBLE_Deliverable_final 64/154
2.6 Use Case 6: Enabling an independent energy community
2.6.1 Use Case identification
Table 29 Use case Identification
Name of the Use Case
Enabling an independent energy community
Link to demonstrators
Nottingham
Domain
Microgrid/Community
Business Key Features
Self-consumption as top priority
Simulated community automated market by means of P2P energy trading transactions
2.6.2 Scope and Objectives of the Use Case
Table 30 Short description and main objectives
Short description This use case will demonstrate that Energy Communities, which use
community energy storage, can create economic benefit for energy
consumers and can improve power quality drawn by the community to
the benefit of the network operator. Its scope covers community based
energy usage, energy re-distribution, billing and operation together with
the usage of customer flexibility within wholesale market and grid usage
optimization regarding economic cost minimisation.
Main Objectives The main aim of this use case is to demonstrate that “Community En-
ergy Storage“, together with a support ICT structure which interacts
with a high level management system, can deliver significant benefits
to both energy consumers and network operators in an electricity dis-
tribution system. The key objectives of this work are to:
• Demonstrate that customers operating as an energy community
can benefit from a real and quantifiable reduced energy cost by
improving their own consumption of local generation by moving
generated energy between community members and using a mix
of different energy storage technologies;
USE CASES
D1.3_SENSIBLE_Deliverable_final 65/154
• Demonstrate that larger community-based energy storage devices
(for example second-life electric vehicle batteries) can be more
cost effective and offer more benefit than individual energy storage
devices connected in individual residences;
• Demonstrate that community energy storage can offer improve-
ments to network operation including peak shaving, power factor
improvement, unbalance correction;
• Work with the demonstrator user communities to increase ac-
ceptance and take-up of these technologies and determine where
significant social and economic impact can be made for end-users;
Relation to other
Use Cases
UC4: Increased percentage of self-consumption
This use cases differs from UC1 and UC3 (Nuremberg demonstrator)
in the sense that UC6 aims the creation of communities for energy man-
agement and UC1 and UC3 focus on energy management at building
level.
2.6.3 Use Case Description
The main aim of this use case is to investigate issues related to the creation of an ‘Inde-pendent Energy Community‘. Rather than individual households being charged for the energy entering their property, a net cost for the community consumption (and generation where appropriate) will be considered. In this way, the community can make best (most economical and efficient) use of energy generated locally by consuming within the com-munity rather than export. The use of energy storage within the community increases the flexibility and speed of response to rapid changes in consumption and generation and can also improve the quality of power drawn by the community, as seen by the network operator. Larger communities may also have sufficient storage capability to be able to contribute power and energy to the benefit of the DSOs and TSOs. The use case will therefore look into methods, techniques and equipment, which will create a benefit at the community level with the ultimate aim of reducing energy costs. As such, the use case will need to consider:
1) The range of members of a potential community:
The majority of members will be residential with different occupancy and electricity usage patterns, different levels of rooftop PV integration, and may have embedded energy stor-age (single residence battery, export-linked domestic hot water controller). Other mem-bers may be schools (mainly daytime energy use, PV integration, little consumption dur-ing summer holidays), retail parks, office buildings etc. There will also be community owned assets e.g. community energy storage, community PV systems, community EV charging points.
USE CASES
D1.3_SENSIBLE_Deliverable_final 66/154
2) Information and Communication Infrastructure;
Users and controllable equipment will need to be monitored and controlled and linked to a Community Energy Management Platform which runs Energy Brokering software.
3) Appropriate Energy Storage
The community will employ a mix of energy storage technologies (single residence bat-tery, export-linked domestic hot water controller, community battery, flywheel, super ca-pacitor). The most economical solution considering capital cost, lifetime costs, payback, and recycling costs needs to be determined.
4) Community Energy Management Algorithm
The management algorithm has responsibility for managing all of the individual re-sources within the community, trading with the electricity wholesaler, and billing (or re-warding) individual community members for their contributions to community energy use and community energy generation. How well this algorithm functions will play a key role in making Energy Communities acceptable to all users – electricity consumers, electricity distribution system operators and electricity wholesalers.
5) Social and Economic Impact
One of the main aspects of creating an ‘energy community’ would be the way in which the members of the community interact with the technology and with each other - user acceptance is key to the success of any such scheme. An important output is to identify any change in attitude or behaviour towards the technology as a result of participation in this project.
This use case will provide data from laboratory and real-life demonstrators which can be used to investigate these five areas and in particular provide evidence to support changes in regulation where Energy Communities are currently not viable. The data may be collected from real time operation of the proposed management algorithms: alterna-tively, if live deployment is not possible (for example if permissions cannot be obtained or they contravene grid regulations) we will collect user and equipment data and create data for a virtual community which reacts to the management algorithm.
2.6.4 Use Case Story
This use case will use three processes in order to achieve its main aim of demonstrating that Community Energy Storage can deliver significant benefits to both energy consum-ers and network operators in an electricity distribution system. The processes can be defined as:
3.a. Equipment (Residential and Community) Monitoring
This process requires different rates of data monitoring depending on the required action. These actions are:
USE CASES
D1.3_SENSIBLE_Deliverable_final 67/154
Energy Monitoring (EM) focuses on the management of energy rather than power. En-ergy trading at present is operated (traded) with a half hour sample time and aims to balance supply and load across the network. For the energy monitoring and energy man-agement algorithms operating locally, a sample time of between 1min and 30s is recom-mended, and these will then interact with energy trading algorithms which will operate with a 30 min sample period. Monitored equipment here includes energy meters (resi-dential, community and in local substations where available), energy storage parameters (State of Charge, Temperature).
Power Quality Improvement (PQ) focuses on the specific issues that fast control can provide assistance with, for example, reducing transformer and cable overload (overcur-rent, unbalanced load), and maintaining voltage magnitude within limits (reducing over-voltage during periods of excess solar generation). A sampling period of 1s is appropriate but will be constrained to specific equipment which can operate locally to provide this function. Monitored equipment here includes specific voltage and current transducers or power quality meters.
High Speed Response (HSR) requires as fast as response as possible (5-10ms) for a) protection and b) extended lifetime of ES equipment (especially electrochemical). For both of these application areas then specific high speed (<1ms) data monitoring is re-quired for specific fast acting grid connected equipment. This speed is NOT required from all grid connected equipment, but will be constrained to specific equipment which can operate locally to provide this function. Monitored equipment here includes specific voltage and current transducers on power electronic interfaces or protection equipment.
3.b. Equipment (Residential and Community) Control
This process requires different rates of data monitoring and control action depending on the required actions, and the equipment to be controlled:
Energy Storage Control will focus on providing the charge and discharge capability to follow the community’s required profile from the community energy management plat-form. This communication rate here should follow the EM requirement from (1) and will act on battery charge/discharge references and domestic hot water controllers.
Power Quality Control (for specified equipment only) will communicate with a 1s sam-pling period react with the same timescale to provide mitigation for overload, unbalance and control of voltage magnitude. It will act on associated power electronic converters and potentially PV inverters (if for example curtailment is necessary). Control falling un-der this umbrella will be executed by low-level controllers with independence from the Energy Management Algorithms.
Energy Storage Optimisation (< 1ms sample rate for specified equipment only) will be constrained to protection devices, and combinations of energy storage equipment which act together to mitigate very fast fluctuations or improve component lifetime (i.e. combi-nation of battery and supercapacitor). It will act on specified power electronic interfaces or protection equipment. Control falling under this umbrella will be executed by low-level controllers with independence from the Energy Management Algorithms.
USE CASES
D1.3_SENSIBLE_Deliverable_final 68/154
3.c. Control Algorithm
The third process is the execution of the control algorithms being evaluated in order to assess its effectiveness. These are divided into two categories, namely high level control algorithm scenarios and low level control scenarios.
Scenario Test (High Level)
The high level scenarios will focus on energy management and will therefore include working closely with the community residents to learn about barriers to acceptance and user interaction in addition to the technical aspects listed below. The strategies to be deployed will include:
Improved community energy supply
This scenario will concentrate on the use of community based energy storage to re-duce the cost of the energy supply to the community. This can be achieved by shifting in time part of the electric consumption in order to:
• Use electricity in times when it is cheaper because of low demand or high renewable production
• Reduce the aggregated contractual power of the community, hence reducing electricity distribution fees
This scenario will be validated firstly by demonstrating that Armines analytics and forecasting functionality can optimally control the energy storage units but the main cost benefits will be predictions and calculations based on real-time data as current legislation and the point of metering within the community prevents real benefits from being realised. Information from this use-case will be used as evidence to help change present UK legislation.
Improved Self Consumption of Local Generation
The maximisation of the self-usage of generated PV will be examined to determine whether it is better to sell the energy to the grid supplier or to use the energy locally bearing in mind the cost of potential equipment to a user. This will be mainly ad-dressed using electrical energy storage but there will also be a limited study into domestic hot water thermal storage. The equipment to be installed in the residential houses has an inbuilt default mode which aims to maximize self-usage. A simple algorithm is typically used whereby the export to the grid is measured and the energy storage demands are then increased in order to nullify any export. This is true of both the Residential Storage Inverters (RSI) and the ImmerSUN thermal energy storage controllers. More complex self-usage algorithms will be tested using the Meadows Data Manager as the platform for controlling the energy flow of the different nodes together with the e-Broker system from GPTech. This will be especially true when looking into the maximisation of the self-usage of the community. The e-Broker hard-ware will be installed between the communications infrastructure (Integration gate-way) and the residential inverters, both PV battery and also ImmerSun. Any excess
USE CASES
D1.3_SENSIBLE_Deliverable_final 69/154
generation will be fed into the community energy store or other residential storage devices depending on the analytics being tested and business models will be gener-ated for the re-selling of energy within the community as in the ‘re-use of non-use energy‘ scenario.
Potential storage size implications will be made in conjunction with the business mod-els. Correlation between different demographical house types and needs and energy store size / cost / benefit will also be made.
Reuse of non-use energy
At some times throughout a year, the generator cannot use the energy generated (i.e. a school with PV generation, during the summer vacation) and therefore, they are forced to sell the surplus energy back to the grid. This scenario will examine how this energy can be re-sold to back to the community.
Utilizing community's/building's flexible energy position on a day-ahead energy mar-
kets
The position of a dynamic and energy intensive community/building will be managed based on the availability and capacity of exploitable storage, controllable consump-tion and the day-ahead market prices. Measurements from consumption, production and storage resources will be aggregated by the MDM to formulate an overview of the community which will then be managed optimally against the energy markets. The energy portfolio will be managed according to different goals i.e. maximizing the self-consumption of generated power or utilizing flexible tariffs and therefore mini-mizing the energy costs for the community. The functionality of the algorithms will be tested live in the demonstrator in their ability to control the resources of the commu-nity for short periods of time to prove the validity of the operation but the majority of the cost-benefit calculations and potential benefit that would have been available to the community, had there been the correct billing structure in place, will be performed off-line on post-processed data or in real-time using present demonstrator measure-ments.
3.d. Test (Low Level)
The low level scenarios will focus on power and power quality management and the strategies to be deployed will include:
Improved community energy quality
This scenario will concentrate on the use of community based energy storage to improve the quality of energy drawn from the grid and hence render the commu-nity a ‘more attractive’ energy user by usage improvements such as peak load shaving, phase imbalance correction, power factor correction. The control em-ployed here will be implemented on the Meadows Data Manager to achieve the
USE CASES
D1.3_SENSIBLE_Deliverable_final 70/154
fast sampling and control rates required from coordinated equipment – it is en-visaged that more than one grid connected power converter will contribute to this control scheme. This control will be tested both as an override and as a subordi-nate to the Community Energy Management Algorithm.
Second life battery usage
This scenario case will determine the suitability of using second life batteries (EV etc). A power converter consisting of a 3-phase grid interface together with two DC ports will be used to connect a pre-used battery together with a super-capac-itor bank. The idea being that while the batteries are capable of providing large peaks in current, their lifetime is reduced. The peaks in power to the grid will be provided using the super-capacitors. The control employed here will be imple-mented specifically within the power converter only to achieve the fast sampling and control rates required.
2.6.5 Actors
Table 31 Actors involved
Actor name Actor Type Actor Description
LV Client Systems of DSO Refers to a residential consumer (point of metering)
ADEVICE
Smart meter
Systems of DSO ADEVICE Smart meter is an power smart meter. This
equipment has remote communication capabilities for
network management, AMR (automatic meter readings),
data gathering. This equipment gives measurements of
a 3-phase power system.
ADEVICE
Smart meter
Modified ver-
sion (ASM)
Systems of DSO ADEVICE Smart meter is an power smart meter. This
equipment has remote communication capabilities for
network management, AMR (automatic meter readings),
data gathering. This equipment gives measurements of
3 individual phase nodes on a single-phase power sys-
tem. This enables the energy meter to measure genera-
tion, storage, usage and grid power variables with a sin-
gle meter.
Meadows
Data Man-
ager (MDM)
Systems of DSO It is a device which allows monitoring the state of the mi-
crogrid elements (storage system, PV solar plant, power
electronics devices, grid interface, etc). This equipment
USE CASES
D1.3_SENSIBLE_Deliverable_final 71/154
is connected to the rest of microgrid devices. It is hierar-
chically superior to the distributed control system (e-bro-
ker) so it can command it. It is the responsible for deter-
mining the operation conditions and the price range of
the sold/bought energy to the elements of the microgrid.
This hardware is also responsible as the LV Network
Controller and Data concentrator. It is able to send com-
mand and control data to the devices in the demonstrator
(inverters, controllable loads, distributed storage de-
vices) and can act as an energy management system.
This device also has the function of the management and
visualisation of the information from the demonstrator
from the smart meter infrastructure and the monitoring of
the distributed storage devices and low voltage network
and auxiliary data collected. This equipment may also be
used as a data concentrator and can be used to re-dis-
tribute data to other actors after data has been concen-
trated into a ‘virtual microgrid’. The hardware may also
be used to implement the analysis for the market driven
control and cost benefit calculation.
Community
Support Stor-
age
Systems of Com-
munity
Refers to all storage units owned by the community (fly-
wheels and electrochemical storage) with a 3 phase grid
interface
Real Time
Platform-In-
dra (RTP)
Systems of Com-
munity
Real Time Integration Platform (iSPEED) integrated plat-
form for real-time data acquisition and processing, with
the ability to handle large volumes of information at low
latency. It will act as a middleware between the DSO ser-
vices and all SENSIBLE tools.
ADEVICE
Visualisation
Tool
LV Client Tool to allow the consumer to monitor their usage / gen-
eration / storage status
Integration
Gateway (IG)
LV Client The gateway will provide the required communication,
computing and storage capabilities to integrate data and
will allow making independent the measuring process
design from the platform development.
This equipment also allows the SENSIBLE tools to send
demands to the client equipment for re-configuration and
test mode initialisation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 72/154
Residential
Storage De-
vices (RSD)
LV client Residential storage for the Meadows demonstrator cor-
responds to electrochemical storage units owned by the
consumer and connected behind the meter.
Residential
Storage In-
verter
LV client Grid tied inverter for residential storage for the Meadows
demonstrator, owned by the consumer and connected
behind the meter.
Micro-gener-
ation
LV client Corresponds to small-scale PV units connected to sin-
gle-phase LV clients.
Community-
generation
Systems of Com-
munity
Corresponds to Larger scale PV units connected to
three-phase LV clients.
Controllable
loads
LV client Corresponds to electric water heaters remotely con-
trolled through the Integration Gateway interface. Con-
nected to single-phase LV clients.
ImmerSUN LV client Refers to a single phase load controller for passive loads
which is used to control controllable loads, specifically
electric water heating but could be used for other loads,
3.3kW
LV substation Systems of Com-
munity
Refers to the LV distribution substation electrical meas-
ured values
GPTech 3
port grid in-
verter
Systems of Com-
munity
Grid inverter with two DC ports, one for a super-capacitor
interface, the remaining one for a 2nd life battery (to be
used in 2nd life battery usage sub use-case)
Energy Mar-
ket Service
Platform
Systems of Exter-
nal Roles
The platform connects the energy community with the
energy markets. The portfolio of the entire community
will be managed to utilize distributed resources accord-
ing to the market prices. The goal is to maximize the self-
consumption of the community and also minimize the en-
ergy costs. The market platform utilizes energy measure-
ments and forecasts and also flexibility forecasts to de-
termine the optimal market actions.
E-Broker HW/SW It is a distributed management and control system capa-
ble of making autonomous decisions, improving dynam-
USE CASES
D1.3_SENSIBLE_Deliverable_final 73/154
ically the quality of a microgrid or a smart grid, contrib-
uting to its stability and computing the price of the energy
to be sold or bought by the commanded element.
The system allows power exchanging, practically in real
time, between the different power devices connected to
the microgrid, without a central control system, a central
energy manager or system operator.
ARMINES
PV produc-
tion and
Building con-
sumption
forecast
Analytics provider Calculates predictions of individual distributed renewa-
ble energy production and buildings electric demand,
taking into account historical measurements and
weather forecasts. Predictions come with a confidence
level (probability density).
Once these values are available, it identifies locations
and time steps where power quality could be degraded
(voltage excursions, voltage swingsX).
For each use case, other indexes can be defined and
predicted, such as the risk of ‘non use energy’ or the risk
of ‘non self consumption’.
The output is also available for display,
ARMINES
storage man-
agement opti-
misation
Analytics provider
(verify if this actor
type is correct)
This service calculates the optimal schedules for each
battery in a portfolio in the local network taking into ac-
count constraints and objectives both at the individual
and at the aggregate level. The tool can manage multiple
objectives and prioritise them. The definition of objec-
tives and priorities will be defined for each use case:
The tool uses the forecasts produced by the ARMINES
forecast tools in order to optimise its decisions. The
schedules are then made available to each battery and
can be updated when new information (weather fore-
casts, battery availability or state of chargeX) are avail-
able.
USE CASES
D1.3_SENSIBLE_Deliverable_final 74/154
2.6.6 Steps
Fig. 22 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 75/154
Fig. 23 Sequence Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 76/154
Table 32 Use case steps for High Level Scenario
Step
nº
Name of
Process /
Activity
Main Actor Information Exchanged / process
performed
Requirements
(Req-ID)
1 Measuring
data from
the network
and Auxiliary
data collec-
tion /
weather
forecast
RTP / MDM RTP Exchanged Information:
Adevice Smart Meter (ASM)
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
No_FR6
No_FR4
No_FR7
2 Use-Case
Initialization
MDM/RSD/
CSS
Energy Management System / Mead-
ows Data Manager commands to all
controlled energy storage equipment
No_FR6
3 Computing
control com-
mands
MDM Energy Management System / Mead-
ows Data Manager commands based
on the Scenario being evaluated e.g.
where the measured data implies that
the self-consumption is no longer
possible due to a storage device be-
ing full to capacity, the MDM will cal-
culate the next best option in terms of
community based storage.
No_FR5
No_FR6
4 Sending
control com-
mands for
execution
RTP Control commands computed by
MDM are sent to appropriate Resi-
dential Storage Devices and Commu-
nity Storage Devices using the RTP.
No_FR6
5 Continuous
data moni-
toring
ASM » IG »
RTP »
MDM
MDM monitors the usage data of the
individual households as well as all
community owned components in or-
der to determine community resident
No_FR6
USE CASES
D1.3_SENSIBLE_Deliverable_final 77/154
consumption/generation profiles for
virtual billing.
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
V_grid (if available)
I_grid (if available)
P_grid (if available)
2.6.7 Pr_grid (if available)
6 Sending
control com-
mands for
suspension
of test
MDM »
RTP
RTP Exchanged Information:
- EMS / MDM commands
No_FR6
7 Data gather-
ing
RTP / IGs /
ASMs
Scenario data download and evalua-
tion
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
2.6.8 P_CG
V_grid (if available)
No_FR4
No_FR5
No_FR6
USE CASES
D1.3_SENSIBLE_Deliverable_final 78/154
I_grid (if available)
P_grid (if available)
Pr_grid (if available)
Table 33 Use case steps for Low Level Scenario
Step
nº
Name of
Process /
Activity
Main Actor Information Exchanged / process
performed
Requirements
(Req-ID)
1 Measuring
data from
the network
and Auxiliary
data collec-
tion /
weather
forecast
RTP / MDM - RTP Exchanged Information: -
Adevice Smart Meter (ASM) Res-
idential & community Power flow
Import / Export.
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
No_FR7
2 Use-Case
Initialization
MDM/RSD/
CSS
- Energy Management System /
Meadows Data Manager com-
mands to all controlled energy
storage equipment
No_FR6
3 Computing
control com-
mands
MDM Meadows Data Manager commands
based on the Scenario being evalu-
ated e.g. where overcurrent or over-
voltage are measured determining
appropriate action from CSS to miti-
gate
No_FR7
4 Sending
control com-
mands for
execution
RTP Control commands computed by
MDM are sent to appropriate Commu-
nity Storage Devices (or other specific
No_FR7
USE CASES
D1.3_SENSIBLE_Deliverable_final 79/154
power quality equipment) using the
RTP.
5 Continuous
data moni-
toring
ASM » IG »
RTP »
MDM
MDM monitors the usage data of the
community owned assets in order to
determine community power quality
improvement.
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
V_grid (if available)
I_grid (if available)
P_grid (if available)
Pr_grid (if available)
No_FR6
6 Sending
control com-
mands for
suspension
of test
MDM »
RTP
RTP Exchanged Information:
Energy Management System /
Meadows Data manager com-
mands
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
V_grid (if available)
I_grid (if available)
No_FR6
USE CASES
D1.3_SENSIBLE_Deliverable_final 80/154
P_grid (if available)
Pr_grid (if available)
7 Data gather-
ing
RTP / IGs /
ASMs
Scenario data download and evalua-
tion
P_LVC
Pr_LVC
P_LVC_loads
Pr_LVC_loads
P_LVC_storage
SoC_LVC
P_LVC_ImmerSUN]
SoC_CSS
P_CSS
Pr_CSS
P_CG
V_grid (if available)
I_grid (if available)
P_grid (if available)
Pr_grid (if available)
No_FR7
Table 34 Use case steps for Evaluation of Social Acceptance and Interaction
Step
nº
Name of
Process /
Activity
Main Actor Information Exchanged / process
performed
Requirements
(Req-ID)
1 Dissemina-
tion Event –
project start
UNOTT/MO
ZES-End
Users
Details of Project to demonstrator
based end-users
No_NFR16,
No_NFR13,
No_NFR12,
No_NFR11,
No_NFR10
2 End user In-
teraction -
deployment
UNOTT/MO
ZES/Equip-
ment Pro-
viders –
End Users
Details of equipment to be deployed No_NFR16,
No_NFR13,
No_NFR12,
No_NFR11,
No_NFR10
USE CASES
D1.3_SENSIBLE_Deliverable_final 81/154
3 End user in-
teraction –
continuous
dialogue
UNOTT/MO
ZES – End
Users
Information pertaining to equipment
usage, potential benefits, problems,
acceptance, behaviour.
No_NFR16,
No_NFR13,
No_NFR12,
No_NFR11,
No_NFR10
4 Dissemina-
tion Event –
project end
UNOTT/MO
ZES-End
Users
Details of Project results and findings
to demonstrator community
No_NFR16,
No_NFR13,
No_NFR12,
2.6.9 Information Exchange
Table 35 Information Exchange
Name of Information (ID) Description of Information Exchanged
[V_grid] Voltage in the LV Substation Per Phase - Measured in the LV
side of the substation.
[I_grid] Current in the LV Substation Per Phase (including Neutral) -
Measured in the LV side of the substation.
[P_grid] Per Phase Real Power imported/exported at the LV Substation
- Measured in the LV side of the substation.
[Pr_grid] Reactive Power imported/exported at the LV Substation Per
Phase - Measured in the LV side of the substation.
[SoC_CSS] Current state of the charge (SoC) of the Community Support
Storage devices
[P_CSS] Real Power absorbed/injected by the Community Support Stor-
age devices Per Phase
[Pr_CSS] Reactive Power absorbed/injected by the Community Support
Storage devices Per Phase
[P_CG] Power injected by the Community Generation devices Per
Phase
[P_LVC] Power export/import by the LV Client devices
USE CASES
D1.3_SENSIBLE_Deliverable_final 82/154
[Pr_LVC] Power (reactive) export/import by the LV Client devices
[P_LVC_loads] Power export/import at the distribution node of the LV Client de-
vices
[Pr_LVC_loads] Power (reactive) export/import at the distribution node of the LV
Client devices
[P_LVC_storage] Power export/import of the residential storage node of the LV
Client devices
[SoC_LVC] Current state of the charge (SoC) of the Residential Storage
devices of the LV Client
[P_LVC_ImmerSUN] Power usage of the ImmerSUN node of the LV Client devices
USE CASES
D1.3_SENSIBLE_Deliverable_final 83/154
2.7 Use Case 7: Microgrid energy market
2.7.1 Use Case identification
Table 36 Use case Identification
Name of the Use Case
Microgrid energy market
Link to demonstrators
Nottingham
Domain
Microgrid / Community
Business Key Features
Self-consumption as top priority
Grid supply used as backup (Islanding operation mode most of times)
Simulated community automated market by means of P2P energy trading transactions
2.7.2 Scope and Objectives of the Use Case
Table 37 Short description and main objectives
Short description In this use case, we will present a situation where the system will have
to manage the microgrid power producers and consumers according to
the microgrid internal energy market. In this use case, the system will
have to comply with the microgrid energy market constraints as well as
with the technical constraints (microgrid stability and power quality).
Main Objectives Show the capacity of the Energy Management System, the Real Time
Integration Platform and the e-Broker system to manage the different
power sources and power consumers while creating a common energy
market.
Relation to other
Use Cases
Microgrid PV Management
USE CASES
D1.3_SENSIBLE_Deliverable_final 84/154
2.7.3 Use Case Description
The goal of this use case is to show the capacity of the system of creating an internal energy market and to comply with the technical requirements. In this scenario, we will see how the different elements of the system (distributed storage system, distributed PV plant, Real Time Integration Platform, Energy Management System and the e-brokers) communicate among themselves and how they agree on the power transfers and the price of the energy.
The system will always look for the best economical solution while assuring that the technical requirements are met (microgrid stability and energy quality).
The main devices and systems taking part in this use case are:
• Distributed PV generation plant: it is composed of PV panels located in different properties where the Nottingham demonstrator is located.
• Distributed storage system consists of batteries located in Nottingham demon-strator’s facilities.
• Energy Management System (EMS): it is a device which allows monitoring the state of the microgrid elements (storage system, PV solar plant, power electron-ics devices, grid interface, etc.).
• E-Broker: it is a distributed management and control system.
• Integration Gateway (IG): Required HW/SW to ensure communication and inter-faces the E-broker and the Real-time platform.
• Real Time Integration Platform: it is a platform which allows sharing the infor-mation among the elements of the microgrid.
• Microgrid load: load to be fed by the microgrid power sources • Grid: it represents the main grid.
2.7.4 Use Case Story
The phases composing this use case are chronologically exposed and described below:
The e-broker responsible for some elements of the system (storage system, PV plant, load, microgrid-grid interface) are periodically sending reports to the RTP through the IG as well as commanding those elements, determining the power transfers and the selling and buying price of the energy.
The information sent by the e-brokers to the RTP will be read by the EMS and it will determine the operation conditions of the system elements and a range of energy prices. EMS commands will be submitted to the RTP.
The e-brokers will have access to the EMS commands through the RTP and the IG. They will coordinate among themselves to decide on the energy transfers.
An example of power transfer, the load demands have to be satisfied. Then the e-brokers will decide how to supply the load. The load can be fed by the energy produced by the PV plant or by the stored energy or by the energy purchased to them electrical grid. The
USE CASES
D1.3_SENSIBLE_Deliverable_final 85/154
e-brokers will select the best choice depending on technical aspects (PV production, state of charge of the batteries, microgrid stability and energy quality) and also depend-ing on economic aspects (selling and buying price of the energy, this prices are set by the e-brokers according to the price ranges commanded by the EMS).
Another example could be the situation in which there is a surplus of PV production. The system will have to decide what to do with the energy surplus. This excess of energy could be either stored or sold. This decision will be made depending, as in the previous example, on technical (state of charge of the storage system, etc.) and economic aspects (is selling the energy to the grid more profitable than storing it?).
This use case we will demonstrate the capabilities of the SENSIBLE system to manage a microgrid energy market.
Fig. 24 Use case Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 86/154
2.7.5 Actors
Table 38 Actors involved
Actor name Actor Type Actor Description
Load E-Bro-
ker
HW/SW It is a distributed management and control system capable of
making autonomous decisions, improving dynamically the
quality of a microgrid or a smart grid, contributing to its stability
and computing the price of the energy to be sold or bought by
the commanded element.
The system allows power exchanging, practically in real time,
between the different power devices connected to the mi-
crogrid, without a central control system, a central energy
manager or system operator.
Energy Man-
agement Sys-
tem
HW/SW It is a device which allows monitoring the state of the microgrid
elements (storage system, PV solar plant, power electronics
devices, grid interface, etc). This equipment is connected to
the rest of microgrid devices. It is hierarchically superior to the
distributed control system (e-broker) so it can command it. It
is the responsible for determining the operation conditions and
the price range of the sold/bought energy to the elements of
the microgrid.
Real Time In-
tegration Plat-
form
HW/SW It is a platform which allows sharing the information among the
elements of the microgrid.
Integration
Gateway (IG)
HW/SW The gateway will provide the required communication, com-
puting and storage capabilities to integrate data and will allow
making independent the measuring process design from the
platform development.
ADEVICE
Smart meter
Modified ver-
sion (ASM)
Systems of
DSO
ADEVICE Smart meter is an power smart meter. This equip-
ment has remote communication capabilities for network man-
agement, AMR (automatic meter readings), data gathering.
This equipment gives measurements of 3 individual phase
nodes on a single-phase power system. This enables the en-
ergy meter to measure generation, storage, usage and grid
power variables with a single meter.
USE CASES
D1.3_SENSIBLE_Deliverable_final 87/154
Distributed
Storage Sys-
tem E-Broker
HW/SW The distributed storage system is compound of real-model
batteries.
As a bidirectional device, the battery simultaneously partici-
pates in the exchanges of power as a consumer and a pro-
ducer. Its offer and demand power value depends on its own
state of charge (SoC) so as to keep a convenient health state
of the device.
The produced or consumed total power by this device is small
so the influence of the battery over the global behaviour of the
microgrid is practically negligible.
Distributed
Photovoltaic
Plant E-Bro-
ker
HW/SW The photovoltaic solar plant is a system mainly compound of
different solar arrays of photovoltaic panels located in the
properties of the Nottingham Demonstrator and a certain num-
ber of inverters. The aim of the PV plant is to provide electric
power to the microgrid.
It starts providing power at dawn. The power available de-
pends on the irradiance in the photovoltaic panels. The pro-
duced power increases over time and reaches the maximum
value about 15:00 hours. Then the value of power decreases
until the sunset when the available power falls to 0.
As it is a renewable source of power and due to its nature, this
device always has a high value of priority and it is normal that
its offers achieve exchange agreements, that is to say, it is
usual that the entire power produced is consumed (or stored
by a storage system).
Load
E-Broker
HW/SW It represents the entire consumption of the microgrid. It could
be represented as an intelligent building, an office building, a
business park, a residential area, city lighting, etc. It is overall
presented as the load of the microgrid. The demands and the
established prices depend on the consumption during the dif-
ferent hours of the day and some events which are described
in detail in the storyline.
Microgrid –
Grid Interface
E-Broker
Facility It represents the point of interconnection or the point of com-
mon coupling (PCC) between the microgrid and the main grid.
At this point, the associated intelligent device manages this
interface, that is to say, for the e-Broker system the main grid
is just another system with the same sort of parameters to
participate in the power exchanges.
USE CASES
D1.3_SENSIBLE_Deliverable_final 88/154
For this use case, the local consumption (exchanges) of
power is considered a priority when possible. In general, if
there is an excess of produced power in the microgrid it is sold
to the grid. Similarly, the power of the main grid will be pur-
chased if the power generated in the microgrid is not enough
to supply itself or if between the microgrid devices have not
been achieved economic agreements.
2.7.6 Steps
Fig. 25 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 89/154
Fig. 26 Sequence Diagram
Table 39 Use case steps
Step
nº
Name of
Process / Ac-
tivity
Main Ac-
tor
Information Exchanged / process per-
formed
Require-
ments
(Req-ID)
1 Measuring data
from the net-
work and Auxil-
iary data collec-
tion / weather
forecast
RTP /
MDM
RTP Exchanged Information:
- Change in the load demands
- Change in the PV production
- PV energy selling price.
- State of charge of the storage system
- Storage system power exchanged.
- Stored energy buying-selling price.
- Supplied power to loads
No_FR2
USE CASES
D1.3_SENSIBLE_Deliverable_final 90/154
2 Use-Case Ini-
tialization
MDM - Energy Management System / Mead-
ows Data manager commands
No_FR1
3 Benchmark
data gathering
RTP » IG »
ASMs
RTP Exchanged Information:
- Microgrid-Grid interface
No_FR2
4 Computing con-
trol commands
MDM Energy Management System / Meadows
Data manager commands:
- Power transfers
- Selling and buying Energy prices
No_FR1
5 Initiation of high
speed data ac-
quisition and
buffering
MDM »
RTP » IG »
ASM
RTP Exchanged Information:
- Energy Management Sys-tem /
Meadows Data manager com-
mands
No_FR2
6 Sending control
commands for
execution
RTP » E-
Broker
RTP Exchanged Information:
- Energy Management Sys-tem /
Meadows Data manager com-
mands:
- Power Transfers
- Selling and buying Energy prices
No_FR2
7 MDM command
execution
E-Brokers
» PV Plant,
Storage
system,
MG inter-
face
Command execution:
- Storage system power ex-
changed - Transferred PV energy - Fed load - Power exchange with the net-
work
No_FR3
8 Suspension of
high speed data
acquisition and
buffering
MDM »
RTP »
ASM
RTP Exchanged Information:
- Energy Management Sys-tem /
Meadows Data manager com-
mands
No_FR2
9 Sending control
commands for
suspension of
test
MDM »
RTP
RTP Exchanged Information:
- Energy Management System /
Meadows Data manager com-
mands
No_FR2
USE CASES
D1.3_SENSIBLE_Deliverable_final 91/154
10 Data gathering RTP / IGs
/ ASMs
Use case data downloading No_FR3,
No_FR4
USE CASES
D1.3_SENSIBLE_Deliverable_final 92/154
2.7.7 Information Exchange
Table 40 Information Exchange
Name of Information (ID) Description of Information Exchanged
Change_load The change in the power and, therefore, a change in the cur-
rent demanded by the load will be share among the elements
of the system.
Power_loads Quantity of power fed to the demonstrator loads.
Change_PV production The change of the PV production will be detected and share
among the elements of the system.
PV_price Selling price for the PV produced energy. It will be agreed by
the EMS and the E-brokers.
Storage_charge The state of charge of the distributed storage system will be
shared with the rest of the elements of the system.
Power_exchanged Incoming and outcoming storage system power.
Stored_price Buying and selling price for the stored energy. These prices
will be agreed by the EMS and the E-brokers.
RTP_Info RTP collects real time data (measurements and status from):
- Residential Storage Devices.
- Adevice Smart Meter (ASM) Residential & community
Power flow Import / Export.
- ASM - Node voltages around the demonstrator
- Community Storage Devices.
- EMS / MDM Commands
EMS / MDM command The Energy Management System will send the commands to
the concerned elements of the system to maintain the stability
and the quality of the service in the microgrid.
Com_exe E-brokers will command the plant devices so as to carry out
EMS/MDM commands.
MGI This information is related to the power exchanged with the
external electrical grid in terms of quantity and quality.
UC_data Data to be gathered after the completion of the use case:
Network Node voltages, PV export data
USE CASES
D1.3_SENSIBLE_Deliverable_final 93/154
2.8 Use Case 8: Optimizing the MV Distribution Network Operation using available storage resources.
2.8.1 Use Case identification
Table 41 Use case Identification
Name of the Use Case
Optimizing the MV Distribution Network Operation using available storage resources.
Link to demonstrators
Évora
Domain
Grid Operation
Business key features
Storage used for MV and LV operation optimization
Participation of independent actors (DER aggregators, services provider, etc.)
Power Quality and Continuity of Service
2.8.2 Scope and Objectives of the Use Case
Table 42 Short description and main objectives
Short description The scope is the optimization of MV Distribution Network Operation by
using available storage resources with effectiveness on the MV network
side.
Two separate scenarios are considered:
1. Comprehensive (simulated) scenario:
This approach is assuming the presence of a more evolved smart grid
that represents a realistic approach in the mid/long term European con-
text. In this scenario, simulated MV grid data based on real grid infor-
mation will be generated and the grid optimization will take both tech-
nical and economic aspects into consideration.
USE CASES
D1.3_SENSIBLE_Deliverable_final 94/154
In this context, the approach requires a high-level management per-
spective, in which the overall MV grid will be monitored at least covering
the network supplied by one HV/MV substation.
In such approach the storage resources might be either:
• devices directly connected to the MV network, or
• inside MV/LV substations (both MV or LV side), property of DSO or
provided by others agents (who have a contractual agreement to
provide these type of services), or
• the aggregated storage capability of devices connected to both the
LV and MV sides of the network, whose aggregated effect is pro-
vided by a unique coordination agent.
2. Particular (real) scenario:
This scenario represents a particular case of the previous one consid-
ering the real site conditions of Évora demonstrator. Real data and a
real storage resource (connected to a client substation on the MV bus)
will be used and the analysis will be mainly focused on the technical
aspects of the grid operation optimization. In this real case, the DSO
owns the storage unit. However, a scenario where the storage unit is
owned by a third party can also be addressed without any modification,
assuming that a bilateral agreement between DSO and owner is in place
(i.e., regulated service).
Main Objectives The main objective shared by both scenarios is the centralized control
of storage resources, at least at the SCADA/DMS level, in order to as-
sure operation of the MV voltage within technical limits, and thus opti-
mize its operation in a flexible and quantifiable way (minimize technical
losses, maximize load balance between feeders, minimize distance to a
predefined optimal voltage profile).
Another key objective fully expressed in the first scenario, will be the
technical and economic assessment of the different types of storage
technologies used in the project (with different technical characteristics
and costs) relative to other available controllable resources in the MV
network (tap changers, controllable distributed generation and loads,
capacitors, STATCOM devices, voltage regulators, etc. and also net-
work reconfiguration options), with which the same operation optimiza-
tion might be achieved.
Relation to other Use
Cases
Not Applicable
USE CASES
D1.3_SENSIBLE_Deliverable_final 95/154
2.8.3 Comprehensive simulated scenario
2.8.3.1 Use case Description
The use case consists in a real time control of storage resources and other available controllable resources in order to provide a safe and optimized network operation, both in present and in near future time (preventive control).
The storage resources available could be from different origins and properties:
• Storage devices property of DSO, directly connected to the MV network of the MV side of MV/LV substations.
• Storage devices property of third parties, but available for DSO operation by means of some specific bilateral contractual agreement between these third parties and the DSO.
• Storage resources comprising a number of devices property of different own-ers, but managed by an independent agent (aggregator) and made available for DSO operation also by means of some bilateral contractual agreement with the DSO.
In all previous cases, the storage resources will be managed the same way regarding the MV network operation. The selection among them will depend on technical re-quirements of the network operation (technical problem to solve), technical charac-teristics of each resource, and an economic balance within the algorithm depending on the cost of each one.
The control function must be accomplished by a real time analytics module that pro-vides:
• Current network and controllable devices static status (from the DMS through INDRA’s RT Integration Platform)
• Current estimated state (from measurements – from the DMS through IN-DRA’s RT Integration Platform – and real time DSE function over them)
• Short-term load and generation forecast that supports preventive control.
• Scheduling of calls to the algorithms that compute the needed control.
• Algorithms that compute the needed control that include, among others, OPF optimization capabilities.
• Mechanism to publish control outputs (proposed commands – to the DMS through INDRA’s RT Integration Platform).
USE CASES
D1.3_SENSIBLE_Deliverable_final 96/154
The set of algorithms that computes the control function must be developed taking into account:
• Different objective functions depending on network situation (network operat-ing within the technical limits or not).
• When the network is operating within technical limits:
o Different objective functions will be available for Operator selection. The flexibility of these options will be defined in the detailed design of the use case, but at least the following ones will be considered:
� Minimizing technical losses.
� Minimizing distance to a predefined optimal voltage profile, and
� Combinations between the previous.
o Regardless of the technical objective function selected, the economic factor will be taken into account. In this sense, the objective function itself will compute a balance between the use of the available re-sources and their cost and benefits of potentially achieved technical optimization.
o Every time a command is sent to a storage device the response of the device will be monitored, in order to determine if it’s meeting a prede-fined expected behaviour. When the expected behaviour is not achieved, and under certain conditions to be defined, the device will be considered under failure state, and will no longer be used for further optimizations while this condition is maintained. In case the device is owned by a third party or it is an aggregator, this circumstance will be registered, and into account in final payment computation for the ser-vice.
• When the network is not operating within technical limits (emergency mode operation) the objective function will have the absolute priority of leading the network to normal operation in the shortest term possible. In this sense, nei-ther economic nor technical considerations used in normal operation will be taken into account: all the resources available could be used, and the main drivers for selection and coordination strategy will be response speed and sustainability in time.
• In addition, a preventive control will be computed periodically, when the short-term load forecast (also computed in the DSO_Analytics), along with present operation conditions suggest a high risk happening of an emergency mode
USE CASES
D1.3_SENSIBLE_Deliverable_final 97/154
operation in near future. This preventive control will be focused on detecting a relation between the operation conditions and the risk, and will react by changing them to less risky conditions.
• Although this use case is focused on storage resources, in order to demon-strate their potential, it must be taken into account that this storage will be incorporated as new resources for general OPF functions, which are previ-ously available using other types of controllable resources. Therefore, algo-rithms must be designed to potentially use different types of resources and not only the storage ones. In this sense, the use case will be useful also to show possible coordination strategies between the different resources.
In order to provide a realistic economic balance in the objective function, a previous task of the economic modelling research need to be performed. This task comprises the anal-ysis and design of the identified potential contractual conditions required between ser-vice providers (individual or aggregators) and DSO and also the need of a cost model for DSO own resources.
2.8.3.2 Use Case Story
Fig. 27 Use case Story Diagram and involved actors
USE CASES
D1.3_SENSIBLE_Deliverable_final 98/154
2.8.3.3 Actors
Table 43 Actors involved
Actor name Actor Type Actor Description
Real Time Analytics
Platform (DSO_An-
alytics INDRA)
Systems of
DSO
DSO_Analytics is a software platform that provides
complex computation services for the DMS using ad-
vanced software technologies (native language, HPC,
etc.). It operates in standalone architecture. The inter-
face with the others actors (information exchange and
computation control) is provided by RT platform.
Distribution Man-
agement System
(DMS INDRA)
Systems of
DSO
DMS is the main platform for DSO monitoring and con-
trol of the distribution network. In order to fulfil its func-
tion, it relies on DSO_Analytics for complex computa-
tion and RT platform for information exchange.
Real Time Platform
(RTP INDRA)
Systems of
DSO
Real Time Integration Platform (iSPEED) integrated
platform for real-time data acquisition and processing,
with the ability to handle large volumes of information at
low latency. It will act as a middleware between the
DSO services and all SENSIBLE tools.
Real Time Network
Simulator (OTS IN-
DRA)
Systems of
DSO
OTS is a real time network simulator that can be used
to simulate any network conditions, including failure
conditions in the network itself or in the information pro-
vided
MV Storage devices DSO / Third
parties
MV Storage resources are the storage resources that
will be available for operation from DSO, either in MV
network itself or in MV/LV substations. They are defined
by their technical characteristics and their usability con-
ditions in economic terms.
Storage resources
from aggregator
Storage ser-
vices Aggre-
gator
Storage resources from aggregators are the storage ca-
pabilities available for usage from DSO, that are com-
posed by individual contributions of several storage de-
vices coordinated by aggregator, which provides to
DSO some resulting technical and economic condi-
tions.
VoltVAr control de-
vices
DSO VoltVAr control devices are the set of devices useful for
voltage control available for operation from DSO, others
USE CASES
D1.3_SENSIBLE_Deliverable_final 99/154
than storage resources: tap changers, STATCOM, con-
densers, generation, etc.
Network Instrumen-
tation
DSO Set of measurement devices spread along the MV net-
work together with devices inside HV/MV and MV/LV
substations. In this scenario, the measurements are
simulated and provided by OTS. In real scenario, these
measurements are provided mainly from SCADA and
also from other sources.
Net-load forecast
tool
Statistical-based tool that produces point forecasts of
the net-load in each secondary substation and MV cli-
ent.
USE CASES
D1.3_SENSIBLE_Deliverable_final 100/154
2.8.3.4 Steps
Fig. 28 Activity Diagram
Ok
OffAssess devicecommunicationstatus
5.2 Exclude from listof available resources
No
3.3 Perform preventive actions
YesP > threshold?
No
3.2 Calculate probabilityof grid emergencyin the mid-term (P) No Yes
3.1 Perform emergency algorithm
Grid in emergency status?
Load algorithm parametrization
Start
End
5.3 Proceed with customer liquidations
In line with commands sent?
Yes
5.1 Monitoring of command responses
5. Monitoring of RT storage devices response
4.3 Execution of manualcontrol commands
No
Confirm execution?
Yes
4.2 Execution of automaticcontrol commands
4.1 Processing of manual control commands
4. Processing control commands
3.5 Resulting control commands
3.4 Perform technical and economic
optimization
3. Computing control commands
2. Computing network status
1. Measuring Data
2.1 DSO data validation
1.2 Measurenet-load forecast
(Retrieved from ARMINESforecast tools)
1.1 Measure data from the network
(Real data from SCADA,simulated data from OTS)
USE CASES
D1.3_SENSIBLE_Deliverable_final 101/154
The steps of the use case are described in the following table:
Table 44 Use case steps
Step
nº
Name of
process/Activ-
ity
Main
Actor
Information Exchanged Requirements
(Req-ID)
1 Measuring data
from the net-
work and net-
load forecast
RTP RTP collects real time data (meas-
urements and status from):
- DSO Storage Devices.
- DSO VoltVAr control Devices.
- Aggregator of Storage Devices.
- Third Party Storage Devices.
- Network instrumentation.
RTP also provides net-load fore-
cast computed by ARMINES pre-
diction system.
FR_UC8_ 4
2 Computing net-
work status
DSO_A
nalytics
DSO_Analytics computes the cur-
rent estimated state of the whole
network by means of the DSE pro-
cess that validates received date
(making it consistent) and close
gaps by estimating data not avail-
able .
FR_UC8_3
3 Computing con-
trol commands
DSO_A
nalytics
DSO_Analytics computes the
needed control commands to
achieve technical and economic
optimized network operation, tak-
ing into account present network
state and different available con-
trol devices.
FR_UC8_5
4 Sending control
commands for
execution/vali-
dation
DMS Control commands computed by
DSO_Analytics are sent to DMS
by means of RTP, so they are
available for DMS.
FR_UC8_5,
FR_UC8_6
FR_UC8_7
FR_UC8_8
5 Monitoring of
real time stor-
age devices re-
sponse
DSO_A
nalytics
Response to commands of control
devices is monitored by DSO_An-
alytics, and compared with ex-
pected response.
FR_UC8_1
FR_UC8_2
USE CASES
D1.3_SENSIBLE_Deliverable_final 102/154
2.8.3.5 Information Exchange
Table 45 Information Exchange
Name of Information (ID) Description of Information Exchanged
Measurements Real time measurements available in the network (real or
simulated), including at least electrical measurements,
state of switching elements, and any other information re-
quired or available (tap changers states, level of load of
storage devices/resources, present capacitors step, etc.)
Third party storage resources
availability
List of resources available with their technical character-
istics, time availability and economic information.
The Economic information related with the storage ser-
vices provided by different actors (DSO, third parties, ag-
gregators) will be composed as a result of:
- The set of potential type of contractual conditions be-
tween service providers (individual or aggregators)
and DSO that will be designed within the project.
- A cost model for DSO own resources.
Static network data Physical characteristics of the network and the devices
connected. This information comprises the complete con-
figuration of the topology of the network detailing all nodes
and lines, the equipment (transformers, switching ele-
ments, control devices, storage elements, etc.) and their
technical characteristics (power, impedances, discharge
curves, etc.).
Data suitable for Load characterization (historic consump-
tions, typical load curves, distribution of customer typolo-
gies, etc.)
Control Commands Results of the control function in terms of proposed com-
mands for the different resources.
2.8.4 Particular real scenario
2.8.4.1 Use Case Description
In this second scenario, a storage device connected to a secondary substation from a client (on
the MV side) will be used to improve distribution network operation. In this case, the objective is
to understand, with field tests, how the DSO can control the storage device for grid support and
USE CASES
D1.3_SENSIBLE_Deliverable_final 103/154
measure important Key Performance Indicators such as network losses and voltage profiles. A
MV Storage Optimization Tool is responsible for managing the local storage unit connected to the
MV/LV substation. This storage device has two objectives: (a) reserve capacity to support conti-
nuity of service of an installation (or building) and (b) the remaining capacity used for grid support.
The regulatory framework assumes that the DSO owned storage is installed at the MV side of the
clients MV/LV substation in order to ensure power quality of supply and continuity of service.
The first step of the MV Storage Optimization Tool consists in estimating the available storage
capacity that can be used for grid support, by considering the forecasted load of the installation.
Based on the forecasted load and corresponding uncertainty, the risk of not having sufficient
backup capacity is calculated and the required storage capacity is defined based on the preferred
risk (defined by the DSO).
The MV Storage Optimization Tool will optimize the storage operating strategy for a pre-defined
time horizon (e.g., next hours, day) in order to minimize the power losses and operating costs
(including degradation costs if available), while respecting the technical constraints of the network
and considering the future states of the MV grid.
The outputs provided are the operating strategy of the storage devices for the next hours/day.
This output generates a set of control set-points for the storage steady-state operation.
2.8.4.2 Use Case Story
Fig. 29 Use case Diagram with involved actors
USE CASES
D1.3_SENSIBLE_Deliverable_final 104/154
2.8.4.3 Actors
Table 46 Actors involved
Actor name Actor Type Actor Description
Distribution Trans-
former Controller –
DTC
Systems of
DSO
DTC is a local control equipment located at the second-
ary substation level, comprising components for meas-
urement, remote control, and communication actions.
Its main functions are collecting data from smart meters
and MV/LV substation, data analysis functions, grid
monitoring, and interface with commercial and technical
central systems.
Distribution Man-
agement System
(DMS INDRA)
Systems of
DSO
DMS is the main platform for DSO monitoring and con-
trol of the distribution network. In order to fulfil its func-
tion, it relies on DSO_Analytics for complex computa-
tion and RT platform for information exchange.
Real Time Platform
(RTP INDRA)
Systems of
DSO
Real Time Integration Platform (iSPEED) integrated
platform for real-time data acquisition and processing,
with the ability to handle large volumes of information at
low latency. It will act as a middleware between the
DSO services and all SENSIBLE tools.
MV Storage device DSO / Third
parties
Modular stationary energy storage and power flow man-
agement system that combines fast-acting power regu-
lation function and high performance lithium-ion batter-
ies. The components of the storage system are inte-
grated into a 40´container E-House.
EMS – MV Storage
management sys-
tem
DSO / Third
parties
Management system of the storage unit connected to
the MV side.
Net-load forecast
tool
Statistical-based tool that produces point forecasts of
the net-load in each secondary substation and MV cli-
ent.
SCADA Systems of
DSO
SCADA is the main DSO system that provides real time
measurements collected in RTP and allow sending
commands to different devices.
USE CASES
D1.3_SENSIBLE_Deliverable_final 105/154
2.8.4.4 Steps
Fig. 30 Activity Diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 106/154
1.1. Access to DMS database (static data) and RTP (dynamic data)
The DSO sends a request to exchange information with the DMS database and RTP so that it can retrieve data to run the optimization tool.
1.2. Retrieve grid current state of operation
The state of operation refers to the current state of the network equipment (including the storage unit), such as MV/LV transformers tap position, capacitor banks, HV/MV OLTC. This dynamic data is retrieved from the RTP and it is combined with the static data from the DMS database (i.e., hierarchy of the network and location of the network equipment). From this information, the current network topology is defined.
1.2.1. Use previous data / perform a state estimation
When the dynamic information coming from 1.2 is for some reason not accessible or erroneous, the DSO uses past but similar information (e.g., for a given hour the DSO uses the correspondent data for the last comparable day – same day of the week, same hour, past week).
Another possible solution is to use a state estimation algorithm in order to find the values for a set of variables (states) that adjust in a more adequate way to a set of network values (measurements) that is available from the network (e.g., AMI, Remote Terminal Units (RTUs), current and voltage transformer). The state variables are such that all the other network variables can be evaluated from them, and the operation state is obtained.
1.3. Access forecasting information from the RTP
The DSO sends a request to exchange forecasting information with the RTP so that it can retrieve data for the optimization algorithm.
1.4. Retrieve nodal forecasted data for the MV network
The DSO retrieve forecasting information from the RTP regarding the nodal active power values (at the MV network level) expected for the time horizon that is being considered.
1.4.1. Use previous forecasts
If, for some reason, the most recent forecasts are not available at the RTP, the DSO uses the previous forecasts (performed in the previous hours for the same period). In fact, these forecasts are less accurate but they still guarantee the success of the optimi-zation process. This forecast data also includes the demand profile of the installation where the storage unit is providing support.
1.4.2. Generate probabilistic profile for the installation
A probabilistic forecast (set of quantiles) is generated for the demand profile of the in-stallation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 107/154
1.5. Estimate the available storage capacity
Estimate the available storage capacity that can be used for grid support, by considering the forecasted load of the installation. Based on the forecasted load and corresponding uncertainty, the risk of not having sufficient backup capacity is calculated and the re-quired storage capacity is defined based on the preferred risk (defined by the DSO).
1.6. Include the available storage capacity in the optimization
After calculating the risk of not supplying the demand profile, the available storage ca-pacity is included as a constraint in the optimization tool function.
1.7. Perform the storage optimization
The optimization tool, considering the input data available, will seek the optimization of the defined objective function (e.g., minimize active losses, improve voltage profiles, etc.).
Upon receiving the necessary input data, the optimization algorithm is run for a pre-specified time horizon (e.g., next hours, day) taking into account technical constraints such as:
� Admissible range for voltage magnitudes at the network buses;
� Maximum allowable current for branches;
Outputs Description
The output of the optimization tool consists in an operating strategy of the storage de-vices for the next hours/day. This output generates a set of control step-points for the storage steady-state operation.
1.8. Send set-points to the storage unit
Using the SCADA/DMS the DSO sends the set-points to the storage control devices and that cover the 24 hours of the next day.
USE CASES
D1.3_SENSIBLE_Deliverable_final 108/154
2.8.4.5 Information Exchanged
Table 47 Information Exchange
Name of Information (ID) Description of Information Exchanged
MV Load Forecast Net-load forecasts for each node of the MV grid (from AR-
MINES prediction system) of the installation that uses stor-
age as backup.
MV storage SOC Current state of the charge (SoC) of MV storage devices
MV Active and Reactive
Power
Active power measurements (by phase) from MV clients,
storage and secondary substation
MV voltage Voltage in the primary substation (measured in the MV
side)
MV storage reserve Required storage reserve capacity
Static network data Physical characteristics of the network and the devices
connected. This information comprises the complete con-
figuration of the topology of the network detailing all nodes
and lines, the equipment (transformers, switching ele-
ments, control devices, storage elements, etc.) and their
technical characteristics (power, impedances, discharge
curves, etc.).
Historical data for the following variables:
• Active and reactive power values measured in the
MV bus of the secondary substations (MV/LV
nodes) with a 15 minutes time resolution;
• Active and reactive power consumption of clients
connected to the MV nodes with a 15 minutes time
resolution;
• Status of the network equipment (transformers,
switching elements, control devices, storage ele-
ments, etc.)
Control Commands Results of the control function in terms of proposed com-
mands for the storage unit.
USE CASES
D1.3_SENSIBLE_Deliverable_final 109/154
2.9 Use Case 9: Optimizing the operation of storage devices in the LV distribution network
2.9.1 Use Case identification
Table 48 Use case Identification
Name of the Use Case
Optimizing the operation of storage devices in the LV network
Link to demonstrators
Évora
Domain
Grid Operation
Business key features
Storage used for MV and LV operation optimization
Participation of independent actors (DER aggregators, services provider, etc.)
Integration of new markets (ancillary services)
Power Quality and Continuity of Service
2.9.2 Scope and Objectives of the Use Case
Table 49 Short description and main objectives
Short description The scope is LV distribution network operation together with optimal op-
eration of storage devices connected directly to LV grid or central storage
systems connected at the level of the secondary substation (MV/LV) but
that are property of the Distribution System Operator.
Main Objectives The main goal is to manage local distributed storage devices in order to
solve technical problems in the LV grid (namely related to voltage issues)
and minimize technical losses. The storage devices are to be coordi-
nated with renewable generation at the LV level as well as with demand
side management schemes, considering residential storage and control-
lable loads.
USE CASES
D1.3_SENSIBLE_Deliverable_final 110/154
Relation to other
Use Cases
UC 11: Microgrid Emergency Balance Tool
2.9.3 Use Case Description
This use case describes the optimization of the LV network by exploring its different flexibilities, such as storage connected to the distribution network feeders and secondary substation, as well as Home Energy Management Systems (HEMS).
The DSO has the possibility of controlling its own storage devices that are directly con-nected to the distribution grid. Furthermore, the HEMS allows for additional flexibility. The HEMS is able to calculate, based on current controllable load devices and residential storage devices’ State of Charge, the flexibility bands that can be used by the DSO.
Making use of the Distribution Management System (DMS) the DSO is able to retrieve information regarding the network topology, the state of operation, which includes the current state of controllable and uncontrollable equipment, the HEMS flexibility bands. The Real Time Platform acts as a middleware between the DSO services and this LV optimization storage tool. Additionally, by accessing the forecasting information from the RTP, the DSO is able to retrieve information on the nodal active power (P) values ex-pected for the time horizon that is being considered.
The LV Storage Optimization Tool is based on a multi-temporal Optimal Power Flow (OPF) algorithm for optimizing microgrid operation while minimizing the deviation be-tween actual and expected net load profile. It makes use of storage connected to the secondary substation, LV distribution feeders and buildings, as well as demand-side management. The LV Storage Optimization Tool optimises the storage and controllable loads operating strategy for a pre-defined time horizon (e.g., next hours, day) in order to minimize the power losses, improve the quality of service and ensure continuity of ser-vice, while respecting the technical constraints of the network (namely in terms of voltage profiles) and considering the future states of the LV grid.
The final output is the operating strategy of the storage devices and controllable loads for the next hours/day. This output generates a set of control set-points for the storage and loads steady-state operation. Furthermore, HEMS flexibilities can be activated.
USE CASES
D1.3_SENSIBLE_Deliverable_final 111/154
2.9.4 Use Case Story
Fig. 31 Optimizing the operation of storage devices in the LV network – Use case diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 112/154
2.9.5 Actors
Table 50 Actors involved
Actor name Actor Type Actor Description
EDP Box (EB) Systems of
DSO
EDP Box is an energy smart meter device designed
according to the Portuguese specifications. This equip-
ment has remote communication capabilities for net-
work management, AMR (automatic meter readings)
and AMI (advanced metering infrastructure).
Distribution Trans-
former Controller
(DTC)
Systems of
DSO
LV Network Controller and Data concentrator device
responsible for the management of the EDP Box
(smart meters) infrastructure and for the management
and monitoring of the distribution MV/LV substation
and low voltage network.
LV Grid Support
Storage
Systems of
DSO
Corresponds to storage units owned by the DSO in-
stalled in the LV bus of the Medium Voltage (MV) / LV
substation (flywheels and electrochemical storage)
and/or LV feeders (electrochemical storage).
Real Time Platform
(RTP INDRA)
Systems of
DSO
Real Time Integration Platform (iSPEED) integrated
platform for real-time data acquisition and processing,
with the ability to handle large volumes of information
at low latency. It will act as a middleware between the
DSO services and all SENSIBLE tools.
HEMS Systems of
customer
Home energy management system (HEMS) device
that is able to communicate with the EDP Box and
manage the customer resources
Net-load Forecast Data Ana-
lytics
The tool provides forecasts for the electric demand for
individual consumers in the LV network
Renewable Energy
Forecast
Data Ana-
lytics
The tool provides forecasts for the microgeneration of
the LV grid.
Residential Storage LV client Residential storage for Évora demonstrator corre-
sponds to electrochemical storage units owned by the
consumer and connected behind the meter.
Microgeneration LV client Corresponds to small scale PV units connected to sin-
gle-phase LV clients.
USE CASES
D1.3_SENSIBLE_Deliverable_final 113/154
Controllable loads LV client Corresponds to electric water heaters remotely con-
trolled through the HEMS interface. Connected to sin-
gle-phase LV clients.
DMS Database Systems of
DSO
Corresponds to a database which collects and stores
relevant information from the EB and DTC (Distribution
Controller Transformer) for the LV network operation. It
will also interface with the Real Time Platform (RTP IN-
DRA) which incorporates this tool.
USE CASES
D1.3_SENSIBLE_Deliverable_final 114/154
2.9.6 Steps
Fig. 32 Optimizing the operation of storage devices in the LV network – Use case activity
diagram
1.1. Access to DMS database (static data) and RTP (dynamic data)
The DSO sends a request to exchange information with the DMS database and RTP so that it can retrieve data for the multi-temporal OPF tool.
USE CASES
D1.3_SENSIBLE_Deliverable_final 115/154
1.2. Retrieve grid current state of operation
The state of operation refers to the current state of the uncontrollable and controllable equipment through advanced meter equipment, such as the EDP Box (EB) that also acts as middleware between the HEMS and the DTC. This dynamic data is retrieved from the RTP and it is combined with the static data from the DMS database (i.e., hierarchy of the network and location of the network equipment).
Uncontrollable equipment:
� Transformers;
� Non-controllable Loads;
� Distributed generation;
� etc.
Controllable equipment:
� Storage Devices;
� HEMS;
� Distributed generation;
� OLTC;
� etc.
Grid topology:
The network topology configuration is required and it should be connected to the con-trollable and uncontrollable assets. This means combining the static and dynamic infor-mation from the DMS database and RTP correspondingly.
1.2.1. Use previous data / perform a state estimation
When the dynamic information coming from 1.2 is for some reason not accessible or erroneous, the DSO uses past but similar information (e.g., for a given hour the DSO uses the correspondent data for the last comparable day – same day of the week, same hour, past week).
Another possible solution is to use a state estimation algorithm in order to find the values for a set of variables (states) that adjust in a more adequate way to a set of network values (measurements) that is available from the network (e.g., AMI, Remote Terminal Units (RTUs), current and voltage transformer). The state variables are such that all the other network variables can be evaluated from them, and the operation state is obtained. The calculation of state variables considers the physical laws directing the operation of electrical networks and is typically done adopting some criteria, such as weighted least squares.
USE CASES
D1.3_SENSIBLE_Deliverable_final 116/154
1.3. Access forecasting information from the RTP
The DSO sends a request to exchange forecasting information with the RTP so that it can retrieve data for the optimization algorithm.
1.4. Retrieve nodal forecasted data
The DSO retrieve information from the RTP regarding the nodal active power values expected for the time horizon that is being considered. The active power values are ob-tained from the net-load and renewable energy forecasts that are generated during the day. The forecasts for the electric and heating demand for individual consumers are pro-vided by the Net-load Forecast tool and the forecasts for the micro-generation at the LV grid are provided by the Renewable Energy Forecast tool.
1.4.1. Use previous forecasts
If, for some reason, the most recent forecasts are not available at the RTP, the DSO uses the previous forecasts (performed in the previous hours for the same period) in the OPF. In fact, these forecasts are less accurate but they still guarantee the success of the OPF process.
1.5. Retrieve flexibility data to be provided by HEMS
The DMS database contains real-time information regarding flexibility bands from the HEMS. This flexibility provided by the local LV consumer results from the combination of current demand, possible demand shift, and current State of Charge of residential stor-age devices. These HEMS flexibility bands are also included in the OPF calculations for the time horizon that is being considered.
The HEMS performs a real time monitoring, accessing to smart meter data from LV con-sumers. This data includes consumption and micro-generation profiles. Acting in some domestic devices like TV’s, fridges, PC, and others is also a possibility.
1.5.1. Disable OPF HEMS flexibility variables
If, for some reason, the HEMS flexibility bands data is not available in the DMS database, the DSO does not consider this flexibility as a decision variable of the OPF.
1.6. Include HEMS flexibility bands’ price into the OPF objective function
After retrieving the HEMS flexibility bands, the DSO includes the offers’ prices into the OPF objective function.
1.7. Perform the multi-temporal OPF
The OPF algorithm, considering the input data available, will seek the optimization of the defined objective function, while respecting the limitations imposed (e.g., voltage and
USE CASES
D1.3_SENSIBLE_Deliverable_final 117/154
branch limits, DSO desired profile). Examples of possible objective function are the min-imization of power losses, the minimization of the difference between expected and measured power profiles, or even the minimization of renewable source energy shed-ding. The activation of flexibility represents a cost to be minimized.
Upon receiving the necessary input data, the OPF is run for a pre-specified time horizon taking into account technical constraints such as:
� Admissible range for voltage magnitudes at the network buses;
� Maximum allowable current for branches;
� Operational limits for equipment (active and reactive power limits for distributed generation and controllable loads, etc.)
� DSO PQ desired profiles.
1.8. Relax DSO conditions regarding PQ profile
If the multi-temporal OPF cannot find a solution within the PQ profile constraints required by the DSO in the secondary substation, these restrictions are successively relaxed until the OPF finds a feasible solution. When a feasible solution is found, it means that the corresponding PQ relaxed profile is the best solution that can be provided to the DSO that complies with the technical constraints of the distribution grid.
Outputs Description
The results of the OPF correspond to a series of control actions that comprehend for each defined time frame the optimal suitable mode of operation. The control actions may be composed of updated set-points that alter the characteristics of operation of deter-mined grid equipment (i.e. storage unit, HEMS, etc.) or activated flexibility. Some of the outputs are described below in a non-exhaustive form:
The OPF output data are:
� Set-points for controllable equipment in distribution grid, such as stor-age unit;
� Activate HEMS flexibility:
• Active/reactive power set-points for HEMS;
• Active/reactive power set-points for distributed micro-generators;
1.9. Send set-points to DSO controllable equipment
Using the DSM and the RTP the DSO sends the set-points that result from the OPF to the equipment controlled by the DSO (i.e., storage units, HEMS).
1.10. Activate flexibilities
The DSO sends a list of HEMS flexibilities that are activated for the considered time frame.
USE CASES
D1.3_SENSIBLE_Deliverable_final 118/154
2.9.7 Information Exchange
Table 51 Information Exchange
Name of Information (ID) Description of Information Exchanged
LV Load forecast Net-load forecasts for each node of the LV grid.
PV generation forecast Renewable generation forecasts of micro-generation, namely
PV (from ARMINES prediction system).
MV/LV substation voltage Voltage measured in the LV side of the secondary substation.
LV imported/exported power Power imported/exported at the secondary substation.
Grid Support LV storage
SOC
Current state of the charge (SoC) of the Grid Support LV stor-
age devices.
Storage Active Power Average (15 min.) active power absorbed/injected by the LV
storage devices.
Active and reactive power
consumption
Average (15 min.) reactive and active power measurements
(by phase) from LV clients.
Phase Voltage Average (15 min.) voltage measurements (by phase) from LV
clients.
LV Power flexibility Availability of residential resources to provide flexibility ser-
vices, in terms of active power.
Static network data Physical characteristics of the network and the devices con-
nected. This information comprises the complete configura-
tion of the topology of the network detailing all nodes and
lines, their technical characteristics (impedances, technical
constraints, etc.), as well as the distribution of consumers per
phase.
Historical data for the following variables:
• Average (15 min.) active and reactive power values
measured in the LV bus of the secondary substation;
• Average (15 min.) active and reactive power con-
sumption of clients connected to the LV nodes;
• Status of the LV network storage equipment (state of
charge, charge/discharge power, etc.)
Control commands Results of the control function in terms of proposed com-
mands for the LV equipment.
USE CASES
D1.3_SENSIBLE_Deliverable_final 119/154
2.10 Use Case 10: Islanding Operation of Low Voltage Networks
2.10.1 Use Case Identification
Table 52 Use case Identification
Name of the Use Case
Islanding Operation of Low Voltage Networks
Link to demonstrators
Évora
Domain
Grid Operation
Business key features
Storage used for MV and LV operation optimization
Participation of independent actors (DER aggregators, services provider, etc )
Integration of new markets (ancillary services)
Power Quality and Continuity of Service
2.10.2 Scope and Objectives of the Use Case
Table 53 Short description and main objectives
Short description The scope of this use case is related to the operation of LV distribution
network in the moments subsequent to islanding, occurring either from a
planned and deliberated action or from unexpected events for which the
LV networks should ride through without interruptions. It describes the
inverter and automation requirements for enabling this mode of opera-
tion.
Main Objectives The main goal is to enable the operation of LV networks in islanding
mode, ensuring the secure transition to islanding operation and the sys-
tem stability, by providing adequate frequency and voltage regulation
mechanisms.
USE CASES
D1.3_SENSIBLE_Deliverable_final 120/154
Relation to other
Use Cases
UC11: Microgrid Emergency Balance Tool
2.10.3 Use Case Description
This use case describes the operation of the LV network when disconnecting from the main grid (due to planned or unplanned events) and operating in islanded mode without interrupting service to LV consumers through the use of electrical storage units. The LV network becomes islanding by the operation of a circuit breaker triggered by a local is-landing detection mechanism or remotely by the SCADA.
Sudden islanding of the LV distribution system may cause high unbalances between local load and generation which must be immediately compensated by the energy stor-age devices. In fact, following LV grid islanding, there is the need for mechanisms that allow a fast balance between load and generation in order to ensure system survival.
Fast acting storage technologies such as flywheel are required in order to compensate the unbalance between local load and generation. However, due to the low energy ca-pacity of flywheels, high-energy capacity storage units such as batteries must also be installed to maintain the stability of the islanded network and ensure load following.
In order to provide power balance, the electrical storage unit(s) installed at the LV bus of the secondary substation should be coupled through an inverter that is able to operate as a Voltage Source Inverter (VSI). The loss of the upstream grid has to be detected autonomously. The storage inverter systems play a master role my providing the voltage and frequency for the islanding system (operation as a grid forming inverter). This func-tional requirement can be achieved through the use of specific control solutions at the VSI level, such as the use of droops for voltage and frequency regulation.
This local control acts autonomously at the VSI level by responding immediately to dis-turbances affecting the balance and voltage of the MG, thus not fully depending on the MG communication infrastructure for responding to the continuous load/generation bal-ance requirement during MG islanding operation. Such behaviour is possible as the MG master inverter role related to voltage and frequency control relies only in electric quan-tities (i.e. voltages, power, and frequency) collected from local measurements. However, the effectiveness of these strategies for long-term operation of the islanded MG is de-pendent on the availability of storage capacity. Therefore, it is mandatory to manage the available storage capacity, considering the flexibility of other resources existing at the LV distribution grid, such as small scale storage units connected to LV feeders and con-sumer resources participating in demand side management strategies (micro-genera-tion, flexible loads and residential storage). As described in use case 10, a supervisory control tool will be responsible for monitoring the LV network and support the local control layer by promoting the coordination between all participating resources.
USE CASES
D1.3_SENSIBLE_Deliverable_final 121/154
When the main grid becomes available or the DSO decides to reconnect the islanded network it is necessary to ensure synchronism between the islanded system and the main grid. This function is typically provided locally by a protective relay connected to the circuit breaker. However, it will have to send to the VSI the new reference voltage and frequency to match the main grid. When the synchronization conditions are verified, a closing signal is sent to the circuit breaker.
USE CASES
D1.3_SENSIBLE_Deliverable_final 122/154
2.10.4 Use Case Story
Fig. 33 Islanding Operation of Low Voltage Networks - Use case diagram and involved
actors
uc LV network islanding operation
DSO
SCADA
Enable planned islanding
Enable reconnection to LV
network
MG pre-balancing
DTC
Confirmation of sucessfull islanding/
reconnection
MG emergency balancing tools
Sends control setpoints
DMS database
MV/LV breaker and synchronizer
MV/LV substation storage
LV network storage Energy Box
Emergency control mode enable
Real Time Platform (RTP)
«flow»
«flow»
«flow»
«flow» «flow»
«invokes»
«flow»
«invokes»
«invokes»
«flow»
«flow»
«flow»
«flow»
«flow»
«flow»
«invokes»
«flow»
«invokes»
«flow»
«flow»
«flow»
«precedes»
«flow»
«flow»
USE CASES
D1.3_SENSIBLE_Deliverable_final 123/154
2.10.5 Actors
Table 54 Actors involved
Actor name Actor Type Actor Description
EDP Box (EB) Systems of
DSO
EDP Box is a smart meter device designed accord-
ing to the Portuguese specifications that provides
also the gateway interface to the domestic/home en-
ergy management systems (HEMS). This equipment
has remote communication capabilities for network
management, AMR (Automatic Meter Readings) and
AMI (advanced metering infrastructure).
Distribution Trans-
former Controller
(DTC)
Systems of
DSO
LV Network Controller and Data concentrator device
responsible for the management of the EDP Box
(smart meters) infrastructure and for the manage-
ment and monitoring of the distribution MV/LV sub-
station and the low voltage network.
DMS Database Systems of
DSO
Corresponds to a database which collects and stores
relevant information from the EB and DTC (Distribu-
tion Controller Transformer) for the LV network oper-
ation. It will also interface with the Real Time Plat-
form (RTP INDRA) which incorporates this tool.
SCADA Systems of
DSO
System for controlling HV and MV Portuguese net-
work including tags, traces and symbols/ synoptic
and enables the remote monitoring and control of the
electricity network.
Real Time Platform
(RTP INDRA)
Systems of
DSO
Real Time Integration Platform (iSPEED) integrated
platform for real-time data acquisition and pro-
cessing, with the ability to handle large volumes of
information at low latency. It will act as a middleware
between the DSO services and all SENSIBLE tools.
LV Grid Support
Storage
Systems of
DSO
Corresponds to storage units owned by the DSO in-
stalled in the LV bus of the Medium Voltage (MV) /
LV substation (flywheels and electrochemical stor-
age) and/or LV feeders (electrochemical storage).
USE CASES
D1.3_SENSIBLE_Deliverable_final 124/154
MV/LV substation
breaker and syn-
chronizer equipment
Systems of
DSO
Corresponds to the circuit breaker which will be re-
sponsible for islanding the LV network from the main
grid. A protection relay or comparable field device /
function for resynchronization need also to be con-
sidered.
2.10.6 Steps
1.1. LV network islanding detection and balancing
The islanding of the LV network can occur due to planned or unplanned actions.
1.1.1. Unplanned islanding
The islanding occurs due to a fault affecting the MV network. The MV/LV substation needs to be equipped with the appropriated protection devices (in the LV side) in order to detect the fault events, ride through the fault event and moving to islanding operation. Under such conditions, LV grid systems such as micro-generators or other energy stor-age units need also to be fault ride through compliant.
1.1.2. Planned islanding
The islanding occurs due to some planned action defined by the DSO, which sends a control signal to trigger the disconnection of the LV bus from the main grid.
1.1.2.1. LV network balancing prior to planned islanding
Before islanding the system the DSO will enable the LV network balancing pro-cess which will minimize the power flow with the upstream network, through a set of control actions for storage and residential flexible resources. The control ac-tions are to be defined by the Microgrid Balancing Tool described in use case 10.
1.2. LV network disconnection from the main grid
The LV bus of the MV/LV substation is islanded from the main grid by the opening of the circuit breaker, triggered either by the local protection system installed in the LV side of the MV/LV secondary substation or by a remote signal sent by the DSO. The islanding of the network should automatically trigger voltage and frequency regulation functionality of the VSI installed at the MV/LV substation located downstream of the circuit breaker, i.e. in the islanded (LV) grid area. In case the substation includes more than one storage unit participating in voltage and frequency regulation, adequate coordination should be ensured amongst them.
Regarding the other storage units installed in the LV feeders or at the residential level, a remote signal should be sent in order to activate islanded grid support functionalities if they are considered.
USE CASES
D1.3_SENSIBLE_Deliverable_final 125/154
1.3. Confirmation of successful islanding
The islanding is considered successful if after the islanding transient all the LV consum-ers/prosumers remain connected to the system as well as all key DSO owned resources such as the grid supporting storage connected to the LV feeders and local generation systems. All these elements should be fault ride through compliant. After the transient the system will check for any failure alarms generated by the DSO monitoring and me-tering equipment.
1.4. Enabling emergency monitoring and management tools
The confirmation of a successful islanding will be sent to the DSO central services, au-tomatically enabling the tools dedicated to the monitoring and management of the LV network during islanded mode (use case 10). All the DMS modules that are not compat-ible with this mode of operation should be temporarily disabled. Similarly, active demand side management strategies for residential resources which are not compatible with is-landed operation should be temporarily disabled until the LV network reconnects to the main grid.
1.5. Initialization of the synchronization process
When the MV network becomes available or when the DSO decides to synchronize the LV network with the upstream grid, the synchronization process should be triggered. This process will require the adjustment of the VSI(s) reference frequency and voltage (mag-nitude and phase) according to the main grid voltage before closing the interconnection circuit breaker. If more than one VSI is installed in the secondary substation, adequate coordination should be ensured amongst them during the preparation and check of the synchronization conditions. The circuit breaker separating the islanded LV network to the main grid is controlled by a synchronization relay. If the closing criteria are not fulfilled, a reference signal has to be provided to the VSI(s). The synchro check and the generation of the reference signal can be realized via a sufficient intelligent protection relay.
1.6. LV network reconnection to the main grid
The interconnection circuit breaker is automatically closed when synchronizing condi-tions are verified.
1.7. Configuration of the system for interconnected mode of operation
After the successful reconnection of the LV network, a confirmation signal should be sent to the SCADA/DMS. This alarm should enable the DMS tools dedicated to the manage-ment of the network during interconnected mode and disable the tool dedicated to the management of the LV network during islanded operation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 126/154
2.10.7 Information Exchange
Table 55 Information Exchange
Name of Information (ID) Description of Information Exchanged
Islanded operation alarm Confirmation of LV network successful islanding.
Enable reconnection Confirmation that the MV network is available for reconnection.
Enable emergency control Enable the control of the storage inverters performing frequency
and voltage regulation.
General alarms Alarms regarding state of network components and metering
equipment
2.11 Use Case 11: Microgrid Emergency Balance Tool
2.11.1 Use Case identification
Table 56 Use case Identification
Name of the Use Case
Microgrid Emergency Balance Tool
Link to demonstrators
Évora
Domain
Grid Operation
Business key features
Storage used for MV and LV operation optimization Participation of independent actors (DER aggregators, services provider, etc ) Integration of new markets (ancillary services) Power Quality and Continuity of Service
USE CASES
D1.3_SENSIBLE_Deliverable_final 127/154
2.11.2 Scope and Objectives of the Use Case
Table 57 Short description and main objectives
Short description The scope of this use case is related to a high level coordination of
LV distribution network in order to ensure a secure islanding opera-
tion, taking advantage of the flexibility of distributed storage capacity
connected at the secondary substation (MV/LV) and LV feeders as
well as the flexible resources at residential level (loads, micro-gen-
eration and storage). This use case describes a tool to support the
automation and local control described in use case 10.
Main Objectives The main goal is to ensure the security and stability of LV networks
during islanding operating conditions until reconnecting to the up-
stream network. During islanding operation, there exists the need of
assuring a continuous balance between LV generation and load in
order to assure adequate system frequency throughout a proper
management of the locally available resources. The main objectives
of this module are:
• Minimize energy not supplied and time of service interrup-tion.
• Ensure that the MG has sufficient capacity to ensure fre-quency regulation following islanding.
• Maintain frequency excursions within admissible limits
• Maintain voltage within admissible limits and minimize volt-age unbalance.
Relation to other Use
Cases
UC9: Optimizing the operation of storage devices in the LV network
UC10: Islanded operation of Low Voltage Network
2.11.3 Use Case Description
MG Emergency Balance tool is a software application which is responsible for managing storage and the flexibility of residential consumption/generation, in order to ensure a se-cure islanding operation. The tool’s main objective is to increase resilience of the LV network when operating under emergency conditions, taking advantage of flexible re-sources such as storage and loads.
The tool is composed of two modules:
• Pre-islanding balancing algorithm runs during interconnected mode. Performs continuous monitoring of the LV grid during normal interconnected mode, eval-uates LV grid state (in terms of total load, generation as well as storage units SoC) and estimates the severity of the disturbance and determine the storage
USE CASES
D1.3_SENSIBLE_Deliverable_final 128/154
energy capacity required to ensure the MG islanded operation during a pre-es-tablished period of time, considering also the forecast of micro-generation and loads for the next hours. If a planned islanding is triggered by the DSO the algo-rithm will define the most adequate control actions to the available resources in order to minimize the transient caused by the islanding procedure. Two main controllable resources are considered: DSO owned storage and the residential flexibility (provided by the local management of residential storage, loads and micro-generation through the HEMS).
• Emergency balancing tool will be triggered after islanding and will monitor peri-odically the LV network operation in order to ensure that the total storage capac-ity is sufficient to ensure the frequency and voltage regulation of the islanded system. The tool will also monitor voltage in the LV network, ensuring that both frequency and voltage are maintained within admissible limits.
The MG Emergency Balance tool control horizon can be set to plan the control for the next 15 min or in a longer term (a few hours) based on load and micro-generation fore-casting. As outputs, the module will return a set of control signals to grid supporting stor-age and to customer energy management system in order to control flexible resources such as residential storage, controllable loads and micro-generation.
USE CASES
D1.3_SENSIBLE_Deliverable_final 129/154
2.11.4 Use Case Story
Fig. 34 Microgrid Emergency Balance Tool Use case – Use case diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 130/154
2.11.5 Actors
Table 58 Actors involved
Actor name Actor Type Actor Description
EDP Box (EB) Systems of
DSO
EDP Box is a smart meter device designed according to
the Portuguese specifications that provides also the gate-
way interface to the domestic/home energy management
systems (HEMS). This equipment has remote communi-
cation capabilities for network management, AMR (auto-
matic meter readings) and AMI (advanced metering infra-
structure).
Distribution
Transformer
Controller
(DTC)
Systems of
DSO
LV Network Controller and Data concentrator device re-
sponsible for the management of the EDP Box (smart
meters) infrastructure and for the management and moni-
toring of the distribution MV/LV substation and low volt-
age network.
LV Grid Sup-
port Storage
Systems of
DSO
Corresponds to storage units owned by the DSO installed
in the LV bus of the Medium Voltage (MV) / LV substation
(flywheels and electrochemical storage) and/or LV feed-
ers (electrochemical storage).
DMS Database Systems of
DSO
Corresponds to a database which collects and stores rel-
evant information from the EB and DTC (Distribution Con-
troller Transformer) for the LV network operation. It will
also interface with the Real Time Platform (RTP INDRA)
which incorporates this tool.
SCADA Systems of
DSO
System for controlling HV and MV Portuguese network in-
cluding tags, traces and symbols/ synoptics and enables
the remote monitoring and control of the electricity net-
work.
Real Time Plat-
form (RTP IN-
DRA)
Systems of
DSO
Real Time Integration Platform (iSPEED) integrated plat-
form for real-time data acquisition and processing, with
the ability to handle large volumes of information at low
latency. It will act as a middleware between the DSO ser-
vices and all SENSIBLE tools.
USE CASES
D1.3_SENSIBLE_Deliverable_final 131/154
Home energy
management
System
(HEMS)
Systems of
customer
Device which is able to communicate with the EDP Box
and manage the customer resources (micro-generation,
storage and loads)
Load Forecast Analytics The tool provides forecasts for the electric and heating
demand for individual consumers.
Renewable En-
ergy Forecast
Analytics The tool provides forecasts for the electric and heating
demand for individual consumers
2.11.6 Steps
Fig. 35 Microgrid Emergency Balance Tool Use Case – Activity diagram
USE CASES
D1.3_SENSIBLE_Deliverable_final 132/154
Description of the Use case step by step:
1.1. Monitors MG operation mode
Checks if the LV network is operating interconnected or islanded. If the LV network is operating interconnected the pre-islanding balancing tool will be enabled, otherwise the emergency balancing tool will be enabled.
1.2. Pre-islanding Balancing
Runs when the LV network is operating interconnected.
1.2.1. Characterize the MG operating state
The algorithm will characterize the MG current operating state based on the information collected locally at the MV/LV substation and remotely from the SM, regarding the power flow between the MG and the MV network, LV storage available capacity (SoC) and MG load (disaggregated between the controllable/flexible and non-controllable load).
Load and micro-generation forecasting for the next hours will also be considered in order to define the necessary reserve capacity for the next period of time considered.
1.2.2. Determine the severity of the disturbance
The algorithm will estimate the severity of the disturbance resulting from the difference between the power imported/exported from the main grid and determine the storage en-ergy capacity required to ensure the MG islanded operation during a pre-established period of time.
The storage energy capacity required to ensure the successful islanding for the next period of time will be an input of the LV Optimization Tool (as a constraint).
1.2.3. Determine pre-islanding control actions
This step is activated when the DSO requests a planned islanding of the LV distribution grid. Based on the current state of operation and storage energy capacity requirement defined in previous step, the algorithm will define a set of control actions considering controllable resources available for minimizing the power unbalance prior to the island-ing.
The output of this module consists of set-points for the exploitation of available resources (for example, power set-points for the grid energy storage devices, controllable loads or residential storage units, micro-generation power in feed reduction, etc).
1.2.3.1. Evaluate the security of the MG during an unplanned islanding
A power flow will be used to check if the control actions do not affect the voltage in the LV network nodes. Otherwise, a new control solution has to be identified.
1.3. Emergency balancing tool
Runs after a successful islanding of the LV network.
USE CASES
D1.3_SENSIBLE_Deliverable_final 133/154
1.3.1. Characterize the MG operating state
The algorithm will continuously monitor the MG operation state ensuring that there are sufficient resources to ensure power balance and that voltage in the LV network are within admissible limits.
1.3.2. Optimized balance of MG
Based on the current state of the network (total load, energy storage units SoC) and on the load and micro-generation forecasting for the next hours, the algorithm will search for the optimal state of controllable resources, namely grid support storage and the flex-ibility of residential resources. The main objective is to manage grid support storage and residential flexibility considering the micro-generation and loads current state as well as its forecasted profile. A power flow study is conducted in order to check if the new control set-points are able to maintain voltage within limits, otherwise it will look for a new solu-tion.
As outputs the algorithm will determine new control set-points namely regarding active power for storage units and the residential flexibility.
When a final solution is found, the plan for the next hours is sent to the substation con-troller (DTC), which will be responsible for sending the control signals to the controllers of the LV feeder storage and for the SM of the consumers participating in emergency control services.
1.3.2.1. Schedule emergency control actions
During islanded mode, the algorithm continuously checks the power flow from the stor-age units providing voltage and frequency regulation, installed at the MV/LV substation. A dead-band is defined considering the deviation to the planned operation set-point de-fined on previous step. If significant changes are detected, a signal should be sent to the DMS in order to update the optimized balance strategy. Therefore, step 1.3.2 will run again to determine a new operation plan for the next hours.
If the storage state-of-charge reaches the minimum or maximum admissible limits the algorithm should activate the last resource control in step 1.3.2.2., in order to avoid the disconnection of the storage units and the consequent network collapse.
1.3.2.2. Schedule last resource control
The algorithm will activate a last resource control, which consist of a rule based proce-dure which gradually change storage installed in the LV feeders and micro-generation reference power or disconnect some consumers to avoid the LV network collapse. Con-sidering the following conditions:
a. The storage SOC is below the minimum admissible limit. If battery SOC is reaching its minimum admissible limit the algorithm will start by disconnecting non-priority consumers until balance between generation and load is achieved.
USE CASES
D1.3_SENSIBLE_Deliverable_final 134/154
b. The storage SOC is above the maximum admissible limit. If batteries are fully charged and the micro-generation increases and there isn’t any load avail-able for control, the algorithm will gradually reduce the micro-generation refer-ence power. The power reduction signal will be done in small steps.
2 Sends control set-points
The control set-points are then sent to the controllable resources dispatched, through the RTP for the DMS infrastructure.
2.11.7 Information Exchange
Table 59 Information Exchange
Name of Information (ID) Description of Information Exchanged
LV Load forecast Net-load forecasts for each node of the LV grid.
PV generation forecast Renewable generation forecasts of micro-generation,
namely PV (from ARMINES prediction system).
MV/LV substation voltage Voltage measured in the LV side of the secondary substa-
tion.
LV imported/exported power Power imported/exported at the secondary substation.
Grid Support LV storage SOC Current state of the charge (SoC) of the Grid Support LV
storage devices.
Storage Active Power Average (15 min) active power absorbed/injected by the LV
storage devices.
Active and reactive power con-
sumption
Average (15 min) reactive and active power measurements
(by phase) from LV clients.
Phase Voltage Average (15 min) voltage measurements (by phase) from LV
clients.
LV Power flexibility Availability of residential resources to provide flexibility ser-
vices, in terms of active power.
Static network data Physical characteristics of the network and the devices con-
nected. This information comprises the complete configura-
tion of the topology of the network detailing all nodes and
lines, their technical characteristics (impedances, technical
USE CASES
D1.3_SENSIBLE_Deliverable_final 135/154
constraints, etc.), as well as the distribution of consumers
per phase.
Historical data for the following variables:
• Average (15 min.) active and reactive power val-
ues measured in the LV bus of the secondary sub-
station;
• Average (15 min.) active and reactive power con-
sumption of clients connected to the LV nodes;
• Status of the LV network storage equipment (state
of charge, charge/discharge power, etc.)
Control commands Results of the control function in terms of proposed com-
mands for the LV equipment.
Network state Signal indicating that the LV network is operating islanded
or interconnected to the main grid.
Enable/Disable grid support
functions
Grid Support storage mode of operation (e.g. P/Q control,
Voltage support, frequency support)
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 136/154
3 Requirements
3.1 Functional Requirements
Table 60 System Functional Requirements – Nuremberg Demonstrator
Req-ID Name Description Priority
Applicability period
and related use case
N_FR1 Access
through
web ser-
vice
based
interface
Access to receive/exchange
non real-time data (e.g. con-
tract data, forecast, etc).
This is the main interface to
Indra real-time integration
platform.
Mandatory Initial
phase of
design
UC1
UC3
UC4
N_FR2 Access
through
DDS-
based
interface
DDS-based interface to re-
ceive/exchange real-time
and high performance data.
This is the second interface
to Indra real-time integration
platform. Needed if real-
time data to be exchanged.
Needed/use-
ful
Initial
phase of
design
UC1
UC3
UC4
N_FR3 Weather
forecast
Access to weather and so-
lar-radiation forecast.
Mandatory Initial
phase of
design
UC1
UC3
UC4
N_FR4 Electri-
cal load
forecast
Access to electrical load
forecast of the building.
Useful Initial
phase of
design
UC1
UC3
UC4
N_FR5 Thermal
load
forecast
Access to thermal load fore-
cast of the building.
Useful Initial
phase of
design
UC1
UC3
UC4
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 137/154
N_FR6 Energy
price
data
Access to energy prices (re-
lated to N_FR1)
Mandatory Initial
phase of
design
UC1
UC3
UC4
N_FR7 Control
signal
Means to be informed (for
the client/building) that it is
switched off after a prede-
fined period of time in emer-
gency.
Useful
(optional)
Final
phase of
design
UC1
UC3
UC4
N_FR8 Direct
channel
1
Direct communication chan-
nel (web service based) for
backup communication with
the energy provider (Em-
power) for emergency.
Useful
(optional)
Final
phase of
design
UC1
UC3
UC4
Table 61 System Functional Requirements – Nottingham demonstrator
Req-ID Name Description Priority
Applicability pe-
riod and related
use case
No_FR1 EMS/MDM Mi-
crogrid Man-
agement
EMS/MDM decision-mak-
ing capacity to meet the
load feeding, to keep the
microgrid stability and ser-
vice quality standards.
Mandatory Initial
phase of
design
UC5
UC7
No_FR2 Access
through DDS-
based inter-
face
DDS-based interface to re-
ceive/exchange real-time
and high performance data.
This is the second interface
to Indra real-time integra-
tion platform. Needed if
real-time data to be ex-
changed.
Needed /
useful
Initial
phase of
design
UC5
UC7
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 138/154
No_FR3 EMS/MDM
Command Ex-
ecution
Direct communication be-
tween e-brokers to organ-
ize the execution of the
EMS/MDM commands
Mandatory Initial
phase of
design
UC5
UC7
No_FR4 Use-case data
export capac-
ity
Capacity to gather and ex-
port the data produced dur-
ing the use-case perfor-
mance
Mandatory Initial
phase of
design
UC5
UC6
UC7
No_FR5 Net-load and
PV Forecast
for the LV grid
Net-load forecasts for each
node of the LV grid, PV site
and clients with HEMS
Mandatory Initial
phase of
design
UC5
UC6
No_FR6 Communica-
tion channel
between RTP
and MDM
Bandwidth and capacity for
data communication be-
tween RPT and MDM for
High Level use case Sce-
nario to achieve sampling
time of 1 min for all relevant
parameters
Mandatory Initial
phase of
design
UC5
UC6
UC7
No_FR7 Communica-
tion channel
between RTP
and MDM
Bandwidth and capacity for
data communication be-
tween RPT and MDM for
Low Level use case Sce-
nario to achieve sampling
time of 1 second for all rel-
evant parameters
Mandatory Initial
phase of
design
UC5
UC6
UC7
Table 62 Functional Requirements – Évora Demonstrator (Simulated Scenario)
Req-ID Name Description Priority
Applicability period
and related use
case
E_FR1 Net-load
Forecast
Net-load forecasts for each
node of the MV grid, includ-
ing the installation that uses
storage as backup
Mandatory Initial
phase of
design
UC8
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 139/154
E_FR2 Database
with dy-
namic data
of MV net-
work
Database with the following
dynamic information:
• Current state of the charge
(SoC) of MV storage devices
• Active power measure-
ments (by phase) from MV
clients and storage
• Voltage in the primary sub-
station (measured in the MV
side)
• Active and reactive power,
voltage in the secondary sub-
station (measured in the MV
side)
• Required storage reserve
capacity
Mandatory Initial
phase of
design
UC2,
UC8
E_FR3 Database
with static
data
Physical characteristics of
the network and the devices
connected. This information
comprises the complete con-
figuration of the topology of
the network detailing all
nodes and lines, the equip-
ment (transformers, switch-
ing elements, control de-
vices, storage elements, etc.)
and their technical character-
istics (power, impedances,
discharge curves, etc.).
Mandatory Initial
phase of
design
UC8,
UC9
E_FR4 Control set-
points gate-
way
Means to send remote con-
trol set-points to controllable
resources in the MV and LV
networks
Mandatory Final
phase of
design
UC2,
UC8,
UC9,
UC10,
UC11
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 140/154
E_FR5 Net-load
and PV
Forecast for
the LV grid
Net-load forecasts for each
node of the LV grid, PV site
and clients with HEMS
Mandatory Initial
phase of
design
UC2,
UC9,
UC11
E_FR6 Database
with dy-
namic data
of LV net-
work
Database with the following
dynamic information:
• Voltage in the secondary
substation
• Power imported/exported at
the secondary substation.
• Current state of the charge
(SoC) of the Grid Support LV
storage devices
• Power absorbed/injected by
the LV storage devices
• Reactive, active power and
voltage measurements (by
phase) from LV clients.
• Availability of residential re-
sources to provide flexibility
services.
Mandatory Initial
phase of
design
UC9,
UC11
E_FR7 Islanding
protection
system
The secondary substation
should be equipped with ad-
equate protection and
switching devices to ensure a
fast disconnection from MV
network and consequent fast
transfer to islanding mode at
the secondary substation.
Mandatory Initial
phase of
design
UC10
E_FR8 Synchroni-
zation
equipment
Ensure the synchronization
of islanded LV network to the
main grid. The synchroniza-
tion process will require the
VSI installed in the MV/LV
substation to adjust its refer-
ence frequency and voltage
Mandatory Initial
phase of
design
UC10
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 141/154
(magnitude and phase) ac-
cording to the main grid volt-
age and frequency.
E_FR9 Voltage and
frequency
regulation
Grid Supporting storage in-
stalled at the MV/LV substa-
tion should immediately en-
sure the LV system fre-
quency and voltage regula-
tion.
Mandatory Initial
phase of
design
UC10
E_FR1
0
Remote dis-
connection
of LV net-
work
Communication with
SCADA/ or equivalent for
performing islanding and re-
connection to the MV net-
work.
Mandatory Initial
phase of
design
UC10
E_FR1
1
Access to
client data
Access to data regarding the
resources owned by the cli-
ents, e.g. storage, smart me-
ter, HEMS, PV, as well as the
availability of flexibility
Mandatory Initial
phase of
design
UC2
E_FR1
2
Market par-
ticipation
optimization
EMSP should have the fol-
lowing capabilities:
• Simulate market
prices
• Optimise the retail-
ers market participa-
tion
• Build energy costs
Mandatory Final
phase of
the design
UC2
E_FR1
3
DSM func-
tionalities
DSO tool provides DMS
functionalities (for this use
case’s purpose, it may be
simulated in the EMSP)
Mandatory Final
phase of
the design
UC2
E_FR1
4
Estimation
of the GUF
DSO tool estimates the Grid
Usage Factor (GUF) (for this
use case’s purpose, it may
be simulated in the EMSP)
Needed Final
phase of
the design
UC2
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 142/154
E_FR1
5
Grid contin-
gency situa-
tion
DSO tool detects a grid con-
tingency situation
Mandatory Final
phase of
the design
UC2
E_FR1
6
Disconnect
clients from
the grid
Disconnect clients from the
grid via smart meter
Needed Initial
phase of
the design
UC2
E_FR1
7
Estimation
of SAF
EMSP estimates the System
Adjusting Factor
Mandatory Final
phase of
the design
UC2
From the simulated scenario described in use case 8, the following specific functional requirements can be inferred:
Table 63 Functional Requirements – Évora Demonstrator (Simulated Scenario)
Req-
ID
Name Description Priority
Applicabil-
ity period
FR_U
C8_1
Data Ex-
change_
DM
Dynamic data will be exchanged by means
of Real Time Platform, using the data
model defined within it, except data with an
assured life-cycle larger than 15 minutes.
Manda-
tory
Final phase
of design
FR_U
C8_2
Data Ex-
change_
ST
Dynamic data with an assured life-cycle
larger than 15 minutes will be available
from the data storage system of the Real
Time Platform.
Useful Final phase
of design
FR_U
C8_3
Data Ex-
change_
DMS
In the scope of this project, the static data
will not be exchanged, but will be available
in DMS database, and manually inter-
change once with the others actors that
need them. Nevertheless, in a real future
operation, a periodic refresh of this infor-
mation from DMS will be required.
Useful Final phase
of design
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 143/154
FR_U
C8_4
Data Ex-
change_
ASY
Data from the field will be sent in an asyn-
chronous mode, with and assured mini-
mum refresh every 15 minutes.
Manda-
tory
Final phase
of design
FR_U
C8_5
Data Ex-
change_
CC
Control commands for optimization will be
computed and sent with an interval defined
by operator from DMS, with a minimum of
5 minutes.
Useful Final phase
of design
FR_U
C8_6
Data Ex-
change_
CCS
Control commands for safety operation of
the network will be computed and sent
asynchronous, when needed.
Useful Final phase
of design
FR_U
C8_7
Perfor-
mance_C
CS
Control commands related to safety opera-
tion of the network must be computed in
less than 20 seconds, including related pre-
vious computations (Reception of meas-
urements, DSE, etc.).
Manda-
tory
Final phase
of design
FR_U
C8_8
Perfor-
mance_C
C
Control commands related with network op-
eration optimization must be computed in
less than 5 minutes.
Manda-
tory
Final phase
of design
3.2 Non-functional Requirements
Table 64 Non-Functional Requirements – Nuremberg Demonstrator
Req-ID Name Description Priority Applicability
period
Link to
functional
requirement
N_NFR-1 Security /
Encryption
Information exchanged
to be encrypted
Mandatory Final phase
of design
N_FR1,
N_FR2,
N_FR7,
N_FR8
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 144/154
N_NFR2 Security /
Anony-
misation
Anonymisation of cli-
ent/building data
source. Location of cli-
ents to be unknown.
Mandatory
Final phase
of design
N_FR1,
N_FR2,
N_FR7,
N_FR8
N_NFR3 QoS/Max.
delay
Maximum delay in data
transfer.
Mandatory Final phase
of design
N_FR_1,
N_FR_2
N_NFR4 QoS/Data
availability
Availability of: price
data, forecast data,
weather forecast ...
Mandatory Initial phase
of design
N_FR3,
N_FR4,
N_FR5,
N_FR6
N_NFR5 QoS /
Precision
Precision of forecast,
process ...etc
Mandatory Final phase
of design
N_FR3,
N_FR4,
N_FR5,
N_FR6
N_NFR6 QoS /
Customiza-
tion
Configuration to use
DDS or ESB
Useful Final phase
of design
N_FR2,
N_NFR7 QoS /
Scalability
Extend available data
types
Useful Final phase
of design
N_FR1,
N_FR2
Table 65 Non-Functional Requirements – Nottingham Demonstrator
Req-ID Name Description Priority Applicabil-
ity period
Link to
functional
requirement
No_NFR1 Conf.Mont.
/Communi-
cation
Communication chan-
nels with the resources
via Integration Gateway
Mandatory Final phase
of design
No_FR3
No_FR6
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 145/154
No_FR7
No_NFR2 Conf.Mont.
/Charge-
Dis-
chargeRat
eGridSupp.
Possibility of controlling
the charge and dis-
charge rate of the grid
support storage devices
in real-time.
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR3 Conf.Mont.
/Measur-
eS-
tateOfChar
geGrid-
Supp
Possibility of measuring
the state of charge in
real-time (remote data
collection) of grid sup-
port storage.
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR4 Conf.Mont.
/ Charge-
Dis-
chargeRat
eRes,
Possibility of controlling
the charge and dis-
charge rate of the resi-
dential storage devices
in real-time.
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR5 Conf.Mont.
/ Measur-
eS-
tateOfChar
geRes
Possibility of measuring
the state of charge in
real-time (remote data
collection) of residential
storage.
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR6 Conf.Mont.
/Pw.Supp.
Stor-
age.Con-
sump.In-
ject.
Possibility of measuring
the active / reactive
power consumption/in-
jection of Community
Support Storage in real
time. (remote data col-
lection)
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR7 Conf.Mont.
/ResStor-
age-
Op-
ModeChan
ge
Possibility of changing
the operating mode /
setpoints for residential
storage devices in real
time
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 146/154
No_NFR8 Conf.Mont.
/CommSup
pStor-
age-
Op-
ModeChan
Possibility of changing
the operating mode /
setpoints for community
support storage devices
in real time
Mandatory Final phase
of design
No_FR2
No_FR6
No_FR7
No_NFR9 Conf.Mont.
/De-
term.En-
erg.Prices
Possibility of determin-
ing the range of prices of
the energy bought or
sold by the power con-
sumers or producers in
real time
Needed Final phase
of design
No_FR2
No_NFR1
0
QoS/Op-
Modes.Re-
mot.Set-
Point.Avail-
ability
Permanent availability
of remote set-points and
modes of operation for
controllable loads and
storage devices
Mandatory Final phase
of design
No_FR1
No_FR4
No_FR6
No_NFR1
1
QoS/DataA
ccess
Access to data regard-
ing the resources
owned by the DSO, e.g.,
LV substation, as well
as the availability of
controllable loads
Mandatory Final phase
of design
No_FR6
No_NFR1
2
Sec./En-
creption
Encrypted information Mandatory Initial
phase of
design
No_FR4
No_FR6
No_NFR1
3
Sec./Anon-
ymisation
Anonymisation of resi-
dential data source
Mandatory Final phase
of design
No_FR4
No_FR6
No_NFR1
4
Data.Mang
./
Tech.Con-
straints
Technical constraints of
the microgrid, e.g. PV
penetration limits
Needed Final phase
of design
No_FR1
No_FR6
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 147/154
No_NFR1
5
Data.Mang
./
Informa-
tionAccess
Access to information
(i.e., sufficient grid
measurements) that en-
ables power flow calcu-
lations and nodal aggre-
gation to enable virtual‚
microgrid measure-
ments
Needed Initial
phase of
design
No_FR2
No_FR3
No_FR4
No_FR6
No_FR7
No_NFR1
6
Permis-
sions
Permissions from all rel-
evant stakeholders
(homeowners, land-
lords, DNOs) before in-
stalling and operating
any equipments
Mandatory Initial
phase of
design
No_FR4
No_FR6
Table 66 Non-Functional Requirements – Évora Demonstrator
Req-ID Name Description Priority Applicability
period
Link to
functional
requirement
E_NFR1 Net-load
forecast
time hori-
zon and
resolution
Time horizon ranging
between 15 minutes
and 48 hours; hourly
resolution of 15 and 60
minutes; hourly update
rate
Mandatory Final phase of
design
E_FR1,
E_FR5
E_NFR2 Update of
dynamic
data of the
MV net-
work
Updated every 15
minutes. A maximum
delay of 6 hours is ac-
ceptable for the follow-
ing variables:
• Active power measure-
ments (by phase) from
MV clients and storage
Mandatory Final phase of
design
E_FR2
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 148/154
• Voltage in the primary
substation (measured in
the MV side)
• Active and reactive
power, voltage in the
secondary substation
(measured in the MV
side)
E_NFR3 Availability
of historical
data for the
MV net-
work
Historical data for the
following variables:
• Active and reactive
power values measured
in the MV bus of the sec-
ondary substations
(MV/LV nodes) with a
15 minutes time resolu-
tion;
• Active and reactive
power consumption of
clients connected to the
MV nodes with a 15
minutes time resolution;
• Status of the network
equipment (transform-
ers, switching elements,
control devices, storage
elements, etc.)
Mandatory Initial phase of
design
E_FR3
E_NFR4 Communi-
cation
channels
Communication chan-
nels with the resources
(storage, primary and
secondary substations,
HEMS) and possibility
of controlling and meas-
uring the charge and
discharge rate of the
storage devices in real-
time (e.g. from DMS to
DTC and then to EB, or
Mandatory Final stage of
design
E_FR4
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 149/154
from the market tools to
HEMS)
E_NFR5 Data qual-
ity for MV
network
Maximum delay of 6
hours in data transfer
(active power and volt-
age of storage devices
and consumption
nodes). Maximum delay
of 60 minutes in the MV
storage state of charge.
Mandatory Final stage of
design
E_FR2
E_NFR6 Data man-
agement
Access to data regard-
ing the resources
owned by the DSO, e.g.
storage, transformer of
secondary substation,
as well as the availabil-
ity of LV and MV storage
and controllable loads.
Access to information
(i.e., sufficient grid
measurements) that en-
ables power flow calcu-
lations.
Mandatory Final stage of
design
N/A
E_NFR7 Update of
dynamic
data of the
LV network
Update every 15
minutes. A maximum
delay of 1 hour is ac-
ceptable.
Mandatory Final phase of
design
E_FR6
E_NFR8 Availability
of historical
data for the
LV network
Historical data for the
following variables:
• Active and reactive
power values measured
in the LV bus of the sec-
ondary substation with a
15 minutes time resolu-
tion;
• Active and reactive
power consumption of
Mandatory Initial phase of
design
E_FR3
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 150/154
clients connected to the
LV nodes with a 15
minutes time resolution;
• Status of the LV net-
work storage equipment
(state of charge,
charge/discharge
power, etc.)
E_NFR9 Data qual-
ity for LV
network
Maximum delay of 1
hour in data transfer
(active power and volt-
age of storage devices
and LV consumption
nodes)
Mandatory Final stage of
design
E_FR6
E_NFR1
0
Uninter-
rupted
power sup-
ply capabil-
ity
Uninterrupted power
supply capability for all
equipment that is nec-
essary to assure island-
ing capability, e.g. VSI,
circuit breaker, DTC
Mandatory Initial phase of
design
E_FR4,
E_FR7,
E_FR8
E_NFR1
1
Synchroni-
zation co-
ordination
The synchronization
process will require the
VSI installed in the
MV/LV substation to ad-
just its reference fre-
quency and voltage
(magnitude and phase)
according to the main
grid voltage and fre-
quency.
Mandatory Initial phase of
design
E_FR8
E_NFR1
2
Active
communi-
cation
channel
verification
After islanding it should
be possible to verify the
active/inactive commu-
nication channels.
Useful Initial phase of
design
E_FR4
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 151/154
E_NFR1
3
Coordina-
tion be-
tween VSI
If more than one storage
unit is installed at the
MV/LV substation
providing frequency and
voltage regulation, ade-
quate coordination
should be ensured be-
tween them in order to
maintain the system sta-
bility.
Mandatory Initial phase of
design
E_FR9
E_NFR1
4
Power
quality and
stability
In the moments subse-
quent to the islanding,
the system frequency
and voltage should be
maintained within ad-
missible limits.
Mandatory Initial phase of
design
E_FR9
NRF-15 Grid sup-
port stor-
age ade-
quate siz-
ing
Storage(s) units should
have sufficient energy
storage capacity and
rated power to maintain
power balance and en-
sure load following dur-
ing islanded operation.
Mandatory Initial phase of
design
E_FR9
E_NFR1
6
Data trans-
fer delay
Maximum delay of 60
minutes in data transfer
(active power and volt-
age of storage devices
and consumption
nodes)
Useful Final phase of
the design
E_NFR1
7
Remote ac-
cess to
HEMS
Remote access to
HEMS
Mandatory Initial phase of
the design
E_FR4,
E_FR11
E_NFR1
8
Encrypted
information
Encrypted information Mandatory Final phase of
the design
E_FR11
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 152/154
E_NFR1
9
Clients
data pri-
vacy
Geographical location of
clients should be un-
known and measured
data should be associ-
ated only to LV network
nodes
Mandatory Final phase of
the design
E_FR11
E_NFR2
0
Equipment
managed
by HEMS
HEMS manages equip-
ment, including its time
schedule, that are able
to provide flexibility
Mandatory Initial phase of
the design
E_NFR2
1
EMSP fore-
casts/ sim-
ulates the
status of
the grid
EMSP forecasts/ simu-
lates the status of the
grid with a 15 minutes
time resolution
Needed Final phase of
the design
E_FR12
E_NFR2
2
Grid Usage
Factor
Grid Usage Factor is de-
termined with a 15
minutes time resolution,
according to the grid op-
eration forecast and the
technical constrains of
the grid
Needed Final phase of
the design
E_FR14
E_NFR2
3
Clients
flexibility
Clients flexibility with a
15 min time resolution
Needed Final phase of
the design
E_FR11
E_NFR2
4
Aggre-
gated flexi-
bility
Aggregation of the flexi-
bility capacity of a re-
tailer clients portfolio
with a 15 min time reso-
lution
Needed Final phase of
the design
E_FR11
E_NFR2
5
Simula-
tions/ opti-
mization
results
Simulations/ optimiza-
tion results with a 15 min
times resolution
Needed Final phase of
the design
E_FR12
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 153/154
E_NFR2
6
DSM warn-
ing signals
Execution of warning
signal to decrease the
load by a pre-defined
amount.
Mandatory Initial phase of
the design
E_FR15
E_NFR2
7
DSM warn-
ing signals
delay
Send warning signals
with a 15 min delay
Mandatory Initial phase of
the design
E_FR15
From the simulated scenario described in use case 8, the following specific non-func-tional requirements can be inferred:
Table 67 Non-Functional Requirements – Évora Demonstrator (Simulated Scenario)
Req-
ID
Name Description Priority Applica-
bility pe-
riod
Link to
functional
require-
ment
NFR_
UC8_
1
Area of
applica-
tion_DSO
This use case will be applicable
only to MV network proprietary of
the DSO, although it could use re-
sources physically located in
other areas, but available indi-
rectly (e.g. by means of aggrega-
tion and coordination)
Useful Final
phase of
design
FR_UC8_1
FR_UC8_2
FR_UC8_3
FR_UC8_4
FR_UC8_5
FR_UC8_6
FR_UC8_7
FR_UC8_8
NFR_
UC8_
2
Area of
applica-
tion_WN
The use case must be applicable
at least at the whole network de-
pending on a single HV/MV sub-
station, but must not be limited to
that, with a reasonable increment
in hardware resources, fulfilling
the previous performance re-
quirements. The verification of the
scalability of the solution to sev-
eral HV/MV substations is con-
templated by means of the use of
Useful Final
phase of
design
FR_UC8_1
FR_UC8_2
FR_UC8_3
FR_UC8_4
FR_UC8_5
FR_UC8_6
FR_UC8_7
FR_UC8_8
REQUIREMENTS
D1.3_SENSIBLE_Deliverable_final 154/154
Real Time Network Simulator
(OTS) to be provided by INDRA.
NFR_
UC8_
3
Area of
applica-
tion_AC
This use case will be applicable
only to MV network proprietary of
the DSO, although ii could use re-
sources physically located in
other areas, but available indi-
rectly (e.g. by means of aggrega-
tion and coordination)
Useful Final
phase of
design
FR_UC8_1
FR_UC8_2
FR_UC8_3
FR_UC8_4
FR_UC8_5
FR_UC8_6
FR_UC8_7
FR_UC8_8