Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 2 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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 3 of 85
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.2Technical Characteristics 41
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 4 of 85
2.2.3PUC - Use Cases / applications 41
2.3 IEC 61851-1 42
2.3.1Definition 42
2.3.2Technical Characteristics 42
2.3.3PUC - Use Cases 42
2.4 IEC 61850-90-8 43
2.4.1Definition 43
2.4.2Technical Characteristics 43
2.4.3PUC - Use Cases 43
2.5 OCPI 43
2.5.1Definition 43
2.5.2Technical Characteristics 44
2.5.3PUC - Use Cases 44
2.6 OpenADR 45
2.6.1Definition 45
2.6.2Technical Characteristics 45
2.6.3PUC – Use cases 45
2.7 OCHP 46
2.7.1Definition 46
2.7.2Technical Characteristics 46
2.7.3PUC - Use Cases 46
2.8 OSCP 47
2.8.1Definition 47
2.8.2Technical Characteristics 47
2.8.3PUC - Use Cases 47
3 Flexibility Cloud Software Architecture .............................................................. 49
3.1 Starting point of the architecture 49
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 5 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 6 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 7 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 8 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 9 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 10 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 11 of 85
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,
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 12 of 85
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].
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 13 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 14 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 15 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 16 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 17 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 18 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 19 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 20 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 21 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 22 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 23 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 24 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 25 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 26 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 27 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 28 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 29 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 30 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 31 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 32 of 85
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].
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 33 of 85
§ 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,
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 34 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 35 of 85
(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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 36 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 37 of 85
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]
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 38 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 39 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 40 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 41 of 85
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.
2.2.2 Technical Characteristics
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 �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 42 of 85
§ 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. �
2.3.2 Technical Characteristics
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. �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 43 of 85
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).
2.4.2 Technical Characteristics
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.
2.4.3 PUC - Use Cases
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 44 of 85
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.
2.5.2 Technical Characteristics
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. �
2.5.3 PUC - Use Cases
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 �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 45 of 85
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.
2.6.2 Technical Characteristics
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. �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 46 of 85
§ 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.
2.7.2 Technical Characteristics
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).
2.7.3 PUC - Use Cases
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 �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 47 of 85
§ 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.
2.8.2 Technical Characteristics
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.
2.8.3 PUC - Use Cases
The high-level use cases supported by OSCP are:
§ Smart charging (capacity based) �
§ Manage grid �In more detail, it includes: �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 48 of 85
§ Handing out capacity budgets �
§ Managing grid capacity using these budgets �
§ Smart charging by communicating capacity forecasts �
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 49 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 50 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 51 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 52 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 53 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 54 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 55 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 56 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 57 of 85
§
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 58 of 85
§ 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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 59 of 85
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
DMS/SCADA(DSO) BS(BRP)Market
Enterprise
Operation
Station
Field
Process
Zones
DomainsDistribution DER Customerpremises
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 60 of 85
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
DMS/SCADA(DSO) BS(BRP)Market
Enterprise
Operation
Station
Field
Process
Zones
DomainsDistribution DER Customerpremises
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 61 of 85
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
DMS/SCADA(DSO) BS(BRP)Market
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 62 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 63 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 64 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 65 of 85
[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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 66 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 67 of 85
§ 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]
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 68 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 69 of 85
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
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 70 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 71 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 72 of 85
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-
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 73 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 74 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 75 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 76 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 77 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 78 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 79 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 80 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 81 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 82 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 83 of 85
Figure 35: Process flow of the Price Service.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 84 of 85
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.
INVADE H2020 project – Grant agreement nº 731148
Deliverable D4.1 – Overall INVADE architecture Page 85 of 85
Figure 37: The process flow of a Demand Response Plan