sensible – deliverable use cases and requirements€¦ · sensible – deliverable use cases and...

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


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


• 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


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


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


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


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


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


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


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


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


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


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


2.1.6 Steps

Fig. 5 Activity Diagram

USE CASES


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


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


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


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


2.2 Use Case 2: Flexibility and DSM in the market participation


Table 8 Use case Identification

Name of the Use case

Flexibility and DSM in the market participation


Évora

Domain

Building/ End customer


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



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


• 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


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


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


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


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


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


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



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


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


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


2.2.6 Steps

2.2.6.1 Day Ahead Case

Fig. 10 - Activity diagram for the day ahead period.

USE CASES


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


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


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


Fig. 11 - Activity diagram - routine A.

USE CASES


Fig. 12 - Activity diagram - routine B.

USE CASES


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


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


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


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


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


2.3 Use Case 3: Increased percentage of self-consumption



Name of the Use case

Increased percentage of self-consumption


Nuremberg

Domain

Building/End customer


Off-grid self-consumption capacity

Maximizing consumption of locally generated power



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


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.


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.


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


Fig. 13 Use case Diagram and involved actors – Increased percentage of self-consumption

2.3.5 Actors



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


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


2.3.6 Steps


USE CASES




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


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

--


Actor /

System /

Information

Triggering

event


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


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


2.4 Use Case 4: Optimized energy procurement




Optimized energy procurement


Nuremberg

Domain

Building/End Customer


Off-grid self-consumption capacity

Maximizing consumption of locally generated power

Real Markets (day-ahead) accessible to Suppliers



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



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.


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


Fig. 16 Use case diagram and involved actors – Optimized energy procurement

2.4.5 Actors



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


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


2.4.6 Steps


USE CASES




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


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



Actor/ System /

Information

Triggering

event


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


2.5 Use Case 5: Microgrid PV Management




Microgrid PV Management


Nottingham

Domain

Microgrid / Community


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



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



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


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


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


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



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


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


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


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


USE CASES




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


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


EMS/MDM commands

No_FR2

10 Data gathering RTP / IGs /

ASMs

UC_data No_FR4

USE CASES




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


2.6 Use Case 6: Enabling an independent energy community




Enabling an independent energy community


Nottingham

Domain

Microgrid/Community






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


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


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


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.


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


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


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


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


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



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


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


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


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


2.6.6 Steps


USE CASES



USE CASES


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


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


- 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


No_FR4

No_FR5

No_FR6

USE CASES




Pr_grid (if available)

Table 33 Use case steps for Low Level Scenario

Step

nº

Name of

Process /

Activity


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


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





No_FR6

6 Sending

control com-

mands for

suspension

of test

MDM »

RTP


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



No_FR6

USE CASES




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





No_FR7

Table 34 Use case steps for Evaluation of Social Acceptance and Interaction

Step

nº

Name of

Process /

Activity


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


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,




[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


[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


2.7 Use Case 7: Microgrid energy market




Microgrid energy market


Nottingham

Domain

Microgrid / Community



Grid supply used as backup (Islanding operation mode most of times)




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



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.


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


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


2.7.5 Actors



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


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


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


USE CASES




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


- 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


2 Use-Case Ini-

tialization

MDM - Energy Management System / Mead-

ows Data manager commands

No_FR1

3 Benchmark

data gathering

RTP » IG »

ASMs


- 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


- Energy Management Sys-tem /


mands

No_FR2

6 Sending control

commands for

execution

RTP » E-

Broker




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




mands

No_FR2

9 Sending control

commands for

suspension of

test

MDM »

RTP


- Energy Management System /


mands

No_FR2

USE CASES


10 Data gathering RTP / IGs

/ ASMs

Use case data downloading No_FR3,

No_FR4

USE CASES





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


2.8 Use Case 8: Optimizing the MV Distribution Network Operation using available storage resources.




Optimizing the MV Distribution Network Operation using available storage resources.


É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



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


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.


Cases

Not Applicable

USE CASES


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


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


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


2.8.3.3 Actors



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


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


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


2.8.3.4 Steps


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


The steps of the use case are described in the following table:


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


2.8.3.5 Information Exchange



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


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


2.8.4.3 Actors



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



with the ability to handle large volumes of information at

low latency. It will act as a middleware between the


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


2.8.4.4 Steps


USE CASES


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


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


2.8.4.5 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


2.9 Use Case 9: Optimizing the operation of storage devices in the LV distribution network




Optimizing the operation of storage devices in the LV network


Évora

Domain

Grid Operation



Participation of independent actors (DER aggregators, services provider, etc.)

Integration of new markets (ancillary services)




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


Relation to other

Use Cases

UC 11: Microgrid Emergency Balance Tool


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



Fig. 31 Optimizing the operation of storage devices in the LV network – Use case diagram

USE CASES


2.9.5 Actors



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



with the ability to handle large volumes of information

at low latency. It will act as a middleware between the


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-


USE CASES


Controllable loads LV client Corresponds to electric water heaters remotely con-

trolled through the HEMS interface. Connected to sin-


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


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


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


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


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





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.


• 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


2.10 Use Case 10: Islanding Operation of Low Voltage Networks

2.10.1 Use Case Identification



Islanding Operation of Low Voltage Networks


Évora

Domain

Grid Operation



Participation of independent actors (DER aggregators, services provider, etc )

Integration of new markets (ancillary services)




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


Relation to other

Use Cases

UC11: Microgrid Emergency Balance Tool


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


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



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


2.10.5 Actors




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.


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


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


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


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





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




Microgrid Emergency Balance Tool


Évora

Domain

Grid Operation


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




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.


Cases

UC9: Optimizing the operation of storage devices in the LV network

UC10: Islanded operation of Low Voltage Network


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


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



Fig. 34 Microgrid Emergency Balance Tool Use case – Use case diagram

USE CASES


2.11.5 Actors




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


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


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


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


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


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.




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


constraints, etc.), as well as the distribution of consumers

per phase.


• 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


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


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


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


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)


Applicability period

and related use

case

E_FR1 Net-load

Forecast


node of the MV grid, includ-

ing the installation that uses

storage as backup

Mandatory Initial

phase of

design

UC8

REQUIREMENTS


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


E_FR5 Net-load

and PV

Forecast for

the LV grid


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


(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


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


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


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.


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


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


of design

No_FR3

No_FR6

REQUIREMENTS


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.


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.


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.


of design

No_FR2

No_FR6

No_FR7

No_NFR5 Conf.Mont.

/ Measur-

eS-

tateOfChar

geRes


the state of charge in

real-time (remote data

collection) of residential

storage.


of design

No_FR2

No_FR6

No_FR7

No_NFR6 Conf.Mont.

/Pw.Supp.

Stor-

age.Con-

sump.In-

ject.


the active / reactive

power consumption/in-

jection of Community

Support Storage in real

time. (remote data col-

lection)


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


of design

No_FR2

No_FR6

No_FR7

REQUIREMENTS


No_NFR8 Conf.Mont.

/CommSup

pStor-

age-

Op-

ModeChan

Possibility of changing

the operating mode /

setpoints for community

support storage devices

in real time


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


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


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


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


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


design

E_FR2

REQUIREMENTS


• 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:


power values measured

in the MV bus of the sec-

ondary substations

(MV/LV nodes) with a

15 minutes time resolu-

tion;


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


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.


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.


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.


design

E_FR6

E_NFR8 Availability

of historical

data for the

LV network

Historical data for the

following variables:


power values measured

in the LV bus of the sec-

ondary substation with a

15 minutes time resolu-

tion;


power consumption of


design

E_FR3

REQUIREMENTS


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



and LV consumption

nodes)


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


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.


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


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.


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.


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.


design

E_FR9

E_NFR1

6

Data trans-

fer delay

Maximum delay of 60

minutes in data transfer



and consumption

nodes)

Useful Final phase of

the design

E_NFR1

7

Remote ac-

cess to

HEMS

Remote access to

HEMS


the design

E_FR4,

E_FR11

E_NFR1

8

Encrypted

information

Encrypted information Mandatory Final phase of

the design

E_FR11

REQUIREMENTS


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


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


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


the design

E_FR14

E_NFR2

3

Clients

flexibility

Clients flexibility with a

15 min time resolution


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


the design

E_FR11

E_NFR2

5

Simula-

tions/ opti-

mization

results

Simulations/ optimiza-

tion results with a 15 min

times resolution


the design

E_FR12

REQUIREMENTS


E_NFR2

6

DSM warn-

ing signals

Execution of warning

signal to decrease the

load by a pre-defined

amount.


the design

E_FR15

E_NFR2

7

DSM warn-

ing signals

delay

Send warning signals

with a 15 min delay


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


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

sensible – deliverable use cases and requirements€¦ · sensible – deliverable use cases and...

Documents