Smart system of renewable energy storage based on ... · 8.1 Azure components 68 8.1.1 Azure SQL...

INVADE H2020 project – Grant agreement nº 731148

This project has received funding from the European Union’s Horizon 2020 Research and Innovation programme under Grant Agreement No 731148.

Smart system of renewable energy storage based on INtegrated EVs and

bAtteries to empower mobile, Distributed and centralised Energy storage

in the distribution grid

Deliverable nº: D4.1

Deliverable name: Overall INVADE architecture

Version: 1.0

Release date: 14/07/2017

Dissemination level: Public

Status: Submitted

Author: Pau Lloret, Pol Olivella – UPC

Glen Thomas Berger – eSmart systems

Jonel Timbergen, Patrick Rademakers – ElaadNL


Deliverable D4.1 – Overall INVADE architecture of 85

Document history:

Version Date of issue Content and changes Edited by

0.1 03/06/2017 Preliminary version of section 1 UPC

0.2 27/06/2017 Section 2 ElaadNL

0.3 29/06/2017 Section 3 eSmart Systems

0.4 03/07/2017 Section 4 and ending of the first complete draft UPC

1.0 14/07/2017 Peer reviewed version UPC

Peer reviewed by:

Partner Reviewer

SmartIN Jay Rajasekharan

eSmart Terje Lundby

Greenflux Michel Bayings

Deliverable beneficiaries:

WP / Task

WP4 / T4.5

WP7 / T7.2

WP8 / T8.1

WP10 / T10.1



Table of contents

Executive summary ....................................................................................................... 9

1 Concept design ..................................................................................................... 11

1.1 Introduction 11

1.2 Flexibility operator concept 15

1.3 Flexibility services 17

1.4 Flexibility sources 20

1.5 Use cases 22

1.6 Application of flexibility to the use cases 24

1.6.1Flexibility services in each UC 24

1.6.2Flexibility sources for each flexibility service 28

1.6.3Flexibility sources in each UC 31

1.7 Traffic light concept (TLC) 32

1.8 Interface mechanisms 34

1.8.1BRP/DSO interface mechanism for using flexibility 34

1.8.2Customer interface mechanism for providing

flexibility 36

1.9 Baseline definition 38

2 Review of standards in the e-mobility chain ...................................................... 39

2.1 ISO/IEC 15118 40

2.1.1Definition 40

2.1.2Technical Characteristics 40

2.1.3PUC - Use Cases / application 41

2.2 OCPP 41

2.2.1Definition 41




2.2.3PUC - Use Cases / applications 41

2.3 IEC 61851-1 42

2.3.1Definition 42


2.3.3PUC - Use Cases 42

2.4 IEC 61850-90-8 43

2.4.1Definition 43



2.5 OCPI 43

2.5.1Definition 43



2.6 OpenADR 45

2.6.1Definition 45


2.6.3PUC – Use cases 45

2.7 OCHP 46

2.7.1Definition 46



2.8 OSCP 47

2.8.1Definition 47



3 Flexibility Cloud Software Architecture .............................................................. 49

3.1 Starting point of the architecture 49



3.2 Functional specification and architecture 50

4 SGAM architecture ................................................................................................ 52

4.1 Function layer 56

4.2 Information layer 59

4.3 Communication layer 60

5 Conclusions .......................................................................................................... 63

6 References ............................................................................................................. 64

7 Annex 1 - Flexibility services in detail ................................................................ 66

7.1 Flexibility services for DSO 66

7.2 Flexibility services for BRP 66

7.3 Flexibility services for Prosumers 67

8 Annex 2 – Azure components and microservices in the FCS .......................... 68

8.1 Azure components 68

8.1.1Azure SQL Databases 68

8.1.2Azure Table Storage 68

8.1.3Azure Cosmos DB 68

8.1.4Azure Blob Storage 69

8.1.5Azure Cache 69

8.1.6Azure Event Hub 69

8.1.7Azure Stream Analytics 70

8.1.8Azure Service Bus 70

8.1.9Azure Machine Learning 72

8.1.10 Azure Scheduler 73

8.1.11 Azure Service Fabric 73

8.1.12 Azure API Management 73



8.1.13 Azure Virtual Machines 74

8.1.14 Azure Application Insights 74

8.2 Microservice architecture in the flexibility cloud software 74

8.2.1Time Series Service 74

8.2.2Contract Service 75

8.2.3Graph Service 77

8.2.4Weather Service 78

8.2.5Prediction Service 78

8.2.6Solver Service / Optimization Service 79

8.2.7EV Charging Service 80

8.2.8Price service 82

8.2.9Asset Service 84

8.2.10 Control of Flexibility 84



Abbreviations and Acronyms

Acronym Description

AF Aggregated Forecast

AFP Aggregated Flexibility Plan

BRP Balance Responsible Party

BS Balance Scheduling

CEM Customer energy management system

CPO Charge Point Operator

CPO Charge point operator

DER Distributed Energy Resources

DFP Detailed Flexibility Plan

DMS Distribution management system

DSO Distribution System Operator

EC European Commission

EG3 Expert Group 3 - Regulatory recommendations for smart grid deployment

EMG Energy Management Gateway

EMSP E-Mobility Service Provider

EV Electric Vehicle

EVSE Electric Vehicle Supply Equipment

FCS Flexibility Cloud Software

FEP Front End Processor

FO Flexibility Operator

GA Grant Agreement

HLC High-Level Communication

IEC International Electrotechnical Commission

IIP Integrated INVADE Platform

LEC Local Energy Community

LV Low Voltage

MR Meter Reader

MV Medium Voltage

OCHP Open Clearing House Protocol

OCPI Open Charge Point Interface

OCPP Open Charge Point Protocol



Acronym Description

OM Operation meter

OpenADR Open Automated Demand Response

OSCP Open Smart Charging Protocol

PTU Program Time Units

PV Photovoltaic

SDC Smart device controller

SGAM Smart Grid Architecture Model

SM Smart Meter

TLC Traffic Light Concept

ToU Time-of-Use

TSO Transmission System Operator

UC Use Case

USEF Universal Smart Energy Framework

V2B Vehicle to Building

V2G Vehicle to Grid

V2H Vehicle to Home

WP Work Package



Executive summary

This document is part of the WP4 (Overall INVADE architecture), which main objectives

are to design the general INVADE system architecture and the software architecture of

the Flexibility Cloud as a base for its implementation. In addition, the interface,

communication and physical connections of the users to the Flexibility Cloud platform

will also be specified.

In particular, this deliverable includes a description of the INVADE concept, its SGAM

layers, defined components, data flows and relations between different assets to

implement the Flexibility System developed in tasks T4.1, T4.2 and T4.3.

The document starts with an overview of the available flexibility management frameworks

and how the flexibility operator role is defined in the INVADE project. Following, the

flexibility services, flexibility sources and use cases are described. Then, a description

of the flexibility sources and services that can provide more added value to each use

case is done. In addition, the traffic light concept that determines which service has

higher priority in each moment, the interface mechanisms with BRP/DSO and customers,

and the baseline definition are described.

Section 2 introduces the reader to the concepts and characteristics of existing

communication standards and protocols on smart grids, with special focus on standards

in the e-mobility chain and the smart charging, and providing information about the

functionality of these protocols.

Next section describes the IT architecture for the Flexibility Cloud Software (FCS), which

uses the eSmart Systems platform and the architecture developed in the EMPOWER

project as a starting point. This platform runs on Microsoft Azure and is based on a

microservice architecture pattern.

Then, the SGAM methodology is summarised and, following its guidelines, the

component layer and the function layer are built. Following the same methodology, the

present deliverable identifies the communication protocols and information exchanges

required and reflects them in the so called information and communication layers, without

constraining them to the available services and infrastructures in pilots.

The concept design described in this document will be further developed and detailed

for each of the implemented use cases and pilot sites, which will be included in the

deliverable D4.2.



The outcomes of this deliverable are an input for WP5 (Flexibility management system),

WP7 (Communication platform) and WP8 (Integrated INVADE platform) in order to

proceed with the implementation of the INVADE platform. In addition, it is also an input

for WP10 (Pilots), as it provides a general description of the generic architecture so that

it can be easily adapted to the specificities of each pilot site for implementation.



1 Concept design

1.1 Introduction

The presence of more intermittent distributed generation, the empowerment of

consumers and new electric loads like electric vehicles are forcing the power system to

evolve. Past centralized, dispatchable and predictable generation provided flexibility at

transmission level to the electric system to balance generation and demand. Now, the

increasing number of installed distributed renewable generation is transforming the

generation side in a more variable and intermittent source of energy that needs to be

managed adequately. In addition, the demand side is becoming more active, which

emphasizes the empowerment and engagement of consumers. The proper management

of available flexibility, both in generation and demand side, can help to compensate the

lack of certainty of renewable sources.

Several studies and institutions have tried to address this issue and proposed its own

methodology and mechanisms to implement flexibility management.

The European Commission (EC) has published three mandates to promote Smart Grid

standardization process. One of these mandates, the M/490, aims to support European

Smart Grid deployment, and under its umbrella, flexibility issues have been addressed

at European level to try to standardize its development.

According to CENELEC/CEN/ETSI [1], grid users can provide flexibility with their

production, storage and consumption, which then can be used for energy services, and

system or grid operations, even directly or through a flexibility market. Figure 1 shows

the conceptual model of this flexibility flow. It also defines the flexibility operator (FO) as

a bundled role that pools the small flexibilities of customers or network users in order to

make use of them in the grid or on energy markets. Although its name and specific tasks

can vary depending on the reference, its main responsibility is to act as an intermediary

between a supplier and a user of flexibility.

Under the same framework, the Expert Group 3 (EG3) - Regulatory recommendations

for smart grid deployment of the Smart Grids Task Force that was set up by the European

Commission identified the roles to provide and use flexibility in [2]. Here the flexibility

operator is referred to as aggregator, as its main function is to aggregate the load or

generation of various demand and/or generation/production units. In fact, in other

references like in IEC 62913-1, it is also known as flexibility aggregator. Under this vision,



the aggregator role is closely related to the role of the supplier, which offers both energy

supply and flexibility offers. In that sense, the aggregation service provider role can be

taken by a third party aggregator or by an energy supplier.

Figure 1: General flow of flexibility model according to [1].

Figure 2 shows the relations between market roles to provide flexibility. Prosumers, by

means of their own consumption flexibility or different forms of distributed generation and

storage, can provide flexibility through flexibility purchase contracts. The Balance

Responsible Party1 (BRP) is in charge of the imbalances of the power exchange market.

Any flexibility use initiated by a third party aggregator could result in an imbalanced

situation for the BRP and the supplier, if not taken into account properly in the settlement

process. For that reason, the BRP would like to establish financial adjustment

mechanisms to avoid having unfair costs incurred through the fulfilment of its balancing

requirements, especially if a third party flexibility request does not benefit the BRPs

balancing position. In addition, Distribution System Operators (DSOs) should have the

opportunity to use flexibility services to mitigate potential conflicts with distribution

network operation.

In a similar way, the Universal Smart Energy Framework (USEF) Foundation created a

detailed framework to provide an integral market design for the trading of flexible energy

use [3] [4]. The full interaction model from USEF can be seen in Figure 3. The model

1 A market- related entity or its chosen representative responsible for its imbalances [2].



combines the current supply value chain with the flexibility value chain. The roles in the

supply value chain are responsible of providing energy, and the roles in the flexibility

value chain are solely responsible of providing flexibility. USEF introduces a new market-

based coordination mechanism, which is aligned with current processes and fits on top

of existing markets.

Figure 2: Possible relations between market roles to provide flexibility [2].

Under this framework, the flexibility operator is again referred to as aggregator. The

aggregator has a central role within the flexibility value chain in USEF framework, as it

is responsible for acquiring flexibility from prosumers, aggregating them into a portfolio,

creating services that draw on the accumulated flexibility, and offering these flexibility

services to different markets, serving different market players. In return, the aggregator

receives the value it creates with the flexibility on these markets and shares it with the

prosumer as an incentive to shift its load. Through the aggregator, prosumers gain

access to the energy markets.

Based on the framework specifications, USEF also provides a fully functional software

implementation. This works as a starting point for third parties aiming to commercially

exploit all or part of the USEF framework, or aiming to develop products and services

built on top of the USEF framework.



Figure 3: The full USEF interaction model with the supply and flexibility value chains [3].

As it can be seen in these examples, flexibility management is a hot topic and there are

some undergoing initiatives trying to standardize and provide common understanding of

flexibility usage in the distribution grid. Despite this, there are still things open or under

research regarding this topic. The more relevant ones are:

§ Optimization strategies. The optimization strategy cannot be standardized and it

will be different for each flexibility operator based on its own requirements and

characteristics.

§ Specific market and business models. A number of possibilities exist regarding

future market designs and energy related products that will affect flexibility

management. For that reason, it is needed to develop appropriate business models

that allow flexibility usage and bring value to all involved participants.

§ Proper regulation framework. There are some legislative initiatives in progress to

facilitate the introduction of smart grids addressing national and European grid

codes, laws and regulation. These will directly affect the development of business

models and use cases regarding flexibility management. A proper new regulatory

framework has to be created to boost flexibility usage. Especially, there is a lack of

standard definitions of flexibility measurements and baseline cases.

These points will be addressed along the INVADE project.

In the following sections, the INVADE approach to the flexibility management and other

related topics are described.



1.2 Flexibility operator concept

According to CEN-CENELEC-ETSI [1], Flexibility Operator (FO) is a role that pools the

small flexibilities of customers or network users in order to make use of them in the grid

or on energy markets.

FO is an independent role that can offer its flexibility services to BRP, DSO, TSO or final

customers. Moreover, the FO role can be played by different current agents like the BRP

or remain as a new independent agent. FO portfolio can be composed by different

distributed energy resources and they can be organized in local energy communities.

Services offered to each of them may be different and can be subject to the following

restrictions:

§ To offer services to the BRP, the FO must have enough customers in its portfolio

that are also customers of this BRP.

§ As FO has not the role of a BRP, FO does not participate in the wholesale markets

directly. Only under command of the BRP.

§ To offer services to the DSO, the FO must have enough customers in its portfolio

with grid access to the same part of the grid where the flexibility services are

requested.

§ Services offered to the TSO are out of the scope of this project.

Figure 4: Flexibility operator relation with BRP portfolio and wholesale markets

Wholesalemarkets

BalanceResponsiblepartyportfolio

LikeSESPorcurrentretailers

C1 C2 C3

C4

C5

C6 C7

C8

C1Customer1=Customer1-8belongtothesameBRPOnlyC1-3tradeflexibilitywiththeFO

EnergytradeBids&OffersFlexibility

operatorportfolio



Although under this approach several FO can offer their services to the same BRP and

one FO can offer its services to several BRP, in the project implementation it can be

assumed that there is only one FO offering its services to only one BRP and all flexibility

providers belongs to the same BRP portfolio. The same happens in case of providing

flexibility services to the DSO, as all flexibility providers will be connected to the same

DSO and they have to be grouped by grid zones or local energy communities.

The proposed system approach is peer-to-platform, which means that the FO acts as a

centralized intermediary between a supplier of flexibility and a user of flexibility. It can be

done by a completely centralized system, like the one represented in Figure 5.

Figure 5: Flexibility flow using a centralized operator to link flexibility sources and flexibility customers.



Figure 6: Flexibility flow using a centralized operator with external flexibility providers.

According to the tentative business model developed in WP9 and exposed in D3.1 [5],

there is a necessity to interact with other intermediate platforms between the FO and the

flexibility sources.

Figure 6 exposes all possible interactions considered in INVADE project grouped in two

categories: Upstream for using flexibility and downstream interactions for providing

flexibility. Upstream interactions include BRP/DSO and FO, and they are focused on

defining the need of using flexibility. In contrast, downstream interactions include FO and

flexibility provider interactions, and their objective is to provide flexibility. Flexibility

providers can be distributed energy resources (DER) directly or through a third-party

platform aggregating DER.

According to this approach, the FO acts as a service provider whose platform can be

seen as a high level platform that has interfaces to interact with other current platforms

that has direct access to flexibility sources. The FO platform offers services on top of

other control platforms, which facilitates large scale deployments.

Additionally, control decisions are made centrally based on contracts and previously

shared information. The customer interface mechanism is exposed in section 1.8.2.

1.3 Flexibility services

Literature has been extensively reviewed for standard definitions on flexibility services.

From this review, several flexibility services have been identified. They are normally

classified in function of the flexibility customer, namely, DSO, BRP, TSO and Prosumer.



By its applicability to the European context, two sources have been identified as key

references to define the INVADE services. One of them is the USEF framework [3] [4]

which delivers one common standard on which to build an integral market for the trading

of flexible energy usage. The other are the conclusions and advices regarding flexibility

implementation from the Expert Group 3 (EG3) - Regulatory recommendations for smart

grid deployment of the Smart Grids Task Force that was set up by the European

Commission in 2009 to advise on issues related to smart grid deployment and

development.

Table 1 shows all the identified flexibility services using two labels from these two

references: USEF [3] [4] and EG3 [2]. In Table 1, the first column of the flexibility

references identifies the services covered by the USEF framework [3], while in the

second column there are the services covered by the first stage of the USEF

implementation [4]. According to the objectives and scope of the project, in the concept

design task (T4.1) the flexibility services that can be interesting to be used in INVADE

project have been selected, which are indicated in the last column. These selected

services are further described in the Annex 7 and in the Deliverable D5.1 of the INVADE

project [6]. The implementation of these services in the project is conditional to the

specific needs of each pilot. For instance, the Spanish pilot included the controlled

islanding in the prosumer facilities as an additional service after D5.1 publication [6].

As it can be seen in Table 1, not all services are equally addressed in both references.

Some of them are not covered by both references while others cover almost the same

concept but its name is different.

For example, although in [2] there is a distinction between short term and long term

congestion management, from the perspective of the flexibility provider the difference

between short and long term congestion management is very thin. Even both services

try to avoid grid congestions, short term belongs to the operation framework on the daily

basis, and long term belongs to the distribution grid planning division on the years ahead

term horizon. Even if the scope of INVADE project is more connected to solve the short-

term problem (with respect to the duration of a grid reinforcement project) for the DSO

that requires a relatively swift response, the unified term “congestion management” is

going to be used to identify this service for DSOs.



Table 1: Flexibility services covered by INVADE. (Y: yes; N: no)

Flexibilitycustomer

Flexibilityservicesnames FlexibilityreferencesUSEF EG3 USEF USEF15 EG3 INVADE

DSO

CongestionmanagementShorttermcongestionmanagement

Y Y Y Y

CongestionmanagementLongtermcongestionmanagement

Y Y Y N

VoltagecontrolVoltage/Reactivepowercontrol

Y N Y Y

Gridcapacitymanagement(Gridlosses) Y N Y NControlledislanding - Y N N YRedundancy(n-1)support - Y N N NPowerqualitysupport - N N N N

BRP

Day–aheadoptimization Portfoliooptimization Y Y Y YIntradayoptimization Portfoliooptimization Y Y Y YSelf-balancing Portfoliooptimization Y Y Y YPassivebalancing - Y Y N N

GenerationoptimizationGenerationcapacityadequacy

Y Y Y N

TSO

Primarycontrol Frequencycontrol(FCR) Y N Y NSecondarycontrol Frequencycontrol(FRR) Y N Y NTertiarycontrol Frequencycontrol(RR) Y N Y NNationalcapacitymarket - Y N N NCongestionmanagement CongestionManagement Y N Y NGridcapacitymanagement(Gridloses) Y N Y NControlledislanding - Y N N NRedundancy(n-1)support - Y N N N- Reactivepowercontrol N N Y N

Prosumer

ToUoptimization - N N N YKWmaxcontrol - N N N YSelf-balancing - N N N YControlledislanding - N N N Y

Power quality services at distribution level are treated locally and the Integrated INVADE

Platform (IIP) does not have to take any actions on that. Therefore, this is not considered

as a centralized service to be provided by the IIP. However, devices installed at pilot

sites can include power quality control capabilities that will work autonomously.

None of the TSO services will be implemented in INVADE as the transmission system is

out of the project scope.

Flexibility services that have Prosumers as flexibility customers are not covered by both

references as they represent the existing approach in most demand response programs,

although [3] also identified and described them. These services are key to achieve the



empowerment of consumers through self-generation and self-consumption of electricity,

so they need to be covered in the INVADE project.

1.4 Flexibility sources

Flexibility can be provided by different flexibility sources that can be grouped into storage,

load, generation, and EV. INVADE project is mainly focued on storage and EV flexibility

sources, but other sources like load and generation will also be taken into account when

available.

Another categorization can be done based on the controllability of the flexibility source.

According to [1] and shown in Figure 7, they rank from no flexibility for uncontrollable

sources to freely controllable sources. Curtailable loads are those that do not need to

recover the curtailed energy once they are reconnected. This type of loads can be for

example programmable space heaters with a clock to disconnect after a certain time. In

contrast, shiftable loads are those that can postpone the consumption out of the base

line like heat pumps and space heaters.

Other load types can have several flexibility properties and its categorization depends

on the way they are operated, like EVs, which can be categorized as both curtailable,

shiftable and buffered. Regarding generation, examples of curtailable sources

(completely or partially) can be wind or solar power, while micro-gas turbines and

combined heat and power units are an example of freely controllable distributed

generation (if unlimited fuel supply is assumed). According to the Spanish distribution

network operation code under discussion, distributed energy sources with more than 800

W have to be capable to be disconnected remotely if the DSO needs it. Additionally, if

they have more than 100 kW, they have to be capable to receive an external set point

control signal setting their maximum output power. Flexible generators with this capability

are labelled as reducible generators. If they can only be disconnected completely, they

are labelled as disconnectable generators.



Figure 7: Categorization of flexibility sources [1]

Table 2 shows the available flexibility sources and its main characteristics: regulation

capabilities, domain and scale.

Table 2: Flexibility sources covered by INVADE.

ClassificationRegulationcapabilities

Domain Scale

Class Type

Dow

nward

regu

lation

Upw

ard

regu

lation

Custom

er

prem

ises

LVgrid

MVgrid

Low

flexibility

capa

city

Med

ium

flexibility

capa

city

High

flexibility

capa

city

Storagecontrol

Batteryathouseholds X X X X

Centralizedbattery(LVgrid) X X X X X

Centralizedbattery(MVgrid) X X X X X

Loadcontrol

Disconnectableload X X X Shiftableload(constantprofile) X X X X

Adjustableorshiftableload(constantenergy)

X X X X

Generationcontrol

DisconnectableDER X X X X

AdjustableDER X X X X X

DisconnectableDERplant X X X X X

AdjustableDERplant X X X X X X

EVcontrol

EVchargingstation(multiplechargingpoints)

X X X X

EVchargerathousehold X X X

EVpublicchargepoint X X X EVchargingstationwithV2G(multiplechargingpoints)

X X X X X

EVchargerathouseholdwithV2G X X X X

EVpublicchargepointwithV2G X X X X

Regarding the regulation capability of the flexibility source, they can be classified into

downward and upward regulation. In case of surplus energy in the system, the system



needs to neutralize the surplus by activating bids for downward regulation.

Consequently, the player will reduce his production or increase his consumption.

Disconnectable loads cannot offer downward regulation. In general terms, EVs without

V2G are not considered for downward regulation as they have very limited control

capabilities. However, if EVs are controlled as shiftable loads, they can be also

considered as downward regulation sources, although they have less potential than V2G

chargers, batteries or flexible generators. In case of a deficit of energy in the system, the

system needs to neutralize the deficit by activating bids for upward regulation.

Consequently, players will increase their production or reduce their consumption. DER

with no adjustable capability cannot offer upward regulation.

The domain characteristic defines the place where the flexibility source is installed:

customer premises, LV grid or MV grid. Customer premises domain includes industrial,

commercial and household facilities behind the meter where the electricity users interact

with the distribution system. They are normally small storage, different types of loads, or

a private EV charger point. LV grid domain represents the LV distribution grid, from

customer premises to secondary substations. It includes small and medium DER plants,

medium storage systems, or charging stations connected to the LV grid. MV grid domain

is representing MV distribution grid, from secondary to primary substations. It includes

large DER plants, large storage systems, and large charging stations connected to the

MV grid.

Some flexibility services need a minimum quantity of flexibility to be used. If this minimum

quantity is not achieved, they need to be aggregated to be fully functional. The scale

classifies the capacity of the flexibility resource into low flexibility capacity (< 50 kWh),

medium flexibility capacity (>50 kWh and <1 MWh), and high flexibility capacity

(>1 MWh).

1.5 Use cases

The INVADE platform will be tested and validated in five different countries investigating

four use cases (UC):

§ Use case 1: Mobile energy storage using EVs for V2G, V2B and V2H

operations

The use case involves mobile energy storage using EVs with focus on V2G, V2B

and V2H operations along with higher renewables integration. The research and

innovation components to be researched, developed and piloted here are: flexibility



management system including demand-response schemes, integration of

renewables, EV battery life-cycle analysis, energy informatics, users’ practises and

behaviour analysis as well as specific business models related to EV-based

storage services involving individuals, communities, business establishments,

energy retailers, aggregators and DSOs. This use case will demonstrate a link to

the transport sector using renewable energy sources in each pilot site.

§ Use case 2: Centralised energy storage using an array of batteries at the sub-

station or street level

The use case involves a centralized energy storage unit comprised of an array of

smaller batteries at the substation and/or community level. The research and

innovation components piloted here are: power quality improvement, demand

management, back-up provision, demand response schemes, models for optimal

array configuration, sizing, positioning and scheduling of storage units in the

distribution grid, risk assessment and business models involving DSOs and

communities. This use case will demonstrate the applicability of large scale

centralized storage units at the substation/street level to demand side

management, power quality improvement and emergency back-up operations. The

deployed capacity of the centralized storage unit will be 200 kWh.

§ Use case 3: Distributed energy storage using individual batteries at the

household level

The use case focuses on distributed energy storage units spread across multiple

households. The research and innovation topics associated with this pilot are:

agent based flexibility management, demand response, life cycle and cost-benefit

analysis of batteries based on charging and discharging cycles, effect of self-

consumption from PVs, energy informatics, visual user interface for battery

monitoring and specific business models for incentivizing the use of batteries at

household level. The use case will showcase the benefits of distributing storage

units across households.

§ Use case 4: Hybrid level energy storage solutions addressing a combination

of use cases 2 and 3

The use case implements a hybrid/combination of centralized and distributed

energy storage units at both substation/street and household levels (a combination

of use cases 2 and 3). The research and innovation components piloted here are

optimal distribution configuration and sizing of energy storage units, analysis of



benefits obtained from combining energy storage at different levels, demand

management, energy informatics, risk assessment and business models involving

both DSOs and households.

1.6 Application of flexibility to the use cases

In this section, the flexibility sources and services that can provide more added value to

each use case are described. This evaluation will be used to select flexibility sources

and services in each pilot according to its specific necessities and the concepts to be

proved according to its use case.

1.6.1 Flexibility services in each UC

Table 3 relates suggested flexibility services from INVADE integrated platform to each

UC. They are classified under categories High (H), Low (L) and No (N) added value. In

general, high added value is identified as the most interesting services for the UC. Low

categorization can be due to several reasons like different countries could get different

values for each service. The following paragraphs explain the reasons behind this

categorization.

Table 3: Flexibility services added value to each UC. (H: high; L: low; N: no)

Flexibilitycustomer

FlexibilityservicesINVADE

Usecases(UC)

UC1:Mobilestorage

UC2:Centralizedstorage

UC3:Distributedstorage

UC4:Hybrid

DSO

Congestionmanagement H H L HVoltage/Reactivepowercontrol H H L HControlledislanding N H N H

Day–aheadportfoliooptimization L L N LBRP Intradayportfoliooptimization L H L H Self-balancingportfoliooptimization H H L H ToUoptimization L N H H

Prosumer kWmaxcontrol H N H H Self-balancing L N H H Controlledislanding N N H H

1.6.1.1 Use case 1: mobile storage

The Flexibility Operator (FO) can get different added values thanks to the control of

electric vehicles as mobile storage units.



Value for DSOs for congestion management and voltage control

During the grid operation in the daily basis, EV Supply Equipment (EVSE) with control

capabilities can provide flexibility to avoid short term congestions and voltage violations.

That means that the FO can reduce their consumption, switch them off or even discharge

EV batteries if the EVSE are V2G capable. Both services can be very valuable (H) for

congested distribution grids with intermittent demand peaks.

Value for BRPs for self-balancing portfolio optimization

EVSE can shift the load consumption and/or discharge EV batteries in V2G-EVSE to

compensate unbalances in BRP portfolio. The operation range corresponds to a few

hours or even minutes ahead to have higher certainty about their availability and this

service is very valuable for BRP (H).

Value for BRPs for day-ahead and intraday portfolio optimization

The value from EVSE and charging stations for BRPs for managing its portfolio in the

day-ahead and intraday markets is low (L) because of the uncertainty of EVSE flexibility

availability one day-ahead or hours ahead.

Value for Prosumers for kWmax control

EVSE at households can provide high value (H) if the prosumer is penalized for its

consumption in terms of maximum power or maximum energy per time period. EVSE in

households with control capabilities can postpone the EV charge after the peak demand

reducing the prosumer’s electricity bill.

Value for Prosumers for ToU Optimization and Self-Balancing

EVSE at households can shift the EV charge to the most interesting periods. For

example, to low cost periods in ToU tariffs or PV production periods. The potential value

for prosumers is less interesting (L) than the kWmax control for two reasons:

§ The current ToU tariffs in Europe are not very volatile, then the cost savings with

this capability is less profitable in general terms. In the future this can be different

but not in the current market based on the ToU retail prices. This is different in

countries like Spain where very low price tariffs are incentivised for charging EV

after 1 am.

§ Probably, the EV will be in the office when the PV at household is exporting energy

during the weekdays in common cases for prosumers. Additionally, the EV can be

travelling away during the weekends as well.



For these reasons both services are less interesting (L) than the kWmax control.

Implications for INVADE pilots

§ To increase the added value for DSOs, the EV charging station has to include at

least one V2G EVSE.

§ EVSE have to include control capabilities and receive control signals from the

INVADE platform to provide flexibility services.

§ To apply the self-balancing service for prosumers, the “local controller” needs to

have a certain smartness to control the power/energy consumption effectively.

1.6.1.2 Use case 2: centralized storage

The added value from centralized storage units is different for the FO than the mobile

storage units. Basically, stationary batteries are always connected in contrast with EVs,

and their energy capacity is higher compared to distributed storage or EVs. Due to both

characteristics, the added value for flexibility customers are as follows.

Value for DSO

In terms of operation and planning phases, centralized storage units provide high value

(H) to increase distribution grids hosting capacity. Centralized units can be operated to

reduce the maximum load or generation peaks discharging or charging them

respectively. In addition, centralized storage can provide controlled islanding services in

a given grid section if the power converter includes this functionality.

Additionally, if the battery inverter has a remote control capability, it can provide active

and reactive power to compensate over voltages or voltage drops or to alleviate network

constraints.

Value for BRP

The usage of centralized batteries in electricity markets for portfolio optimization has

been deeply discussed in the research literature and different studies analysed their

profitability in different markets. Majority of studies agree on the prioritization of markets

from the highest to the lowest profitable markets as balancing, intraday and day-ahead

markets.

This depends a lot of each country but the usage of centralized batteries for portfolio

optimization purposes is very interesting for BRP (H) except for day-ahead markets. The

lack of a specific bidding products for batteries in the day-ahead market, like “linked block



orders”, makes day-ahead bidding strategies very complicated, risky and therefore less

profitable (L).

Value for Prosumer

As the centralized storage unit is in front of the prosumer’s meter, it cannot provide

benefits behind the meter for reducing prosumer’s electricity bill (N). Nevertheless,

services like community energy storage acting as an energy bank for prosumers could

be interesting for prosumers and it is included in the BRP domain doing portfolio

optimization.

Implications for INVADE pilots

§ Battery inverters should include the control capability to receive active and reactive

control set points remotely.

§ It is desirable that Battery inverter includes Volt/var and/or Volt/Watt local control

capabilities for the short time response requested by the DSO.

1.6.1.3 Use case 3: distributed storage

The potential benefits from distributed storage units spread in the distribution grid are

analysed in this UC. All services are classified per flexibility customer. In this UC, storage

units have less storage capacity and they are distributed in the grid and connected

behind the household meters.

Value for DSO

The grid constraints that distributed storage units can solve are limited to rural areas with

long lines with voltage problems. Therefore their flexibility value is considered as limited

(L).

During the operation phases, storage units can control the energy discharge or charge

from households and then the voltage and saturation can remain within the limits but

their capacity to discharge power during high demand periods could be not enough to

solve all technical problem.

This capability has an impact on the DSO planning decisions to estimate the new

capacity needed but its impact is limited (L).

Value for BRP

The usage of distributed storage units has a limited impact in portfolio optimization

problems due to their limited capacity per unit if the portfolio has not enough units. For



this reason, the usage of these resources in portfolio management is limited (L) or even

null (N).

Additionally, current day-ahead markets are not volatile enough to generate profits

charging and discharging batteries if the small-scale battery cost is considered. This is

different in the centralized battery case because of the effect of economies of scale.

Value for Prosumer

For the prosumer’s case, distributed storage units can provide high added value (H)

discharging during the high price periods (ToU Optimization), avoiding consumption

peaks (kWmax Control) and storing energy during the surplus periods when the PV

power generation is higher than the consumption (self-balancing).

In addition, distributed storage can provide controlled islanding services behind the meter

to their households or buildings during grid outages.

Implications for INVADE pilots.

§ Household battery inverters should include local control capabilities to avoid

overvoltage problems during PV production periods (Voltage control)

§ Household battery inverters should include local control capabilities to avoid

consumption peaks to avoid penalties (kWmax control)

§ Household PV inverters should also include local control capabilities, like those

used with the batteries.

This would increase the integration of renewable generation in distribution grids.

Use case 4 is a combination of UC 2 and 3, consequently the relation between services

and the use case 4 is the same as in these previous UC.

1.6.2 Flexibility sources for each flexibility service

Flexibility services can also be evaluated in function of the suitability of the sources that

can provide this flexibility. In Table 4 this evaluation is summarized, classifying the

flexibility sources under categories High (H), Low (L) and No (N) added value to each

service.

Value for DSO



To provide congestion management services, it is necessary to have high volumes of

flexibility capacity (centralized storage, generation plants or EV charging stations) or to

be easily aggregated (loads at households). In contrast, for the voltage/reactive power

control service, sources installed at prosumer or consumer premises are more

convenient than the ones installed at centralized sites. In addition, centralized storage,

adjustable DER plant and EV charging stations with V2G can help to match generation

and demand to provide controlled islanding services in a given grid section.

Value for BRP

As stated in section 1.6.1.2, centralized storage is very interesting for portfolio

optimization purposes. However, the lack of a specific bidding products for batteries in

the day-ahead market makes day-ahead bidding strategies more complicated and risky.

Other useful sources for portfolio optimization, apart from day-ahead optimization, are

generation resources, and batteries and loads behind household meters. EV chargers

with V2G capability can also be very useful for self-balancing portfolio optimization

purposes.

Value for Prosumer

At local level, distributed storage, load control and EV chargers are highly apropiate to

provide added value to prosumer services. However, batteries at households may have

less potential value for prosumers in ToU optimization or self-balancing than the kWmax

control. This could be different case by case.

Distributed generation control can also help to match generation and demand to provide

local controlled islanding services in a given household or building.



Table 4: Flexibility sources added value to each flexibility service. (H: high; L: low; N: no)

Flexibility

customerFlexibilityservicesINVADE

Storage

controlLoadcontrol Generationcontrol EVcontrol

Batteryathouseholds

CentralizedbatteryatLVgrid

CentralizedbatteryatMVgrid

Disconnectableload

Shiftableload(constantprofile)

Adjustableorshiftableload

(constantenergy)

DisconnectableDER

AdjustableDER

DisconnectableDERplant

AdjustableDERplant

EVchargingstation(multiple

chargingpoints)

EVchargerathousehold

EVpublicchargepoint

EVchargingstationwithV2G

(multiplechargingpoints)

EVchargerathouseholdwithV2G

EVpublicchargepointwithV2G

DSO

Congestionmanagement L H H H H H L L H H H L L H H HVoltage/Reactivepowercontrol H L L L L L H H H H L L L H L LControlledislanding N H H L L L N N N H L N N H N N

BRP

Day–aheadportfoliooptimization L H H L L L L L L L N N N N N NIntradayportfoliooptimization H H H L H H H H H H N N N L L LSelf-balancingportfoliooptimization H H H H H H H H H H L L L H H H

Prosumer

ToUoptimization L N N H H H N N N N H H N H H NkWmaxcontrol H N N H H H N N N N H H N H H NSelf-balancing H N N H H H L L N N H H N H H NControlledislanding H N N H H H H H N N H H N H H N



1.6.3 Flexibility sources in each UC

Similarly to section 1.6.1, Table 5 relates available flexibility sources to each UC defined

in INVADE project. They are classified under categories High (H), Low (L) and No (N)

added value. In general, high added value is identified as the most interesting flexibility

source for the UC. The following paragraphs explain the reasons behind this

categorization.

Table 5: Flexibility sources added value to each UC. (H: high; L: low; N: no)

Class Type

Usecases

UC1:Mobilestorage

UC2:Centralizedstorage

UC3:Distributedstorage

UC4:Hybrid

Storagecontrol

Batteryathouseholds L N H HCentralizedbatteryatLVgrid L H N HCentralizedbatteryatMVgrid L H N H

Loadcontrol

Disconnectableload L N H HShiftableload(constantprofile) L N H HAdjustableorshiftableload(constantenergy)

L N H H

Generationcontrol

DisconnectableDER L L H HAdjustableDER L L H HDisconnectableDERplant L H L HAdjustableDERplant L H L H

EVcontrol

EVchargingstation(multiplechargingpoints)

H H L H

EVchargerathousehold H N H HEVpublicchargepoint H N L HEVchargingstationwithV2G(multiplechargingpoints)

H H L H

EVchargerathouseholdwithV2G H N H HEVpublicchargepointwithV2G H N L H

Under UC1, the most important sources are related to the EV control (H), as it is

concentrated on the use of mobile energy storage using EVs with focus on V2G, V2B

and V2H operations. Other flexibility sources can be part of this UC but with a

complementary role (L).

The UC2 is based on the use of centralized storage. For that reason, devices installed

at households are not the main focus of the UC (N), even if they are batteries, loads or

EV chargersIn this UC, only centralized devices provide high added value.



In contrast to UC2, UC3 is centered in the use of distributed energy storage units spread

across multiple households. In this case, the sources that provide high added value are

those batteries, loads, generation and EV chargers installed at household level.

Finally, as UC4 is a mixture of UC2 and UC3, all kind of flexibility sources can contribute

to this hybrid UC.

1.7 Traffic light concept (TLC)

It is necessary to classify and prioritize sources, services and use cases because a multi-

service approach of storage units usage involves high risks and the operational problem

could have not a feasible solution.

The traffic light concept (TLC) can help to determine which service has higher priority in

each moment, based on the current and forecasted condition of the grid [1] [7]. The TLC

defines three different states:

§ Green state: is the “normal operating state”, where the “flexibility market”

competitively operates freely. Under this state, the system/grid operator may not

request flexibility services and market operation has the highest priority.

§ Yellow state: indicates the state where the system/grid operator actively engages

with the market in order to prevent the grid system from becoming unstable and

entering in the red state. Under this state, the system/grid operator may request

flexibility services and grid operation has the highest priority. It is a temporary state

until the grid operation becomes safe again.

Figure 8: Traffic Light Concept [1].



§ Red state: the system/grid operator needs to take control of market interactions in

a certain area where a grid constraint has occurred. Under this state, the grid

operator can override contracts existing in the market and execute dedicated

emergency actions through flexibility operators in order to re-stabilise the system.

The services offered to BRP, DSO, TSO or final customers/prosumers can be requested

at the same time and be contradictory. For this reason, it is necessary to classify them

according to the TLC zones in order to define their priority.

Table 6: Flexibility services to be offered in each grid state.

Flexibilitycustomer

FlexibilityservicesINVADEGridstate

Green Yellow Red

DSO

Congestionmanagement X X

Voltage/Reactivepowercontrol X X

Controlledislanding X X

BRP

Day–aheadportfoliooptimization X

Intradayportfoliooptimization X

Self-balancingportfoliooptimization X

Prosumer

ToUoptimization X

kWmaxcontrol X X

Self-balancing X X

Controlledislanding X

In red and yellow states, FO offers its available flexibility to the DSO (or TSO) to solve

or avoid problems in the grid, which should only occur in few specific occasions. These

services have higher priority than other flexibility requests, and consequently, it is

supposed to be highly rewarded. The DSO (or TSO) is responsible for the identification

of the grid state and necessities and for the notification of them to the FO. Controlled

islanding service at prosumer premises can also be performed in red state. In yellow

state, surplus flexibility not used to avoid grid problems (DSO services) can be used to

satisfy prosumer services such as kWmax control and self-balancing.

However, in green state flexibility can be offered to the BRP or to prosumers

interchangeably. Here, services to the BRP (portfolio optimization for instance) and to

the final customer have to compete for the same available flexibility. Before flexibility is

offered to other customers in an aggregated way, a prosumer can use its own flexibility

for in-home or building optimization. As a first approach, services to the BRP may be

less frequent but highly rewarded than the services to the final customer, which are

always present by default if no other flexibility request is in place. For that reason,



compensation to prosumers for providing flexibility to BRP should exceed the profits they

can obtain by the use of its own flexibility for its own benefit.

The TLC system could be useful for the pilots in INVADE, if they see a need for

prioritization between flexibility services.

Figure 9: Traffic Light Concept applied to the flexibility services and customers.

1.8 Interface mechanisms

1.8.1 BRP/DSO interface mechanism for using flexibility

In red or yellow grid states, the DSO (or TSO) should notify the FO its grid requirements

to avoid grid problems. This can be done under two different mechanisms: capacity or

control based signals.

§ Capacity based signals: signals based on maximum amount of consumption or

generation for a specific group of customers. These customers have to be placed

in a same grid zone defined by the DSO (or TSO). Figure 10 (a) shows a case

example of a local energy community (LEC) consumption in which their maximum

capacity defined by the DSO is 140 kWh.

§ Control based signals: signals based on specific amount of flexibility that has to be

activated. The DSO request can be for upward or downward regulation. In contrast

to the previous case, Figure 10 (b) shows the upward flexibility requested by the

DSO from a LEC in the same example.



(a) (b)

Figure 10: Example of LEC consumption with (a) aggregated consumption with its maximum capacity allowed at 140 kWh and (b) control based requested flexibility to avoid higher

consumptions than 140 kWh.

In order to compare pros and cons of each mechanism, the following comparison table

is provided:

Table 7: Capacity and control based mechanism comparison

Pros Cons

Capacity

based

The Integrated INVADE Platform (IIP)

has higher capacity to control the LEC

consumption/ production

The IIP requires more monitoring

capabilities

DSO & BRP algorithms to define

capacity limits can be based on

simple rules

FO operation procedures increase in

complexity

Control

based

The IIP needs less monitoring

capabilities

The IIP has lower capacity to control

the LEC consumption/production

Easier for the FO to use operation

algorithms

DSO & BRP require more complex

algorithms to define the control

request

The complexity in the DSO and BRP algorithms to define their requests is due to the risk

from the non-flexible assets performance. In the capacity-based mechanism, the FO

takes the responsibility of controlling all assets to perform within a certain limit. Therefore,

the FO has to monitor non-flexible assets aggregately and the operation procedures

increase in complexity because it has to compensate their non-expected performance.



The cost in monitoring systems has to be considered too. However, greater monitoring

capabilities allow the FO to control all LEC energy assets performance.

1.8.2 Customer interface mechanism for providing flexibility

Distribution-level energy management approaches can be classified in four categories

as Kok et al. [8] proposed: Top-down switching, centralized optimization, price-reactive

and transactive energy systems. Figure 11 shows classification categories (a) and their

pros and cons (b).

In centralized optimization approach, FO uses direct control signals of demand and/or

supply to manage customer’s resources. Figure 12 shows a direct control customer

interface mechanism for providing flexibility and the FO is cautioned by BRP/DSO.

Additionally, FO manages equipment of smart customers through an interface or directly,

and decisions are taken using a centralized optimization algorithm.

Smart customer interface involves local intelligence to activate flexibility at device level.

This approach requires local computational capabilities to take decisions. In contrast, if

the FO controls flexible assets directly, all smartness is located in the central entity and

the local equipment only applies the external signals. Therefore, the centralized

optimization approach requires cheaper equipment controlling DER than smart customer

interface. However, smart customer interface can deal with transactive energy control

mechanisms and decisions are taken locally.

The main drawback of centralized approaches for meeting BRP/DSO needs are the

privacy and autonomy issues. User energy preferences are exposed to the FO through

a flexibility contract and it is used to forecasts personal energy patterns. Additionally,

individual decisions are taken under a specific framework and some specific preferences

could not be considered by the FO. Nevertheless, the centralized approach with a single

manager of the energy community for negotiations with the BRP/DSO, and its central

trading platform, offers a simpler and more easy to implement interaction mechanism

between DSO/BRP and FO than transactive energy approaches.

Therefore, INVADE proposal is to implement a centralized approach with direct controls

for all interactions, especially between DSO/BRP and FO. It allows more control on

actions taken by the customer to deliver its flexibility and it is expected to have less

deviations and higher response certainty. Nevertheless, the IIP remains open to include

transactive mechanisms between FO and flexibility providers in further developments.



Figure 11: The energy management matrix: the four main categories of (a) smart grid energy management and (b) their pros and cons. Kok et al. [8]



Figure 12: Direct control of demand and/or supply use case [1].

1.9 Baseline definition

An agreed consumption and generation baseline is needed for all involved actors to have

a common understanding when doing the settlement process. The following baseline

definition has been proposed by the EG3 [2] and it is used in INVADE project:

“Baselines should balance accuracy, simplicity and integrity. They should be designed

to produce statistically valid and consistent results, unbiased in either over-predicting

or under-predicting actual performance. There are numerous reliable methodologies

and ICT solutions that are able to establish reliable baseline values, currently in use

throughout the world, and it is not necessary to re-invent the wheel when

implementing demand side flexibility into a market design.

A baseline is important to calculate the effective service provided by the aggregation

service provider and to avoid strategic users from being incentivized to emphasize

their individual benefits without real gain for the system. The baseline must make it

possible to differentiate services performed behind the same point of delivery, making

it possible to differentiate between the benefits of for example dynamic pricing and

specific demand side flexibility services valued by an aggregation service provider.”

In INVADE project the baseline is calculated by the FO and it is accepted by DSO and

BRP because of the lack of regulatory framework to establish a third party entity for these

tasks. However, the recommendation from INVADE project for future regulatory

proposals is to create a separated and regulated entity to define baselines and this new

entity should not have any incentive to over-predict or under-predict the energy assets

performance.



2 Review of standards in the e-mobility chain

Task 4.4 of the INVADE project aims to analyse, up-take and improve on the existing

communication standards and protocols on smart grids, with special focus on the

standards in the e-mobility chain and the smart charging. The goal of this section is to

reflect the work and results of this task, introducing the reader to the concepts and

characteristics of EV related standards protocols, and providing information about the

functionality of these protocols. This information is going to be used as an input to define

the communication layer in section 4.3.

The EV area comes with various market roles and their interactions using various

protocols being relevant to the INVADE pilot. At different locations, different

combinations of protocols are used for the same functionalities or different purposes.

Generally, there are two different types of standards and protocols relevant in the EV

domain. The ones that are developed “open” in Alliances or other consortia (consisting

of companies), in which everyone, in principle, can join and contribute. For their practical

approach they are called bottom-up standards

The other type of standards and protocols is embodied by large (institutional)

standardisation organizations, who define their standards and protocols from a more

theoretical top-down approach with participation from numerous country representatives.

Figure 13 shows the chain of systems connected to make EV driving and roaming

possible. On the left side, it starts with the EV that is connected to an Electric Vehicle

Supply Equipment (EVSE) for the actual charging. That connection also contains a data

exchange on the charging rate and, depending on the protocol, other information as well.

The EVSE is connected to a charge point operator (CPO) that is responsible for

supplying, installing, maintaining and repairing the charging points. To validate if the user

is allowed to charge the user identifier supplied by the EVSE is verified with the e-mobility

service provider (EMSP) which is responsible for selling the mobility products and

services. If allowed, the transaction takes place and the transaction details are sent to

the clearing house. The clearing house is an entity mediating between two clearing

partners to provide validation services for roaming regarding contracts of different CPOs.

Finally, as it is responsible for the voltage stability in the distribution grid, the DSO may

also exert influence on the rate of charging, for example to provide congestion

management.



Figure 13: Distribution of protocols in the EV chain.

In the following sections, the standards shown in Figure 13 and used in the e-mobility

chain are described.

2.1 ISO/IEC 15118

2.1.1 Definition

The ISO/IEC 15118 protocol specifies a communication standard between a charging

station and an EV. The ISO/IEC Joint Working Group 15118 for the Vehicle-to-Grid

Communication Interface (V2G CI) was founded in 2009. In this specification, a more

advanced form of communication is described, also referred to as High-Level

Communication (HLC). This enables EV’s to communicate information (e.g. how full the

battery is- state of charge) to a charging station, without intervention of the EV user

(autonomously) in a more advanced way.

2.1.2 Technical Characteristics

The main tenacity of the 15118 standard is to facilitate authorized charging sessions,

smart charging, EV charging and reservation. More specifically, this contains schedule

based charging, certificate handling by both the EV and EVSE and value added services

such as reservations. The three main actors covered in the specification are the Electric

Vehicle Communication Controller (EVCC), Supply Equipment Communication

Controller (SECC) and Secondary Actor, which can be an app or back-office system.

The protocol is defined in detail on the different ISO levels. The specification quite clearly

describes both the use cases, as well as the technical details of the protocol. �

EVSE DSOEMSPCPOEV

ClearingHouse

OCHPOICPeMIP

OCHPOICPeMIP

OCHPDirectOCPIOCPP OSCP

IEC61850-90-8

IEC/ISO15118

OpenADR&IEEE2030.5

IEC61850-90-8

IEC61851-1

Roaming

Smartcharging

EV<>EVSE EVSE<>CPO



2.1.3 PUC - Use Cases / application

Communication between EV and EVSE:

§ Certificate handling between EV

§ Authorize a charging session

§ EV charging

§ Reservation

§ Smart Charging

2.2 OCPP

2.2.1 Definition

The Open Charge Point Protocol (OCPP) has been designed and developed to

standardize the communication between a charging station and a back office, which is

used for operating and managing EVSE. The communication protocol is open and freely

available to ensure the possibility of switching from charging network without necessarily

replacing all the charging stations or significant programming, including their

interoperability and access to electric grid services. OCPP, managed by the Open

Charge Alliance, has become the de facto open standard for charger to network

communications in many countries, including in Asia, Europe and parts of the U.S.


OCPP is an application layer protocol consisting of around 28 messages in either SOAP

or JSON over Websockets format, mainly servicing authorization, transaction and smart

charging functionalities. It does not only describe messages, but also the related

behavior of the central system and charging station is included in the protocol.

2.2.3 PUC - Use Cases / applications

Communication between charging station and backoffice:

§ Authorize charging session �

§ Billing �

§ Manage grid �



§ Operate Charge Point �

§ Reservation �

§ Smart Charging �

§ Non- EV related battery management �

2.3 IEC 61851-1

2.3.1 Definition

IEC 61851-1 edition 2 is a standard published in 2010, which concerns basic charging.

It is an official IEC standard, created by the “IEC technical committee 69 (TC69): Electric

road vehicles and electric industrial trucks”. The 2010 edition replaces the first edition

from 2001, Edition 3 is under development. The IEC 61851-1 standard from 2010 is the

second edition of the protocol. It is currently the standard for EV charging in Europe. It

can be tested and certified at different certification / test laboratories. �


The IEC 61851-1 describes 4 modes for EV charging. In short, these modes refer to:

§ Mode 1: basic AC charging to a maximum of 16 A / 1x250 V / 3x480 V. �

§ Mode 2: basic AC charging to a maximum of 32 A / 1x250 V / 3x480 V including

some additional features, such as standardized socket-outlets, power and

protective earth �conductors together with a control pilot function and system of

personnel protection against electric shock. �

§ Mode 3: AC charging with basic signaling (i.e. Pilot Control Function) where the

control pilot �function extends to control equipment in the charging station, gaining

the ability to activate / �deactivate the power flow and set charging rate limits. �

§ Mode 4: charging using an off-board charger and high level communication (i.e.

Powerline or CAN). �

2.3.3 PUC - Use Cases

Communication and charging between EV and charging station, used for smart charging

based on external control signals. �



2.4 IEC 61850-90-8

2.4.1 Definition

The IEC 61850-90-8 document is not a protocol in itself, more specifically, it is a technical

report which describes an object model for electric mobility. The main commitment of

IEC 61850-90-8 is to model E-mobility into IEC61850-7-420 ed. 2, for the integration with

other DER types like PV, wind, etc. for a high level of safety and interoperability. This will

be withdrawn by IEC when this process is finalized. The standard models EVs as a

specific form of DER according to the paradigms defined in IEC 61850. The idea is to

create a “logical node” model for EV. In this way IEC 61850-90-8 can be used as a

protocol: the report itself only describes the object model, but since it defines an object

model "in the IEC 61850 way", the properties of the data in this model can be "read" and

"set" using the standard messaging protocols for IEC 61850 (i.e. the MMS protocol).


The model is available as an IEC technical report, however, no existing real life charge

point implementation based on the protocol is known. The messages which are sent

using 61850 via the MMS protocol can be certified in general, so this also applies to

61850-90-8.


The supported use cases in IEC 61850-90-8 are:

§ Control a charging station for AC charging

§ Control a charging station for DC charging (high power charging)

§ Optimized charging with scheduling from the secondary actor / at EV

§ Managing the grid by optimizing power

§ Basic operations of a charging station

2.5 OCPI

2.5.1 Definition

The Open Charge Point Interface protocol is designed to facilitate roaming between

CPOs and EMSPs and to facilitate exchange of data like billing records, (live) charge



station information and pricing information. The OCPI protocol originates from the Dutch

EV market. Starting in 2009, a number of CPOs and EMSPs, collaborating under the

name eViolin together with ElaadNL, created a first version of a protocol for exchanging

information concerning charge points. Eventually in 2014 this resulted in the

development of OCPI. Version 2.1 was published in 2016.


OCPI is a strict protocol, which makes the interoperability high as it does not only

describe the protocol messages in much detail, but also the transport layer including

error codes etc. are described. OCPI can be used both in a peer 2 peer environment and

via central roaming hubs. �


The following high-level use cases are supported by OCPI:

§ Authorizing charging sessions �

§ Billing �

§ Providing charge point information21 �

§ Reservation �

§ Roaming �

§ Handle registrations �

In more detail, OCPI includes: �

§ Providing both session information as well as location information. �

§ Sending remote commands among which reservation commands. �

§ Providing Charge Detail Records for billing purposes �

§ Providing tariff information �

§ Authorizing charging sessions by exchanging tokens �



2.6 OpenADR

2.6.1 Definition

The Open Automated Demand Response standard is a (dynamic) Demand Response

protocol, developed by the United States (U.S.) Department of Energy’s Lawrence

Berkeley National Laboratory (LBNL) since 2002, formally published, as a standard by

the international standards development organization, the Organization for the

Advancement of Structured Information Standards (OASIS) Energy Interoperation

Technical Committee and maintained by the OpenADR Alliance. The OpenADR Alliance

(US-based) has members from all over the world, including grid companies, research

institutes and commercial component and infrastructure companies.


The protocol is relatively generic, due to the nature of DR programs, which means that it

can be used in a wide range of areas. Since the DR program message content is an

outcome of a specific implementation, this genericity makes it impossible to describe the

exact signal content and behavior for interoperability with every program. To limit the

variability of the implementation scenarios, the OpenADR Alliance has published A “DR

Program Guide” that sets out to harmonize the programs and add additional certification

options.

2.6.3 PUC – Use cases

The high-level use cases as listed in paragraph 4.1.4 that are supported by this protocol

are:

§ Handle registrations (registering a virtual end node at a virtual top node15) �

§ Manage grid �

§ Smart charging �

More specifically, OpenADR can be used for

§ Sending price and load control signal, which can be used for decreasing /

increasing power consumption of individual devices, which is a form of managing

a (smart) grid. �



§ Sending reports, in the EV context this can be e.g. standardized metering data

from a charging station (for example for monitoring and validating performance),

charge levels (in case of V2G), use times for forecasts etc. �

2.7 OCHP

2.7.1 Definition

The Open Clearing House Protocol (OCHP) is a protocol which is meant for exchanging

authorization data, charging transaction and charge point information data for roaming.

The protocol consists of 2 parts:

§ A part that is specifically for communication between market parties and an EV

clearing house.

§ A part that is for peer to peer communication between market parties, this is called

OCHPdirect.

The protocol is currently used with the e-clearing.net clearing house platform, which is

operated by smartlab Innovationsgesellschaft mbH and owned by both smartlab and

ElaadNL on an equal shares basis (non-profit). The version under consideration is 1.4.


The OHCP is a strict protocol, it does not only describe messages, but also the related

behavior of the CPO’s and the clearing house, as the more elaborate use cases are

explained in more detail. This “strictness” makes the protocol highly interoperable: a

correctly implemented system using OCHP and a correctly implemented clearing house

will usually integrate without many problems (if any).


The high-level use cases as listed in paragraph which are supported by OCHP are all

aimed at roaming:

§ Authorizing charging sessions �

§ Billing �

§ Providing charge point information �

§ Reservation �



§ Roaming �

§ Smart Charging (only in OCHPdirect, in a basic / lean form) �

In more detail, it also includes: �

§ Remote Control of Charge Point (only in OCHPdirect). This includes setting limits,

but this is not targeted at dynamic Smart Charging (yet). �

§ Providing tariff information �

§ Providing Charge Detail Records for billing �

§ Providing charging session information (only in OCHPdirect) �

2.8 OSCP

2.8.1 Definition

The Open Smart Charging Protocol communicates forecasts of the available capacity of

the electricity grid to other systems. This protocol has first been created by Dutch DSO

Enexis and EMSP14 / CPO GreenFlux but has been transferred for further development

to the Open Charge Alliance.

The protocol is based on a budgetary system where client systems can indicate their

needs to a central system, which guards against overuse of the grid by handing out

budgets per cable. If a system requires more it can request more, if it requires less it can

hand back part of its budget, to be available for other systems.


OSCP has no direct relationship with charging stations, as the protocol is by design more

generic. It can, in principle, be used for allocation of capacity in general (energy,

bandwidth, euro’s etc.) from a higher level system to a lower level system, however, the

naming is quite DSO specific.


The high-level use cases supported by OSCP are:

§ Smart charging (capacity based) �

§ Manage grid �In more detail, it includes: �



§ Handing out capacity budgets �

§ Managing grid capacity using these budgets �

§ Smart charging by communicating capacity forecasts �



3 Flexibility Cloud Software Architecture

This section describes the IT architecture for the Flexibility Cloud Software (FCS). It is a

system based on a microservice architecture pattern and the services and the platform

itself runs on Microsoft Azure. Microsoft Azure is the cloud compute platform offered by

Microsoft for building, deploying and managing applications and services through a

global network of managed datacentres. There is no need for any physical servers to

operate the system.

The architecture uses the eSmart Systems platform and the architecture developed in

the EMPOWER project as a starting point. Changes in the architecture might be needed

further into the project since the use cases and concept design are not completely ready

at the point of this document being delivered.

3.1 Starting point of the architecture

In the start of the INVADE project it was decided and agreed on that the architecture of

the EMPOWER project is the starting point of the architecture that will be used in

INVADE. The EMPOWER software architecture can be seen in Figure 14.

Figure 14: The EMPOWER software architecture.

The reason for this is that some of the functionality that is needed for the INVADE project

is available from the Horizon 2020 EMPOWER project. For instance, control of flexibility,

contract handling and calculations of time series, which will also be needed for the FCS.



This is then a great starting point to build upon and will save time. Being able to reuse

what has already been made in the EMPOWER project will also be in value of itself.

3.2 Functional specification and architecture

The chosen technology, design and architecture builds upon the EMPOWER project and

the eSmart Systems platform and is proven to be a solid solution built upon state of the

art technology and patterns from. Powered by Microsoft Azure, the FCS architecture is

highly scalable and will be ready to handle scenarios with large amount of traffic and

simultaneous computing and users.

The architecture will build upon this and adopt it into a more microservice oriented

architecture. By using a micro service architecture, the system will be flexible when it

comes to adding new features when needed. This helps to make the system even more

robust and scalable. It also makes the system highly maintainable since changes, since

Continuous Integration and Continuous Delivery is possible.

Figure 15: The Flexibility Cloud Software architecture



Figure 15 is an overview of the planned architecture to be implemented for the FCS. In

Annex 8, the architecture and features to be used in the FCS are described in detail.

Adaptions and improvements may be required further into the project as technology

always is in change.



4 SGAM architecture

The general architecture is defined based on the SGAM (Smart Grid Architecture Model)

methodology. The SGAM framework has been developed by the Joint Working Group

on standards for smart grids from CEN/CENELEC/ETSI in response to the

standardization mandate M/490 to support European Smart Grid deployment. Its

methodology aims to present smart grid use cases by a holistic architecture definition of

an overall Smart Grid infrastructure.

The SGAM framework has a three dimensional model with interoperability layers, smart

grid zones and domains, which are used to define the architecture design of smart grid

use cases (as depicted in Figure 16). The zones define the hierarchical levels of power

system management, the domains cover the complete electrical energy conversion

chain, and the interoperability layers represent the interrelations between the different

elements of the system, enabling the interoperability of this system.

Figure 16: SGAM model [9].

The different layers are specified as follows:

A. Component layer: it represents the physical distribution of all participating

components in the smart grid system: actors, applications, power system

equipment, protection and control devices, network infrastructure, etc.



B. Communication layer: it describes the communication protocols and

mechanisms for exchange of information. This layer is important to guarantee the

interoperability.

C. Information layer: it represents the data used and exchanged between

functions, services and components: power quality data, power flow, protection,

data from DERs, customers and meter data, etc.

D. Function layer: it contains the definition of the functions and services and their

relationships from an architectural point of view. It describes how the function or

service are performed independently from actors, physical implementations,

systems or components.

E. Business layer: this layer represents the business view of the smart grid. It can

be used to represent the market, regulatory and economic structures as well as

policies, business models, products and services of market participants.

In the following sections, function, component, information and communication layers of

the generic model are described. These layers have been designed following a top-down

approach. In addition, they will be further detailed when applied to specific pilot

environments in deliverable D4.2. Business layer will be described in deliverable D4.3.

Component layer

The SGAM component layer specifies the physical distribution of all components in the

described system. It includes physical devices, applications, actors and power system

equipment. Table 8 shows the symbols used in the component layer to represent the

information flow and components.

Table 8: Generic symbol description of the component layer.

Symbol Name Description

Component It represents any component of the layer. It can be a software application, an operator interface, or a field component.

Information flow

It represents a link between two or more components. It also notes the presence of an information exchange between the selected components.

Information flow (with another system)

It represents a link between a component and a different system than the represented in the SGAM diagram. It is used to represent interactions between systems.

In Table 9 there is a description of the components that will be used to define the

component layer in the INVADE project.



Table 9: Description of components present in the INVADE component layer.

Name Description

Aggregation function of the

flexibility operator

It manages all transactions and workflows necessary to aggregate and implement flexibility services. It includes energy scheduling, settlement, billing and accounting applications, and it takes care of the actions related to the DSO/BRP-FO interactions. It is also equipped with prediction and big data analytics.

Balance scheduling (BS)

Application that plans the energy procurement of a balance responsible energy retailer to satisfy the energy demands of their customers.

Customer energy

management system (CEM)

Energy management system for energy customers to optimize the utilization of energy according to supply contracts or other economic targets.

Charge point operator (CPO)

It is responsible for supplying, installing, maintaining and repairing the charging points.

Distributed energy resource

(DER)

A small unit that generates or consumes energy. It includes generation and storage connected to the distribution grid.

DER controller Controller of a DER that allows the adjustment of its active or reactive power output according to a received set point.

Distribution management system (DMS)

Application server of a Distribution Operator which hosts applications to monitor and control a distribution grid from a centralized location, typically the control centre. A DMS typically has interfaces to other systems, like a GIS or an OMS.

Electric Vehicle Supply

Equipment (EVSE)

Single or multiple power outlets specially designed to charge the battery of cars. Typically including also facilities meter the energy consumption and to authenticate the owner of the car to be charged for settlement reasons.

Energy Management

Gateway (EMG)

Gateway used to interface the private area with remote service providers and also with the metering system.

Electric vehicle (EV)

A vehicle with an electric drive (as only drive or in combination with a fuel engine) and a battery which can be charged at a charging station.

Front End Processor (FEP)

System component in charge of interfacing widely spread remote sub/systems or component usually communicating over WAN, to a central database.

Meter reader (MR)

Device which measures the energy consumption within predefined cycles from the smart meter. The metered energy consumption is used to determine the energy bill. It is not used by the DSO.

Operation function of the

flexibility operator

It is in charge of managing the orders and schedules that the flexibility plan defines. It receives requests from the aggregator and allocates flexibility at device level.

Operation meter (OM)

Device which monitors the energy consumption of a specific device for operational and control reasons. It is placed beyond the main meter, The meter values are not used for commercial purposes.

Smart device It includes loads and customer appliances that provide an interface to influence their consumption behaviour. It can also include generation, storage and electric vehicles placed at customer premises.

Smart device controller (DC)

Control the energy consumption of a smart device according to received set point without jeopardizing the desired process of the device.

Smart meter (SM)

Electronic device that measures and records consumption of electric energy in intervals of an hour or less and communicates that information at least daily back to the utility for monitoring and billing. It measures aggregated consumptions of customers.



These are generic minimum components that need to be further specified when defining

each pilot site. For example, the OM and SDC can be part of the same physical device

or not, depending on the specific device used. In addition, depending on the use case

and pilot’s characteristics, not all components are going to be used in each pilot, and

more devices can be added to complement the ones defined in Table 9.

The components needed in the architecture of INVADE, above described, and their

interactions are represented in the SGAM component layer in Figure 17. This component

layer is used as a baseline to define the other SGAM layers.

Figure 17: SGAM component layer.

SDCOM

CEM

SM

MR

EMG

SMARTDEVICE

FEP

SM

MR

EV

CPO

FEP

AGGREGATIONFUNCTION

OPERATIONFUNCTION

DMS/SCADA(DSO) BS(BRP)Market

Enterprise

Operation

Station

Field

Process

Zones

DomainsDistribution DER Customerpremises

FLEXIBILITYOPERATOR

SM

MR

DERCONTROLLER

DER

FEP

EVSESDCOM



4.1 Function layer

Function layer exposes the agents’ responsibilities and actions needed to operate the

IIP. The FO has been split in aggregation and operation functions. Aggregation functions

take care of the actions related to the DSO/BRP-FO interactions and operation functions

receive requests from the aggregator and allocates flexibility at device level.

There are three groups of functions depending on their moment to be executed and they

are day-, hour- and quarter-ahead of the operation time. The INVADE settlement

program time units (PTU) are quarters (15 minutes), therefore the timeline is divided in

periods of 15 minutes. Additionally, data and functions use smaller PTU depending on

each function.

All functions and interactions are considered and designed to define the control signals

that the FO sends to every flexible device (i).

Functions description (highlighted in green in Figure 18):

§ Aggregated forecast (AF): Estimates available flexibility and its price at aggregated

level based on time series, weather forecast and others. This information is

required to define the baseline. In further developments, the baseline should be

established by a regulated and independent third party.

o Flexibility request or capacity limit: Defines the BRP or DSO flexibility

demand and it is based on the explanation from section 1.8.1.

§ Aggregated flexibility plan (AFP): Schedules flexible assets to attend the flexibility

request based on the previous AF at aggregated level at different moments: daily,

hourly and quarter. This plan is used to reply the flexibility request favourably or

not.

o Request acceptance: Contains the price for activating the requested

flexibility, the flexibility amount in case of partial fulfilment.

o Detailed flexibility plan (DFP): Based on the AFP, it schedules flexible

assets at device level at different moments (daily, hourly and quarter).

During daily and hourly operations the result is used to inform the end

user that its flexible resource could be activated. In contrast, during

quarter operations, DFP defines control signals to be sent.

§ User acceptance: Allows flexible device owners to reject the flexibility request

using the IIP customer interface channels.



§

Figure 18: Functions timeline.

BRP/DSOFlexible

devicei

Aggregation

functions

Operation

functions

FlexibilityOperator

Flexibilityrequest/

Capacitylimit

(CM,DAPO)

Agregated

Forecast(AF)

AggregatedDaily

FlexibilityPlan(FP)

ADailyFPRequestacceptance

(price;quantity)

Detailed

DailyFP

DDailyFPi

User

acceptancei

Time-line

Day-aheadoperations

Hour-aheadoperations

Flexibilityrequest/

Capacitylimit

(CM,IPO)AHourlyFP

AHourlyFP

DHourlyFP

DHourlyFPi,t

DDailyFP*

Cancelationi

User

acceptancei

Quarter-aheadoperations

Flexibilityrequest/

Capacitylimit

(CM,SBPO)

AQuarterFP

AQuarterFPRequestacceptance

(price;quantity)

DQuarterFP

Controlsignal

DHourlyFP*

Cancelationi

DDailyFP*

Requestacceptance

(price;quantity)

DDailyFP*

INTEGRATEDINVADEPLATFORM

Settlement

Meteredvaluesi

Flexibility

calculationFlexibilityactivatedi

Settlement

Deliverynote

Acceptance Billingi

(Payments;Penalizations)

Baseline

AF

Baseline

AF

Baseline

§CM: Congestion management service§DAPO: Day-ahead portfolio optimization service§IPO: Intraday portfolio optimization service§SBPO: Self-balancing portfolio optimization service



§ DFP* and HFP*: Re-calculates the flexibility scheduling after receiving all rejection

messages.

§ Flexibility calculation: Defines the flexibility activated based on the baseline and

the metered values of each flexible resource.

§ Settlement: Defines the total amount of flexibility activated and requested. It

produces the delivery note to be sent to BRP/DSO.

Forecasts (AF) and flexibility plans (AFP and DFP) are generated for periods of 15

minutes.

Where required, contracts, communication and money flows can be directed through an

independent third party. In the case of flexibility being valued through supply contracts,

this does not apply [2].

In Figure 19, these functions are represented into a SGAM function layer, which identifies

the logical entities that performs a dedicated function.



Figure 19: SGAM function layer.

4.2 Information layer

The information layer of the SGAM architecture methodology is the layer where the

naming and parameters of the data to be exchanged are specified. In Figure 20, the

generic information architecture layer for the INVADE project concept is shown. It details

the kind of information to be exchanged between the components of the system. It will

be further developed and detailed when applied to specific environments in deliverable

D4.2, as they can be slightly different in each pilot implementation.

SDCOM

CEM

SM

MR

EMG

SMARTDEVICE

FEP

SM

MR

EV

CPO

FEP

AGGREGATIONFUNCTION

OPERATIONFUNCTION


Enterprise

Operation

Station

Field

Process

Zones


FLEXIBILITYOPERATOR

SM

MR

DERCONTROLLER

DER

FEP

EVSESDCOM

Aggregatedforecast

ADFP

DDFP

AHFP

DHFP

AQFP

DQFP

Measurement

Flexibilitycalculation

Settlement Settlement

Controlexecution

Controlexecution

Controlmanagement

Controlexecution

Measurement Measurement

Dataacquis ition

Dataacquis ition

Dataacquis ition

Dataacquis ition

Dataacquis ition

Dataacquis ition

Sendcontrolsignals

Sendcontrolsignals

Sendcontrolsignals

Controlmanagement



Figure 20: SGAM information layer.

4.3 Communication layer

The communication layer of the SGAM architecture methodology is the layer where the

communication protocols are specified. In Figure 21, the generic communication

architecture layer for the INVADE project concept is described.

SDCOM

CEM

SM

MR

EMG

SMARTDEVICE

FEP

SM

MR

EV

CPO

FEP

AGGREGATIONFUNCTION

OPERATIONFUNCTION


Enterprise

Operation

Station

Field

Process

Zones


FLEXIBILITYOPERATOR

SM

MR

DERCONTROLLER

DER

FEP

EVSESDCOM

Meteringdata

Meteringdata

Meteringdata

Meteringdata

Meteringdata

Controlsignals

Controlsignals

Controlsignals

Meteringdata/Co

ntrol

signals/D

DFP,DHFP,D

QFP

Meteringdata/

ADFP,A

HFP,AQFP

Meteringdata/Co

ntrol

signals/D

DFP,DHFP,D

QFP

Meteringdata/

Controlsignals/

DDFP

,DHFP,D

QFP

Baseline/F

l.Request&

acceptance/

Settlem

ent

Baseline/F

l.Request&

acceptance/

Settlem

ent



Figure 21: SGAM communication layer.

There are some interfaces where the communication protocol still needs to be defined

(TBD). However, the particular solution for each pilot implementation will be detailed in

deliverable D4.2 and in Work Package 7 - Communications platform.

Device controllers and their metered values are usually connected through a gateway

directly to the internet using a subscriber access network. The local communication

interfaces at household level between the gateways and controllers may differ depending

on the specific components to be used in each implementation.

In centralized storage or other DER installations, the communications depend on the

final solution adopted during the project execution and the communication standards

used for each pilot owner in their own installations.

SDCOM

CEM

SM

MR

EMG

SMARTDEVICE

FEP

SM

MR

EV

CPO

FEP

AGGREGATIONFUNCTION

OPERATIONFUNCTION


Enterprise

Operation

Station

Field

Process

Zones

DomainsDistribution DERCustomerpremises

FLEXIBILITYOPERATOR

SM

MR

DERCONTROLLER

DER

FEP

EVSESDCOM

IEC/ISO15118

IEC61

851-1

IEC61

850-90

-8OCP

POCH

PDirect

OCP

I,OSCP

TBD

TBD

TBD

TBD

Web

services

Web

services

TBD

TBD



Upstream communications from the gateways to the INVADE platform will be

implemented using web services or a similar integration service.

Communications regarding e-mobility chain are specified in section 2. The identified

protocols will be further studied to see if any addition or improvement needs to be done

to allow flexibility management.



5 Conclusions

This document has proposed a general description and architecture of the INVADE

system, which is the basis for the following development process.

At first, the concept design is explained, with special references to the role of the flexibility

operator and how the flexibility can be used and provided. The identified flexibility

services are classified in function of the flexibility customer, namely, DSO, BRP, TSO

and Prosumer; although TSO is out of the scope of the project. Then, these services and

flexibility sources are evaluated to identify which can provide more added value to each

use case.

Thereafter, deliverable sections describe the concepts and characteristics of existing

communication standards and protocols on smart grids, with special focus on standards

in the e-mobility chain and the smart charging, and the IT architecture for the Flexibility

Cloud Software, which uses the eSmart Systems platform and the architecture

developed in the EMPOWER project as a starting point.

This document finishes with a description of the architecture of the INVADE system using

the SGAM methodology. At first, it described generic components to be used in the

general INVADE system in the component layer, without limitations on the available

infrastructure at the pilot sites. Then, information, communication and function layers

have been detailed.

The concept design described in this document serves as input to WP5 (Flexibility

management system), WP7 (Communication platform) and WP8 (Integrated INVADE

platform), as these WPs are in charge of the implementation of the INVADE system.

Then, the concept design and architecture will be adapted to the particularities of the

different pilot sites with the involvement of WP10 (Pilots) and pilot sites owners.



6 References

[1] CENELEC-CEN-ETSI Joint Working Group on Standards for Smart Grids, SG-CG

/ M490 / L Flexibility Management - Flexibility Management Overview of the main

concepts of flexibility management. Smart Grid Coordination Group, 2014

[Online]. Available:

ftp://ftp.cencenelec.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/SGC

G_Methodology_FlexibilityManagement.pdf

[2] M. Sánchez-Jiménez, K. Stamatis, M. Kollau, M. Stantcheva, E. Busechian, P.

Hermans, D. Guzeleva, G. E. Abrandt, W. Friedl, P. Mandatova, and J.

Stromback, Regulatory Recommendations for the Deployment of Flexibility. Smart

Grid Task Force - Expert Group 3: Regulatory Recommendations for Smart Grids

Deployment, 2015 [Online]. Available:

http://ec.europa.eu/energy/sites/ener/files/documents/EG3 Final - January

2015.pdf

[3] Universal Smart Energy Framework (USEF), “USEF: The framework explained,”

2015 [Online]. Available: www.usef.energy/download-the-framework/

[4] Universal Smart Energy Framework (USEF), “USEF: The framework

specifications,” 2015 [Online]. Available: www.usef.energy/download-the-

framework

[5] B. A. Bremdal, “D3.1 Stakeholders Engagement Plan,” no. 731148. INVADE

project, 2017.

[6] Flo Bødal. Espen, P. Crespo del Granado, H. Farahmand, M. Korpås, P. Olivella,

I. Munné, and P. Lloret, “D5.1 Challenges in distribution grid with high penetration

of renewables.” INVADE project, 2017.

[7] Bundesverband der Energie und Wasserwirtschaft (BDEW), Elements of a

dynamically developing internal market for electricity and gas. 2014 [Online].

Available: www.bdew.de/internet.nsf/id/9PGMAH-20140924-o-discussion-paper-

elements-of-a-dynamically-developing-internal-market-for-

electri/$file/140919_BDEW_Discussion_Paper_IEM_final_ohne_AP.pdf

[8] K. Kok and S. Widergren, “A Society of Devices: Integrating Intelligent Distributed

Resources with Transactive Energy,” IEEE Power Energy Mag., vol. 14, no. 3, pp.

34–45, 2016.



[9] CENELEC-CEN-ETSI Joint Working Group on Standards for Smart Grids, “Smart

Grid Reference Architecture,” 2012 [Online]. Available:

ftp://ftp.cen.eu/EN/EuropeanStandardization/HotTopics/SmartGrids/Security.pdf



7 Annex 1 - Flexibility services in detail

7.1 Flexibility services for DSO

§ Congestion management: Congestion management refers to avoiding the

thermal overload of system components by reducing peak loads where failure due

to overloading may occur. The conventional solution is grid reinforcement (e.g.,

cables, transformers). The alternative (load flexibility) may defer or even avoid the

necessity of grid investments [3].

§ Voltage / Reactive power control: Voltage control is typically requested when

solar PV systems generate significant amounts of electricity. This will “push up” the

voltage level in the grid. Using load flexibility by increasing the load or decreasing

generation is an option to avoid exceeding the voltage limits. This mechanism can

reduce the need for grid investments (such as automatic tap changers) or prevent

generation curtailment [3] .

§ Controlled islanding: it aims to prevent supply interruption in a given grid section

when a fault occurs in a section of the grid feeding into it [3].

7.2 Flexibility services for BRP

A BRP has different options for using flexibility at different points in time. It is more difficult

to decrease or increase outputs for certain types of generation units such as wind or

solar as for conventional types of generation. Flexibility from other generation/supply

units or demand is often necessary for BRP portfolio optimisation. Trading energy is also

an option to optimize the portfolio for a BRP [2].

§ Day-ahead portfolio optimization aims to shift loads from a high-price time

interval to a low-price time interval before the day-ahead market closure. It enables

the BRP to reduce its overall electricity purchase costs [3]. This service is used by

BRP to prepare day-ahead market bids.

§ Intraday portfolio optimization closely resembles day-ahead optimization, but

the time frame is constrained after closing of the day-ahead market. This enables

intraday trading and load flexibility can be used to create value on this market,

equivalent to the day-ahead market [3]. This service is used by BRP to prepare

intraday market bids.



§ Self-balancing portfolio optimization is the reduction of imbalance by the BRP

within its portfolio to avoid imbalance charges. The BRP does not actively bid on

the imbalance market using its load flexibility, but uses it within its own portfolio.

7.3 Flexibility services for Prosumers

§ ToU optimization is based on load shifting from high-price intervals to low-price

intervals or even complete load shedding during periods with high prices. This

optimization requires that tariff schedules are known in advance (e.g., day-ahead)

and will lower the Prosumer’s energy bill [3].

§ kWmax control is based on reducing the maximum load (peak shaving) that the

Prosumer consumes within a predefined duration (e.g., month, year), either

through load shifting or shedding. Current tariff schemes, especially for C&I

customers, often include a tariff component that is based on the Prosumer’s

maximum load (kWmax). By reducing this maximum load, the Prosumer can save

on tariff costs. For the DSO, this kWmax component is a rudimentary form of

demand-side management [3].

§ Self-balancing is typical for Prosumers who also generate electricity (for example,

through solar PV or CHP systems). Value is created through the difference in the

prices of buying, generating, and selling electricity (including taxation if applicable).

Note that solar PV self-balancing is not meaningful where national regulations

allow for administrative balancing of net load and net generation [3].

§ Controlled islanding during grid outages. Whether this is of sufficient value to the

Prosumer depends mainly on the grid’s reliability and the potential damage from a

grid outage, which in turn depends on the type of Prosumer (e.g., residential home,

office building, hospital…). Islanding may require additional investments, such as

storage and synchronization systems. [3]



8 Annex 2 – Azure components and microservices in

the FCS

8.1 Azure components

8.1.1 Azure SQL Databases

Azure SQL Database provides all key features of a relational database management

system, including atomic transactions, concurrent data access by multiple users with

data integrity, ANSI SQL queries, and a familiar programming model. Like SQL Server,

SQL Database can be accessed using Entity Framework, ADO.NET, JDBC, and other

familiar data access technologies. It also supports most of the T-SQL language, along

with SQL Server tools such as SQL Server Management Studio. The Azure SQL

Database takes care of the administrative grunt work, such as managing the hardware

infrastructure and automatically keeping the database and operating system software up

to date. SQL Database also provides high availability, automatic backups, point-in-time

restore capabilities, and can replicate copies across geographical regions.

Azure SQL Databases is used within the FCS to store structural data as in customer

information data, meter info data, etc.

8.1.2 Azure Table Storage

Azure Table Storage let an application store properties of various types, such as strings,

integers, and dates. An application can then retrieve a group of properties by providing

a unique key for that group. While complex operations like joins are not supported, tables

offer fast access to typed data. They are also very scalable, with a single table able to

hold as much as a terabyte of data. And matching their simplicity, tables are usually less

expensive to use than SQL Database's relational storage.

Azure Table Storage is mainly used within the FCS to store logs.

8.1.3 Azure Cosmos DB

Cosmos DB is a true schema-free NoSQL document database service designed for

mobile and web applications. Cosmos DB offers global distribution with scaling and the

possibility to replicate data where the users are located. Cosmos DB delivers fast reads

and writes, schema flexibility, and the ability to easily scale a database up and down on



demand. It does not assume or require any schema for the documents it indexes. By

default, it automatically indexes all the documents in the database and does not expect

or require any schema or creation of secondary indices. Cosmos DB enables complex

ad hoc queries using a SQL language, supports well defined consistency levels, and

offers JavaScript language integrated, multi-document transaction processing using the

familiar programming model of stored procedures, triggers, and UDFs.

The FCS utilize Azure Cosmos DB to create the link between components and time

series, to save demand response plans and to save information about contracts. During

development, even more areas might be able to be stored in Cosmos DB.

8.1.4 Azure Blob Storage

Azure Blob Storage is designed to store unstructured binary data. Like Tables, Blobs

provides inexpensive storage, and a single blob can be as large as 1TB (one terabyte).

Azure applications can also use Azure drives, which let blobs provide persistent storage

for a Windows file system mounted in an Azure instance. The application sees ordinary

Windows files, but the contents are actually stored in a blob.

Azure Blob Storage is mainly used within the FCS to store time series.

8.1.5 Azure Cache

Accessing data stored in any of Azure's data management services (SQL Database,

Tables, or Blobs) is quite fast. Yet accessing data stored in memory is even faster.

Because of this, keeping an in-memory copy of frequently accessed data can improve

application performance.

Microsoft Azure Cache supports this and is available in the following offerings:

§ Azure Redis Cache

§ Managed Cache Service

§ In-Role Cache

Azure's Redis Cache is widely used within the FCS for quick access to all persistent

data.

8.1.6 Azure Event Hub

Azure Event Hub is a highly scalable data ingress service that can ingest millions of

events per second so that you can process and analyse the massive amounts of data



produced by connected devices and applications. Event Hubs acts as the "front door" for

an event pipeline, and once data is collected into an event hub, it can be transformed

and stored using any real-time analytics provider or batching/storage adapters. Event

Hubs decouples the production of a stream of events from the consumption of those

events, so that event consumers can access the events on their own schedule.

Event Hubs is an event processing service that provides event and telemetry ingress to

the cloud at massive scale, with low latency and high reliability. This service is especially

useful for:

§ Application instrumentation

§ User experience or workflow processing

§ Internet of Things (IoT) scenarios

The FCS utilizes Azure Event Hub for high-frequency messages, such as real-time data.

8.1.7 Azure Stream Analytics

Azure Stream Analytics is a fully managed, cost effective real-time event processing

engine. Stream Analytics makes it easy to set up real-time analytic computations on data

streaming from devices, sensors, web sites, social media, applications, infrastructure

systems, and more. A typical Stream Analytics job can be authored by specifying the

input source of the streaming data, the output sink for the results of the job, and a data

transformation expressed in a SQL-like language. One can then monitor and adjust the

scale/speed of the job to scale from a few kilobytes to a gigabyte or more of events

processed per second.

Currently Azure Stream Analytics is used in the FCS to process high frequency

messages, such as real-time data coming into Azure Event Hub, and store time-series

into Azure Blob Storage.

8.1.8 Azure Service Bus

Azure Service Bus messaging is an information delivery service. The purpose of this

service is to make communication easier. When two or more parties want to exchange

information, they need a communication mechanism. Service Bus messaging is a

brokered, or third-party communication mechanism. This is similar to a postal service in

the physical world. Postal services make it very easy to send different kinds of letters

and packages with a variety of delivery guarantees, anywhere in the world.



Similar to the postal service delivering letters, Azure Service Bus messaging is about

information delivery from both the sender and the recipient. The messaging service

ensures that the information is delivered even if the two parties are never both online at

the same time, or if they are not available at the exact same instant. In this way,

messaging is similar to sending a letter, while non-brokered communication is similar to

placing a phone call (or how a phone call used to be - before call waiting and caller ID,

which are much more like brokered messaging).

The message sender can also require a variety of delivery characteristics including

transactions, duplicate detection, time based expiration, and batching. These patterns

have postal analogies as well: repeat delivery, required signature, address change, or

recall.

Service Bus supports two distinct messaging patterns: relayed messaging and brokered

messaging.

Relayed messaging

The relay component of Service Bus is a centralized (but highly load balanced) service

that supports a variety of different transport protocols and Web services standards. This

includes SOAP, WS-*, and even REST. The relay service provides a variety of different

relay connectivity options and can help negotiate direct peer-to-peer connections when

it is possible. Service Bus is optimized for .NET developers who use the Windows

Communication Foundation (WCF), both with regard to performance and usability, and

provides full access to its relay service through SOAP and REST interfaces. This makes

it possible for any SOAP or REST programming environment to integrate with Service

Bus.

Brokered messaging

In contrast to the relayed messaging scheme, brokered messaging can be thought of as

asynchronous, or "temporally decoupled." Producers (senders) and consumers

(receivers) do not have to be online at the same time. The messaging infrastructure

reliably stores messages in a "broker" (such as a queue) until the consuming party is

ready to receive them. This allows the components of the distributed application to be

disconnected, either voluntarily; for example, for maintenance, or due to a component

crash, without affecting the entire system. Furthermore, the receiving application may

only have to come online during certain times of the day, such as an inventory

management system that only is required to run at the end of the business day.



The core components of the Service Bus brokered messaging infrastructure are queues,

topics, and subscriptions.

Queues

Queues offer First In, First Out (FIFO) message delivery to one or more competing

consumers. That is, messages are typically expected to be received and processed by

the receivers in the order in which they were added to the queue, and each message is

received and processed by only one message consumer. A key benefit of using queues

is to achieve "temporal decoupling" of application components. In other words, the

producers (senders) and consumers (receivers) do not have to be sending and receiving

messages at the same time, because messages are stored durably in the queue.

Furthermore, the producer does not have to wait for a reply from the consumer in order

to continue to process and send messages.

Service Bus Queues are mainly used within the FCS for integrations of: meter values,

structural data (customer information, meter information, etc.).

Topics and subscriptions

In contrast to queues, in which each message is processed by a single consumer, topics

and subscriptions provide a one-to-many form of communication, in a publish/subscribe

pattern. Useful for scaling to very large numbers of recipients, each published message

is made available to each subscription registered with the topic. Messages are sent to a

topic and delivered to one or more associated subscriptions, depending on filter rules

that can be set on a per-subscription basis. The subscriptions can use additional filters

to restrict the messages that they want to receive. Messages are sent to a topic in the

same way they are sent to a queue, but messages are not received from the topic

directly. Instead, they are received from subscriptions. A topic subscription resembles a

virtual queue that receives copies of the messages that are sent to the topic. Messages

are received from a subscription identically to the way they are received from a queue.

Service Bus Topics are mainly used within the backend in the FCS for publishing

information to the clients.

8.1.9 Azure Machine Learning

Azure Machine learning involves a set of advanced techniques and algorithms designed

to adapt generic models to existing (historical) data which, when applied to new data,

can generate forecasts of future behaviours, outcomes, and trends. It is a powerful cloud-



based predictive analytics service that makes it possible to quickly create and deploy

predictive models as analytics solutions.

Azure Machine Learning not only provides tools to model predictive analytics, but also

provides a fully-managed service that we use to deploy our predictive models as ready

to consume web services. Azure Machine Learning provides tools for creating, testing,

operationalizing, and managing complete predictive analytics solutions in the cloud.

Azure Machine Learning is designed for applied machine learning, which means that in

minutes our models are live as fully managed web services that can connect to any data,

anywhere. As our needs change, we can easily update our solutions and put them back

into production, while still being able to revisit our previous results.

Azure Machine Learning will be used in the FCS whenever the system needs to generate

predictions.

8.1.10 Azure Scheduler

Some business processes only need to run at a certain time. Azure Scheduler gives the

ability to schedule when an application should run based on interval of time or a calendar.

It is reliable and will verify that a process runs even if there are network, machine, and

data centre failures.

The FCS can use the Azure Scheduler REST API to manage the workflow scheduling,

together with export/import of reports.

8.1.11 Azure Service Fabric

Azure Service Fabric is a distributed systems platform that makes it easy to package,

deploy, and manage scalable and reliable microservices. The FCS will use Azure Service

Fabric to host microservices and actors for handling contracts and for instance time

series.

8.1.12 Azure API Management

API Management helps to publish APIs to external, partner and internal developers to

handle data and communicate with services. The FCS will implement Azure API

Management for access control, rate limiting, event logging and response handling.



8.1.13 Azure Virtual Machines

The FCS uses Virtual Machines for the optimization process. This is run as a compute

server.

8.1.14 Azure Application Insights

Application Insights will be used in the FCS to monitor microservices, web API’s and

other components. Application Insights can detect performance issues and helps to

improve performance and usability in the software.

8.2 Microservice architecture in the flexibility cloud software

Several parts of the FCS follows a microservice architecture, where logic is placed in

different services. This makes the software easier to build and maintain in contrast to a

traditional monolithic application.

This section describes some of the microservices that are part of the FCS. Further

services and features may be added to the architecture later in the project when the

concept designs and pilots are described more in detail.

8.2.1 Time Series Service

The time series service is a microservice for storing and delivering time series data. Other

microservices can feed and retrieve time series to this service. An example of a time

series is the consumption of power when charging an EV and the production of solar

power from a PV.

Figure 22: Charge State Service feeding data to the Time Series Service.



Figure 23: The different components of the time series service.

8.2.2 Contract Service

The Contract Service is a service for handling all different kinds of contracts. For

example, a contract between the end user and the company delivering charging stations.

The Contract Services handles storage and calculations of the contract. The service

utilizes the Virtual Actor pattern where each contract is represented by an Actor that

processed data and calculations for the contract. In addition, data regarding the contract

is stored in Azure Cosmos DB. The service and the contract actors are run in Azure

Service Fabric.

Figure 24: The Contract Service.



To access information about the contracts, the contract service has a restless service

that other services can connect to, that works as a communication interface for the actors

and with the Azure Cosmos DB storage. The actors and the restless service is hosted in

Azure Service Fabric. Example of usage of this service is to store flexibility contracts,

energy contracts, grid contracts and service contracts.

Figure 25: Process flow of the Contract Service.

Other services will also access information from the Contract Service. An example is

when a Demand Response Plan is created. The plan then needs to access constraints

on for instance what devices the prosumer allows the flexibility operator to control.



Figure 26: Interaction with the Contract Service when creating a Demand Response Plan.

8.2.3 Graph Service

The Graph Service handles relations between different assets. For instance, the relations

between a smart meter and devices that consume or generate power.

Figure 27: Example of hierarchy between smart meter, PV panel and a water boiler. The scenario is taken from the implementation of the system in the EMPOWER project.



8.2.4 Weather Service

The weather service provides the flexibility cloud with weather forecasts.

Figure 28: Relation between the Weather Service and the Prediction Service.

An example use of the weather service is in the Prediction Service when machine

learning is predicting power consumption in a household, how much power electricity

floor heating will consume, and how much electricity the PV panel will generate.

8.2.5 Prediction Service

The prediction service exposes the different APIs that are created in Azure Machine

Learning for predicting consumption, production and available flexibility.

Figure 29: Example of models to be implemented in machine learning.



The figure above illustrates different models used to predict data for water heaters, floor

heating, heat pumps, EVs, main meters, PV panels and weather. New models can be

added if more prediction is required. For instance models for wind mills.

8.2.6 Solver Service / Optimization Service

The Solver Service connects to the state-of-the-art mathematical programming solver,

Gurobi, to optimize for instance demand response plans or smart charging profiles.

The Service consist of an Optimization Manager that implements the Gurobi Solver. The

Optimization API expose the methods available in the manager to solve mathematical

problems.

Figure 30: The different components of the Solver Service.

The Gurobi Optimizer is run on an Azure Virtual Machine as a compute server.



Figure 31: Process flow of the solver service.

8.2.7 EV Charging Service

The EV charging service to handle charge plans. With integration to Elwin Price API. For

the FCS, the service will be adopted to fin into the use cases for smart charging.



Figure 32: The EV Charging Service

Figure 33: Process flow for the EV charging service

This service is responsible for calculating the charge plan for EV's. The service holds

information regarding several states for a charge point. The charge point is represented

by a virtual actor that holds the state for the charge point.



After the charge plan / smart profile is created, it can be transferred by for instance using

OCPI to other platforms.

8.2.8 Price service

The price service imports market data as day ahead elspot and makes this data available

for other components in the FCS. The prices are saved as time series in the time series

service. This data is then used by the Contract Service to calculate economic figures.

Figure 34: Price Service.



Figure 35: Process flow of the Price Service.



8.2.9 Asset Service

The Asset Service is a service where one can store and search for different components.

Each asset is represented by a virtual actor that holds information and state regarding

the asset. An asset can be for example a PV panel, a smart meter, an electrical vehicle

or a water heater.

Figure 36: Relationships in the asset service.

The service is a collection of several microservices that serves different purposes. One

of the services offers the possibility to search for assets. Elastic search is used for this

to offer search with the possibility for filtering on multiple properties on the assets.

Docker containers and Azure Service Fabric are used for the hosting of the services and

the Elastic search instances.

8.2.10 Control of Flexibility

In several of the pilots, control of different flexibility sources is to be demonstrated. The

FCS will utilize automated processes to do calculations and to workflows can be created

for different use cases and the following example describes how the FCS can be used

to create a Demand Response Plan. A Demand Response Plan is used to turn devices

on / off in the grid. In this example, a DSO uses a web based interface to request

flexibility.

Optimization will be used to make better decisions on that appliances that should be

turned on / off.



Figure 37: The process flow of a Demand Response Plan

Smart system of renewable energy storage based on ... · 8.1 Azure components 68 8.1.1 Azure SQL...

Documents

Transcript of Smart system of renewable energy storage based on ... · 8.1 Azure components 68 8.1.1 Azure SQL...