deliverable 5.1 nrg-5 trials set-up

Research & Innovation Actions

5G PPP Research and Validation of critical technologies and systems: Enabling Smart Energy as a Service via 5G Mobile Network advances.

Project: H2020-ICT-07-2017

Enabling Smart Energy as a Service via 5G Mobile Network advances

Deliverable 5.1

NRG-5 Trials Set-up

Author(s): Francesco Bellesini, Costanza Mancinelli (EMOT), Luca Alfieri, Tommaso Bragatto (ASM), Dominique Barthel, Frederic Antonio (ENGIE), Antonello Corsi (ENG), José Maria Lalueza (VIS), Fabián González Suárez (HIS), Kostantinos Kalaboukas (SiLO).

Status -Version: V1.0

Delivery Date (DOW): 31/01/2019

Actual Delivery Date: 31/01/2019

Distribution - Confidentiality: Public

Code: 10.5281/zenodo.1240279

Abstract:

This document concerns the analysis results of the integration and validation requirements per trial, including the required adaptation and customization so that the NRG-5 will be fine-tuned, tested and validated in the real-life trial. Moreover, it specifies all the necessary hardware and software to be procured and installed in the testbed. This document will also provide the adaptation guidelines focused on the NRG-5 methodologies framework specified in WP1, to ensure proper adaptation and trial integration of the modules implemented in WP2 and WP3 and validated in laboratory environment in WP4.

H2020-ICT-2016-2 – 762013: NRG-5

D5.1: NRG-5 Trials Set-up

© The NRG-5 consortium partners, 2017 2

Disclaimer

This document may contain material that is copyright of certain NRG-5 beneficiaries and may not be reproduced or copied without permission. All NRG-5 consortium partners have agreed to the full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information.

The NRG-5 Consortium is the following:

The information in this document is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability.

Participant number

Participant organisation name Short name

Country

01 Engineering-Ingegneria Informatica SPA ENG Italy

02 THALES Communications & Security TCS France

03 SingularLogic S.A. SiLO Greece

04 Ineo Energy & Systems ENGIE France

05 Romgaz S.A RGAZ Romania

06 ASM Terni SpA ASM Italy

07 British Telecom BT UK

08 Wind Telecomunicazioni S.P.A. WIND Italy

09 Hispasat S.A. HIS Spain

10 Power Operations Limited POPs UK

11 Visiona Ingenieria De Proyectos SL VIS Spain

12 Optimum S.A OPT Greece

13 Emotion s.r.l EMOT Italy

14 Rheinisch-Westfälische Technische Hochschule Aachen RWTH Germany

15 Jožef Stefan Institute JSI Slovenia

16 TEI of Sterea Ellada/Electrical Engineering Dept. TEISTE Greece

17 University Pierre et Marie Curie UPMC France

18 Centro Romania Energy CRE Romania

19 Rutgers State University of New Jersey Rutgers USA

H2020-ICT-2016-2 – 762013: NRG-5



Document Revision History

Date Issue Author/Editor/Contributor Summary of main changes

23/03/18 0.1 F. Bellesini, C. Mancinelli (EMOT) 1st draft of ToC

09/04/18 0.2 F. Bellesini (EMOT), Luca Alfieri (ASM), Dominique Barthel (ENGIE)

2nd draft of ToC

27/04/18 0.3 F. Bellesini (EMOT), Antonello Corsi (ENG), José Maria Lalueza (VIS)

Consolidated ToC with instructions for the partners involved to provide contributions

15/06/18 0.4 F. Bellesini (EMOT), Luca Alfieri (ASM), Dominique Barthel (ENGIE)

1st Round of contributions

14/09/18 0.5 F. Bellesini (EMOT), José Maria Lalueza (VIS), Luca Alfieri (ASM)

2nd Round of contributions

23/11/18 0.6 F. Bellesini (EMOT), Tommaso Bragatto (ASM), Frederic Antonio (ENGIE), Antonello Corsi (ENG), José Maria Lalueza (VIS)

3rd Round of contributions

21/12/18 0.7 F. Bellesini (EMOT), Tommaso Bragatto (ASM), Antonello Corsi (ENG), Fabián González Suárez (HIS), Kostantinos Kalaboukas (SiLO)

4th Round of contributions

23/01/19 0.8 F. Bellesini (EMOT) Ready for Peer Review

30/01/19 0.9 F. Santori (ASM), John Davies (BT) Deliverable reviewed

31/01/19 0.10 F. Bellesini (EMOT), Tommaso Bragatto (ASM),

Addressing review comments

31/01/19 1.0 F. Bellesini (EMOT) Final Version

H2020-ICT-2016-2 – 762013: NRG-5



Table of Contents

1 Introduction ________________________________________________________________ 7 1.1 Purpose of the Document _________________________________________________________________ 7 1.2 Structure of the Document ________________________________________________________________ 7 1.3 NRG-5 Pilot Sites ________________________________________________________________________ 8

2 Terni Pilot Site_______________________________________________________________ 9 2.1 UC1 Trial Set-up ________________________________________________________________________ 13

1.1.1 2.1.1 UC1 Trial Workflow Description ............................................................................................................... 16 1.1.2 2.1.2 UC1 Hardware Catalogue ......................................................................................................................... 20 1.1.3 2.1.3 UC1 Software Catalogue ........................................................................................................................... 22

2.2 UC3 Trial Set-up ________________________________________________________________________ 23 1.1.4 2.2.1 UC3 Trial Workflow Description ............................................................................................................... 27 1.1.5 2.2.2 UC3 Hardware Catalogue ......................................................................................................................... 29 1.1.6 2.2.3 UC3 Software Catalogue ........................................................................................................................... 36

3 Storengy Pilot Site __________________________________________________________ 37 3.1 UC2 Trial Set-up ________________________________________________________________________ 38

1.1.7 3.1.1 UC2 Trial Workflow Description ............................................................................................................... 40 1.1.8 3.1.2 UC2 Hardware Catalogue ......................................................................................................................... 42 1.1.9 3.1.3 UC2 Software Catalogue ........................................................................................................................... 45

4 Conclusions ________________________________________________________________ 46

5 Acronyms _________________________________________________________________ 47

6 References ________________________________________________________________ 51

H2020-ICT-2016-2 – 762013: NRG-5



List of Figures

Figure 1: NRG-5 Pilot Sites in Europe .............................................................................................. 8

Figure 2: ASM headquarters ............................................................................................................. 9

Figure 3: Daily load profile of ASM buildings .................................................................................. 10

Figure 4: Terni pilot site configuration ............................................................................................. 11

Figure 5: Monthly embedded generation in Terni (2017) ............................................................... 12

Figure 6: 5G NORM ......................................................................................................................... 13

Figure 7: Microgrid advanced operation with NRG5 technologies in Terni pilot site ..................... 14

Figure 8: The NRG-5 components involved in the AMIaaS use case [8] ....................................... 15

Figure 9: AMIaaS local grid monitoring dashboard technical overview .......................................... 17

Figure 10: Registering new price offers to the local Energy Marketplace [8] ................................. 18

Figure 11: Selecting new price offers to the local Energy Marketplace ......................................... 19

Figure 12: AMIaaS local energy marketplace technical overview .................................................. 19

Figure 13: NORM already installed in Terni trial site ...................................................................... 20

Figure 14: Architecture of NORM devices ...................................................................................... 21

Figure 15: Data sending to local DSO server ................................................................................. 21

Figure 16: Power flow before RES integration ................................................................................ 23

Figure 17: Power flow after RES integration ................................................................................... 24

Figure 18: Overview of the entities involved in UC3 ....................................................................... 24

Figure 19: Fault detection and isolation in the power grid .............................................................. 25

Figure 20: Dispatchable Demand Response Sequence Diagram [8] ............................................. 26

Figure 21: DDRaaS edge computing domain ................................................................................. 27

Figure 22: Renault ZOE customized by Emotion ............................................................................ 29

Figure 23: Nissan LEAF .................................................................................................................. 30

Figure 24: 2nd life Li-ion battery energy storage cabinet ............................................................... 31

Figure 25: 2nd life Li-ion batteries ................................................................................................... 31

Figure 26: Emotion SpotLink EVO charging stations...................................................................... 32

Figure 27: Efacec QC45 .................................................................................................................. 33

Figure 28: PV plants at the Terni trial site ....................................................................................... 34

Figure 29: PV production at the Terni trial site................................................................................ 34

Figure 30: ABB inverters (single module) ....................................................................................... 35

Figure 31: Stublach Gas Storage Facility ....................................................................................... 37

Figure 32: Overview of the components involved in UC2 ............................................................... 38

Figure 33: Workflow of a PMaaS scenario [8]................................................................................. 39

Figure 34: Drone with thermal camera ............................................................................................ 42

Figure 35: Pixhawk 2.1 flight controller ........................................................................................... 43

H2020-ICT-2016-2 – 762013: NRG-5



List of Tables

Table 1: 5G KPI for UC1 [5] ............................................................................................................ 15

Table 2: 5G KPI for UC3 [5] ........................................................................................................... 26

Table 3: 5G KPI for UC2 [5] ............................................................................................................ 40

H2020-ICT-2016-2 – 762013: NRG-5



1 Introduction This document is the first deliverable produced within the Work Package 5, which will evaluate the real-

life trials and provide feedback to the technical WPs in order to optimize NRG-5 developments, evaluate

the KPIs defined in WP1 and serve as a reference for exploitation and draft the steps to bring the results

to the market.

1.1 Purpose of the Document

This document concerns the analysis results of the integration and validation requirements per trial,

including the required adaptation and customization so that the NRG-5 will be fine-tuned, tested and

validated in the real-life trial. Moreover, it specifies all the necessary hardware and software to be procured

and installed in the testbed. This document will also provide the adaptation guidelines focused on the

NRG-5 methodologies framework specified in WP1, to ensure proper adaptation and trial integration of the

modules implemented in WP2 and WP3 and validated in laboratory environment in WP4.

1.2 Structure of the Document

Deliverable 5.1 is structured into four sections. The first section describes the NRG-5 pilots, their location

and rationale, in accordance with the objectives of the project. Section 2 discusses in detail the pilot site

of Terni, where use cases 1 and 3 (UC1 and the UC3) will be deployed. After an initial description of the

background of the Terni pilot site, an overview of the UC1 trial area is presented; an analysis of the

integration and validation of UC1 requirements is provided, including a description of the workflow test

(preparation, triggering event, operations) with clear reference to the global architecture of NRG-5. Then

the hardware necessary for the demonstration of UC1 are described and the software necessary for the

demonstration of UC1 are listed (UCs software description are included in D4.3 [1]). Subsequently, with

the same progression used for the UC1, UC3 is addressed. In Section 3 the pilot site of Stublach, where

UC2 will be deployed, is discussed using a similar structure to UC1 and UC3 descriptions. Finally, section

4 contains our concluding remarks.

H2020-ICT-2016-2 – 762013: NRG-5



1.3 NRG-5 Pilot Sites

The NRG-5 project will conduct real-life demonstrations in two different pilot sites, with the aim of demonstrating the advantages of the application of 5G technology in the energy sector.

One pilot site is located in Terni (Italy) and provided by ASM, the municipal operator for the electricity and gas distribution network in Terni, and EMOT, a leading company in the electric mobility sector. The pilot site of Terni is equipped with several branches of a low voltage power supply network and it has a surplus of energy generated locally by local RES that generates reverse power flow through the secondary MV/LV substation and gives rise to a significant demand of local energy consumption to avoid imbalances in the electricity grid. The surplus energy will be compensated by DR campaigns in which electric vehicles will be involved, taking advantage of the daily need to recharge them. Furthermore, Terni’s advanced metering infrastructure will be used for near real time monitoring for power network optimisation.

The other pilot site is located in Stublach (UK) and provided by ENGIE, one of the foremost companies in Europe for the distribution, transportation and storage of natural gas, with a gas portfolio of 1,296 TWh and a LNG portfolio of 16.4Mpa. In France alone, ENGIE has 32,153 km of high-pressure pipelines, which connect seventeen operators of distribution networks, ten million domestic customers and eight hundred industrial customers, including twelve gas-fired power stations. In the ENGIE pilot site we will evaluate predictive maintenance and incidents localization using drones, latest generation SCADA, gas pressure sensors/actuators and a multi-RAT environment of cellular, satellite and WiFi connectivity.

Figure 1: NRG-5 Pilot Sites in Europe

H2020-ICT-2016-2 – 762013: NRG-5



2 Terni Pilot Site The Terni trial site will be used to validate two Use Cases (UCs), namely Advanced Metering Infrastructure as a Service (UC1: AMIaaS) and Dispatchable Demand Response as a Service (UC3: DDRaaS).

Figure 2: ASM headquarters

Terni trials will take place at the ASM’s headquarters. According to the general overview given in Figure 2, ASM district can be considered as a living lab because of the presence of advanced technologies already tested and in operation for the purpose of validating the main pillars of a smart grid (e.g. AMI, DR, Storage, EV integration, V2G). In particular, the district consists of the following block of energy units:

• Two PV arrays (180 kWp and 60 kWp), connected to the LV network;

• 72 kWh 2nd life Li-ion battery energy storage is the Block of Energy Unit (BoEU) providing the

electric power storage and supply services. It is the BoEU that plays an important role in providing

the district with the flexibility necessary to implement different services, especially ancillary services

like Primary reserve, Dynamic reactive Power control and Reactive Power Compensation;

• ASM Terni buildings comprising a 4,050 m2 three-storey office building, a 2,790 m2 single-storey

building consisting of technical offices, a computer centre and an operation control centre and a

1,350 m2 warehouse; usually the base load varies between 50 kW and 90 kW and peak load is

between 120 kW and 170 kW, depending on seasonal factors. A daily load profile is shown in

Figure 3 as an example;

H2020-ICT-2016-2 – 762013: NRG-5



Figure 3: Daily load profile of ASM buildings

• Three smart charging stations (two SpotLink EVO and one Efacec QC45) and six electric vehicles

(four Renault ZOE and two Nissan LEAF) will be part of the Terni pilot site. The 22 kWh/40 kWh

lithium-ion batteries of Renault Zoe are charged at 22 kW SpotLink EVO charging station while a

Efacec QC45 charging station, supplying up to 50 kW DC, is used to charge the 22 kWh lithium-

ion batteries of Nissan LEAF.

This energy infrastructure is enhanced by an innovative metering system, made up of new generation smart meters (NORM [2]) able to collect real time data from the most crucial points of the district and transmit the data through the mobile network (GSM). Figure 4 shows the single line diagram of the ASM’s living lab in which the UC1 and UC3 will be tested and validated. Specifically, the NORM devices are marked with green square.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 4: Terni pilot site configuration

It is worth pointing out that the aforementioned living lab is a part of the distribution power network of the city of Terni, which is owned and managed by ASM Terni. This power network is connected to the HV grid through three substations. There are also six MV/MV substations and more than six hundred MV/LV substations, supplying about sixty-five thousand energy customers. Nowadays, the ASM network shows relevant features of the “smart grid” since 99% of customers have a smart meter managed remotely by an Advanced Metering Infrastructure (AMI). Moreover, the high penetration of renewable energy sources (RES) has dramatically changed the paradigm of the network management, creating a reverse flow and congestions where production and consumption are not balanced.

In 2017, the energy consumption reached 350 GWh, while the distributed production units connected to the MV/LV network (DER) generated 182 GWh. Thus, about 50% of the total consumption was covered by RES. In 2017 the local power network received renewable energy from 1228 power generation plants (1217 PV arrays, 7 hydro plants, 4 biomass/waste to energy) using renewable sources, such as sunlight, water and biomass. In 2017 the total electric power generated from RES was as follows, considering only the main contribution (i.e. these data do not consider small plants that produce from other sources a negligible amount of energy):

- 36 GWh from solar energy;

- 68 GWh from hydropower;

- 78 GWh from waste material.

The energy production from hydropower, solar, and waste for each month in 2017 is shown in the figure below.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 5: Monthly embedded generation in Terni (2017)

The energy transition requires enabling of new services at capillary level by means of real time exchanges of both technical and economic information between new and old actors (e.g. DSOs, Aggregators, microgrid managers, EV fleet managers) and each single user and/or prosumer, as well as NRG-5 aims to demonstrate.

Considering the present status of the distribution network which connects an increasing amount of distributed generators, the DSO is going to assume more responsibility as coordinator of distributed local resources, notably, it is going to acquire observability of the network, in order to provide real-time data to various stakeholders (e.g., Transmission System Operators, market actors, customers). A reliable and secure observability can enable market participation of distributed generators, as already investigated by the Italian Authority in [3], as well as allow the implementation of flexibility market and peer-to-peer transactions foreseen by Directive [4]. The observability improves by itself the reliability of the Transmission Services that are already based on the load forecasting and production plan carried out by the programmable plants. In addition, real time measurements are a pillar for the deployment of a real time management of the distributed resources carried out by the DSO or other stakeholders (e.g., Aggregator, RESCO companies). In order to provide these services, the DSO should be capable to manage real-time data as well as information exchange between distributed devices.

In order to reach these goals, DSOs implementing the desired Virtual Network Functions are evaluating

the installation of real time smart meters, which are able to produce a notable amount of data every month

(i.e., they sample electrical values per second). By means of 5G technology, those smart meters will be

capable to actively transmit data and to support advanced services for the Smart Grid. Moreover, 5G will

allow meter points communication resulting in the reliable and profitable exchange of electric information

H2020-ICT-2016-2 – 762013: NRG-5



2.1 UC1 Trial Set-up

Based on D1.1 [5], one of the main objectives of NRG-5 project is to achieve truly decentralized, secure and trusted plug ‘n’ play by combining MTC VNFs and inherited physical functions of low-end devices. With respect of the Mobile Edge Computing (MEC), combining elements of information technology and telecommunications networking, novel and scalable xMEC paradigm focused on energy will be realized. As a consequence, customers will be able to play an active role in energy flexibility, exploiting efficiently decentralized energy generation and local storage and enabling intensive neighbourhood/local energy related activities with the support of xMEC functionalities.

According with D1.1, this use case considers the emergent energy market and its relative services, used by local microgrid, that aims to maximize self-consumption and to reduce the energy exchanged with the DSO network.

For the integration of the different functionalities requested by the UC1, near-real time smart meters (i.e. NORM [2]) are considered. They are characterized by low cost, high level of security and suitable operational functions. NRG-5 extensions developed over the project will facilitate distributed, scalable and trusted plug ‘n’ play functionality of hardware constrained devices (SM contains a Linux machine with limited resources, where the SMG is implemented with single board computers such as Raspberry Pi3 or BeagleBone Black) in order to allow easy, real time, automated devices identification.

Figure 6: 5G NORM

NORM can be used as a new stand-alone meter (when equipped with the proper metrology and hard-real time features) or to expand legacy aspects of the meter with more functionalities and securities and with added hard real-time features such as PMU functionality [6].

In this scenario there are three different components that usually constitute the xMEC architecture:

- edge devices connected to the network (NORM being chosen as the proper edge device);

- edge cloud deployed as mobile base station with the responsibility of traditional network traffic

control and hosting various mobile edge applications;

- public cloud which is the cloud infrastructure hosted in Internet.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 7: Microgrid advanced operation with NRG5 technologies in Terni pilot site

It can be seen that peer-to-peer connections are possible, functionalities to be developed under 5G-NORM equipment associated with each prosumer or consumer. The implementation of this use-case requires all the listed VNFs with a specific attention to the plug ‘n’ play facility to make the trustful connections between the prosumers and consumers, the blockchain based transactions, the operation, measurement and settlement of the transacted services.

Based on D3.2 [7], in order to validate UC1, the AMIaaS case can be split into two basic and independent views effectively implementing Dashboard-as-a-Service (DaaS) and Marketplace-as-a-Service (MaaS). The core functionalities for each of these views are based on the coordinated interworking of NRG-5 VNFs (particularly for data gathering and identity validation). Figure 8 offers an overview of the NRG-5-based architecture that the application logic of AMIaaS will implement, omitting the device identification and network establishment operations handled by vTSD and vSON, namely the VNF devoted to self-discovery and self-organization of the network.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 8: The NRG-5 components involved in the AMIaaS use case [8]

In the UC preparation, the following actors are identified:

- End users. For each smart meter a user is identified and it will demonstrate the DaaS;

- Energy managers. For the most notable block of energy units, namely building, storage system,

PV plants. Energy managers want to submit and participate to flexibility market;

- Utility. In this use case the utility is represented by the DSO. In line with with previous figures, the

utility will manage the Visualization and keep a record of new offers.

Table 1: 5G KPI for UC1 [5]

No Description Low Medium High

1 Device density (dev/km2)

≥ 10.000

2 Mobility < 3 (pedestrian)

3 Infrastructure Big number of small cells (>10)

4 Traffic type Burst Periodic

5 User Data Rate (Mbps) 50 ÷ 100

6 Latency (ms) 1 ÷ 10

7 Reliability > 99 %

8 Availability > 99 %

xMEC

Smart Meters

RES DES PMU

vMCM vRES vDES vPMU

Local Grid Monitoring Dashboards

Micro-contracts marketplace framework

vBCP/vAAAvBCP/vAAA

UtilitiesEnergy Prosumers

H2020-ICT-2016-2 – 762013: NRG-5



2.1.1 UC1 Trial Workflow Description

In order to prepare the trial demonstration, the VNFs have to be deployed at xMEC evaluating their ability to self-discover and self-organize the network. As well as functionalities deployment, already identified in D3.2, the installation of related HW/SW equipment is done according to the context. Regarding AMIaaS, as general approach, three contexts can be identified:

- Edge. In this context, 10 NORMs are installed at the block of energy units to provide xMEC

services; they should be able to make data gathering, to validate the identification, to support utility

roaming, to be controllable by the utilities in case of emergency;

- Local. In this context, local server is installed at ASM premises an edge cloud; to validate its

functionalities, it will provide data visualization, transparent billing service and support to local

energy market;

- Regional. In this context, external support for the data forecasting is provided to local utilities.

During the UC preparation, the following requirements will be fulfilled:

- The Phasor Measurement Units (PMUs) will be installed in strategic locations in order to monitor

the stability/quality of the grid;

- Smart meters infrastructure should be deployed and integrated into the smart grid.

Three main triggering events can be identified as starting point of the UC1:

- A new SM meter is connected to the network and its data are visualized by the dashboard;

- A user wants to change utility contract;

- A utility wants to register new prices offers.

Regarding the ability of Utilities to quickly graphically overview the status of the power grid, each of the Utility VNFs (e.g. vRES, vDES, vPMU) will gather data directly from their physical counterpart, which are the Smart Meters leveraging on vMCM and will, in turn, perform the intended data manipulation operations. Depending on the time criticality and delay tolerance of the data sets, they can be either streamed to the blockchain infrastructure through vBCP or not. In any case, the data will be, then forwarded to a microservices-oriented platform exposing DaaS capabilities, whose main details are provided in D3.2.

To support big data analytics frameworks, a proper message bus featuring publish subscribe protocols like Apache Kafka or AMQP clusters will be also provided as a data integration mechanism. Figure 9 offers a graphical overview of the technological approach that will be used for the implementation of the DaaS. As for Figure 8, the AMIaaS providers are either vMCM or vAAA. Note that the API server, the PubSub bus and the time series DB may be configured as clusters of relevant services (e.g. in the form of a Kafka cluster or a DB shard) to enforce security from an availability and performance perspective.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 9: AMIaaS local grid monitoring dashboard technical overview

The DaaS may validate the following requirements:

- Private data and data coming from measurements will be protected, so as not to reveal the actual

identity of the individual(s) involved;

- The VNFs installed will allow the data anonymization by using anonymous labels in some

databases and personal reference in other databases;

- Measurement data will be communicated in a real time fashion, as soon as they become available,

to support their further processing;

- The communication infrastructure will be able to support the concurrent communications of

multimillion SM devices distributed in local, regional or national level;

- The data owners will decide for which purposes their data can be used (Role Based Access Control

- RBAC should be implemented at the user side of the smart meter).

As far as the process of publishing new energy offers is concerned, a Utility suppose that after overviewing the AMIaaS Dashboards they consider that they should create a DR campaign setting the prices to a set of possible end-users. As a first step, they get the list of possible clients as stored in the blockchain, after being authenticated/authorized to do so. Next, they post the new offers to vBCP. Next, the vBCP hooks inform the marketplace mechanisms about the registered contract options and inform the associated end-users.

Grafana DashboardsTime Series DB

Time Series DB

AMIaaS

ClientAMIaaS

ClientAMIaaS

Provider

PubSub

ClusterPubSub

ClusterPubSub

Bus

API

ServerAPI

ServerAPI

Server

H2020-ICT-2016-2 – 762013: NRG-5



Figure 10: Registering new price offers to the local Energy Marketplace [8]

A similar approach is followed by the end-users, when, after receiving the relevant notification, they should trigger vBCP to get the list of available offers, then select one and register it as selected in the blockchain as a signed micro-contract; when a selection has been registered, the vBCP hooks will notify the Utilities about the newly signed micro-contract.

This approach concerning MaaS validates the following requirements:

- A set of analysis will be performed triggered by certain events (such as reception of new data) and

the VNF will support execution of analysis algorithms upon preconfigured triggers;

- The energy prosumer will be able to have a lock-in free energy service in a dynamic fashion;

- The VNF shall be able to communicate with a defined number of protocols.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 11: Selecting new price offers to the local Energy Marketplace

Despite the workflow being more complex than in the dashboard case, the technical framework of the AMIaaS Marketplace is straightforward, being depicted in Figure 12.

Figure 12: AMIaaS local energy marketplace technical overview

This approach concerning MaaS validates the following requirements:

- Prosumers / end-users will be able to connect point-to-point for direct blockchain transaction;

- The energy prosumer will be able to have a lock-in free energy service in a dynamic fashion.

.

Marketplace

Instance

vBCP

client of

Actor

vBCP

vAAA Related Actors

H2020-ICT-2016-2 – 762013: NRG-5



2.1.2 UC1 Hardware Catalogue

Data Transmission Device

In UC1 5G-NORM devices are involved. Thanks to the NRG5 extensions developed over the project, they support the scalable and trusted plug ‘n’ play functionality for a simple, real time, automated devices identification.

According with the NORM definition [9] metrology part of existing smart meters has been enriched by means of the installation of extensions able to support 5G – extension, developed over the project. In the ASM trial site, as shown in Figure 13, existing smart meters are used to validate 5G extension, belonging to 2 different types:

- Power Quality Analyzer, Class A, produced by TeamWare, connected to a SM extension (SMX)

able to collect and transmit real time data and suitable gateway for running the 5G extensions and

the VNFs. The SMX is a result of the NOBEL GRID project [10];

- Smart Low-cost Advanced Meter (SLAM), which is a results of the NOBEL GRID project as

example of unbundled smart meter, with both the metrology part and the gateway for data collection

and transmission integrated in the same device.

In both case, a Beagle Bone Black will be devoted to support NRG-5 contents, sending data to edge cloud and public cloud using the mobile network; it is worth pointing out that all the devices are already using 4G network to communicate. According with the 5G-NORM schema provided in Figure 6, the metering infrastructure has been improved in functionality through the installation of PMUs in most critical points of the trial.

Figure 13: NORM already installed in Terni trial site

Moreover, for a secure and encrypted communication, a based cryptographic technology namely Physical Unclonable Function (PUF) has been integrated in the NORM device to offer a decentralized trust & identity management mechanism, supporting end-users privacy by design [2].

Furthermore, some NORMs have been integrated with few low cost phasors (PMUs) that provide scalable and reliable finer grained information to enable improved smart grid self-recovery via power re-routing scenario completely. Specifically, PMU can provide 50/60 frames per seconds which will allow a real time

H2020-ICT-2016-2 – 762013: NRG-5



improved state network estimation within the order of tens of milliseconds, thus greatly contributing to improve the near real time observability of the grid.

The architecture of 5G-NORM devices is described in the figure below:

Figure 14: Architecture of NORM devices

The collected data are then sent to local DSO server, as shown in Figure 15.

Figure 15: Data sending to local DSO server

Local hardware platform

Both the Dashboard and the Marketplace will be offered as complete integrated OpenStack QCOW2 images as well as Docker Compose and Kubernetes recipes so that they can be instantiated on demand (as a Service); when installed as singleton QCOW2 or via a Docker Compose script, everything will be installed integrated in a monolithic way (as different components hosted in a single deployment environment) following a pseudo-microservices-oriented approach. A server will be deployed locally; its main technical requirements are the following:

• CPU: 2 core 3.1 GHz;

• HDD: 50 GB;

• RAM: 4 GB;

• S.O.: Ubuntu 15.04.

MOBILE NETWORK

H2020-ICT-2016-2 – 762013: NRG-5



2.1.3 UC1 Software Catalogue

As per the project cause, the trial software (local xMEC) will be hosted under the supervision of an OSM installation, having OpenStack as VIM of choice. The OpenStack configuration will be such that pre-built images (working instance snapshots) will be available to be instantiated as VNF VDU instances.

VNFs

General Core VNFs:

• vTSD: virtual Terminals Self-Discovery;

• vSON: virtual Self-Organizing Networks;

• vMCM: virtual Machine-Cloud-Machine;

• vMME: virtual Mobility Management Entity;

• vBCP: virtual Blockchain Processing;

• vAAA: virtual Authentication, Authorization, Accounting.

Smart Energy Specific VNFs:

• vPMU: virtual Phasor Measurement Unit;

• vRES: virtual Renewable Energy Sources;

• vDES: virtual Distributed Energy Storage.

Other services and APIs

On top of the above VNF requirements (and the associated MANO and NFVI/VIM ones), for implementing the extra functionality of AMIaaS, the following software components will be employed:

• Grafana: dashboard offering flexible graph and plot capabilities;

• Influx DB: time series database acting as temporary persistence layer feeding Grafana;

• A mediation service reading from vMCM and feeding InfluxDB;

• The AMIaaS Marketplace software platform.

H2020-ICT-2016-2 – 762013: NRG-5




UC3 analyses a problem that arose after the advent of distributed generation. As shown in Figure 16, before the integration of the RES, the power flow was unidirectional: the power was generated in the large power plants from which the high voltage networks operated by the TSO (Transmission System Operator) started, then the power was transformed into medium and low voltage in the networks managed by the DSO (Distribution System Operator) and finally reached the end users.

Figure 16: Power flow before RES integration

As shown in Figure 17, after the integration of the RES, the power flow has become bi-directional. In the part of the electrical network where the end users are located (LV/MV grid) now there are production plants from renewable sources, such as photovoltaic or wind turbines, which generate intermittent energy and often their energy produced is not consumed instantaneously locally. As that part of the electricity network had been built with the idea that the end user was exclusively a consumer of energy and as therefore no energy storage facilities had been installed, the phenomenon of reverse power flow has arisen.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 17: Power flow after RES integration

Reverse power flow causes stability and safety problems, like voltage rise, frequency imbalance and fault equipment tripping; for this reason, more and more demand response (DR) campaigns are being experimented, with the aim of instantaneously consuming the energy produced from renewable sources locally. At the Terni pilot site there are two photovoltaic plants, which produce more energy than is necessary for the company, causing a reverse power flow in the secondary substation SCOV. For this reason, it was decided to implement DR campaigns in the ASM district involving both a Li-Ion battery storage system and electric vehicles (EVs).

Figure 18: Overview of the entities involved in UC3

DR campaigns should therefore mitigate the problems due to the reverse power flow, reducing the complication caused by failures and outages, helping to isolate faults and restore services managing power flows in real time.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 19: Fault detection and isolation in the power grid

Therefore, UC3 scenario can be divided in 3 phases:

• DSO request of flexibility;

• DR application sends a DR campaign to the selected devices/VNFs with flexibility information;

• The vESR will collect real data resulting from VNFs and offer to the DSO a DR application.

The figure below shows the Dispatchable Demand Response Sequence Diagram, highlighting the interactions between DSO, DR Application, vESR and VNFs.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 20: Dispatchable Demand Response Sequence Diagram [8]


.



1000 ÷ 10.000

2 Mobility > 50 (fast moving vehicles)

3 Infrastructure Macro cell coverage

Small amount of small cells (<10)

4 Traffic type Continuous Event driven

5 User Data Rate (Mbps) < 50 50 ÷ 100

6 Latency (ms) 1 ÷ 10 10 ÷ 50 > 50



H2020-ICT-2016-2 – 762013: NRG-5




The demonstration of DDRaaS is based mainly on the integration of a certain number of devices and VNFs tailored and fine-tuned for the provision of energy flexibility to the DSO in case of network and energy balance problems could arise. The software infrastructure for the demonstration of 5G requirements in case of Demand Response is the one based on the xMEC for guarantee low latency provision of dispatchable demand side campaign. To this purpose the integration of computing process near the edge cloud is to allowing the sensing data to be stored and used intelligently for smart monitoring and powerful processing of sensing data streams. This kind of computation pulls the cloud computing to the edge of network and allows data to be pre-processed whenever latency limitation is required and leads to increase in interoperability, scalability, consistence and connection between smart devices. In a bulk electrical network, the mobile edge computing can be realized dividing the smart grid in local sub-networks called microgrids. A microgrid is a small-scale local power grid that can operate independently or in connection with the utility grid, which constitutes of power resources, generation and loads and definable boundaries. As it is possible to analyse from Figure 21 we can divide the ASM network in one or more microgrids considered as an edge computing domain and these edge/microgrid elements can communicate via vMCM. Is it possible, depending on the requirements of the application that is running, i.e. the Demand Response algorithm and fault localization, to identify different cluster of devices or VNFs to put in place the software set of item needed for the real deployment and test of this scenario.

The Demand Response application deployed in the central cloud is coordinated with different edge nodes cluster to collect data before and after DR campaign. In the edge is executed the portion of calculation that keep the latency of the service for provision of energy flexibility low. Each of the real devices in Figure 21 is sending data to a virtual twin that is the VNF of the storage or PV renewable source. With lack dot in figure are indicated the VNFs that are running in behalf of the real device.

Figure 21: DDRaaS edge computing domain

H2020-ICT-2016-2 – 762013: NRG-5



In order to perform DR campaign through electric vehicles, different models of EV's should easily be integrated in vDES and different models of charging stations should easily be integrated in vDES; moreover, it is necessary that a EVSE unique identifier will be used. It will be possible to perform a DR campaign in which all the EVSEs are involved through EVSEs can be grouped as one hub, vDES should allow grouping EVSEs in one hub, sharing the same location, leaving however the possibility to the Fleet manager to autonomously manage the EVSE. DR campaigns require continuous monitoring of energy production and energy consumption, for this reason, adequate amount of equipment for monitoring the distribution network is installed, so vESR will calculate the reference load profile per regulation area. Regarding user authentication and data management, the end user should be registered and authorised in order to charge and/or book an EV in the system, the EVSE operator or the fleet manager has an updated list of known users (for authentication process), the system should detect and avoid attempted intrusions by unauthorized persons, anonymising charging data to assure data privacy in case of private EVs and the tool should prevent access to data (energy, meteorological, customer contracts, etc.) from unauthorized persons or client applications.

The application logic coordinates the EV charging plane in accordance with the flexibility request arriving from the DSO. In case of unbalance between production and consumption, as registered and reported by vESR that measures displacement among renewables and storage available, reported by vRES and vDES, a DR campaign is issued and any devices under the microgrid is informed of their duty for automate demand response fulfilment. In conclusion, the vDES will receive the DSO flexibility needs through vESR.

All the energy VNFs of this UC will interact with the general core VNFs following the simple list of actions: the general core VNFs will allow the self-discovery and self-organization inside the network of the energy VNFs. These energy VNFs will be authenticated thanks to the vAAA. The communication will be regulated by the vMCM that enables the communication between the devices and the cloud. Each mobile device will be managed by the vMME. The sensitive information if needed will be stored in the vBCP. Once recognized in the network the device will produce data that will be aggregated by the vDES and vRES; after that will be calculated the flexibility available in a given time frame with internal algorithm. These flexibilities will be provided to the vESR and in case of unbalance aroused by DSO the DR application will trigger a DR campaign to smooth the unbalance through spread of EV in useful charging stations communicating with the EV application running on the central cloud. The vDES will calculate the aggregated flexibility capabilities of the EVSEs under its, based on EV status available (SOC), Nominal battery characteristics and vDES gathers data from EVs via API's. Thanks to the Implementation of an algorithm that calculates the best option to manage an energy production surplus, the vDES will modulate the power output of his EVSE network to maximise the RES integration answering the DSO flexibility requests. To verify the effectiveness of the DR campaign during its advancement, vDES must provide real-time monitoring of the EVSE equipment (and the EV fleet) to the EVSE manager (and EV-fleet manager). If EVs are not connected to the EVSEs during the request for flexibility, the system must be able to contact the EV users, with the aim of involving him in the DR campaign. In this regard, will be sent to the users a notification of near charging stations, list of available charging stations with booking possibilities, clear identification of the EVSE on its casing; the EV user only will provide flexibility to the system allowing the system to module his charging session if he wants. If not, his car will be charged asap. If the DR campaign has been performed as a result of a disruption, it is calculated the power and energy capability of the storage system in order to meet the black start requirements and consequently STaaS/VPP should provide islanding mode in case of a power outage. Regulation allows islanded operation of part of the distribution network and the vDES will modulate the power output of his EVSE network to help the DSO with the grid operation.

H2020-ICT-2016-2 – 762013: NRG-5




Distributed Energy Sources

A fleet of six electric vehicles and a battery storage system will be involved in the DDRaaS trial. Regarding electric vehicles, two models will be used: Renault ZOE and Nissan LEAF.

Figure 22: Renault ZOE customized by Emotion

Renault ZOE, acronym of ZerO Emissions, is a five-door supermini electric car produced by the French manufacturer Renault. The ZOE is powered by a 22 kWh lithium-ion battery pack weighing 275 kg, driving a 65 kW (87 bhp; 88 PS) synchronous electric motor supplied by Continental (the Q210). Maximum torque is 220 N·m (162 lb-ft) with a top speed of 135 km/h (84 mph). The NEDC cycle range is 210 km (130 mi). Renault estimates that in suburban use, the ZOE can achieve around 100 km (62 mi) in cold weather and 150 km (93 mi) in temperate conditions. The car features a charging system called "Caméléon" (Chameleon) charger that allows the ZOE to be charged at any level of power, taking between 30 minutes and nine hours [11].

H2020-ICT-2016-2 – 762013: NRG-5



Figure 23: Nissan LEAF

The Nissan LEAF, acronym of Leading, Environmentally Friendly, Affordable, Family car, is an electric propulsion car introduced by Nissan on the markets in December 2010. It is equipped with an 80 kW (109 hp) synchronous AC electric motor. The first version equipped a lithium-ion battery, consisting of 48 modules and each of them contains 4 cells for a total of 192, with a capacity of 24 kWh with an autonomy of 199 km NEDC cycle. Since 2016, a 30 kWh Lithium-ion battery with an operating cycle of 250 km NEDC is available as an accessory. Nissan LEAF recharges in alternating current or in direct current. In AC, LEAF uses an on-board charger with a maximum 7.4 kW (32A maximum current, 230V, single-phase) with the Type 2 socket. In DC it uses the CHAdeMO standard up to 50 kW of power. Charging times vary from 5/6 hours to about 7 kW up to 1 hour with direct current charging [12].

The Battery storage system, 72 kWh 2nd life Li-ion battery energy storage, is the Block of Energy Unit (BoEU) providing the electric power storage and supply services installed in ASM district during ELSA project [13]. It is the BoEU that plays an important role in providing the district with the flexibility necessary to implement different services, especially ancillary services like Primary reserve, Dynamic reactive Power control and Reactive Power Compensation.

H2020-ICT-2016-2 – 762013: NRG-5



Figure 24: 2nd life Li-ion battery energy storage cabinet

Figure 25: 2nd life Li-ion batteries

H2020-ICT-2016-2 – 762013: NRG-5



Charging Stations

Three smart charging stations will be involved in the DDRaaS trial, two 22 kW charging stations (SpotLink EVO) and one 50 kW charging station (Efacec QC45).

The SpotLink EVO charging station with 1 or 2 type 2 sockets, recharges up to 32 A single-phase or three-phase for each socket; it is equipped with a 7” touch screen panel to manage recharges and offers many features, such as the location and navigation to the charging station (through the dedicated App) and the recharge with coupon code or credit card directly from the App. It allows the operator to remotely monitor and manage all the functions of the charging station such as recharge powers, recharge prices, statistics and reporting.

Figure 26: Emotion SpotLink EVO charging stations

H2020-ICT-2016-2 – 762013: NRG-5



SpotLink EVO works with plug Type 2 or Type 3A, its nominal voltage is 230 VAC in mono phase or 400 VAC in three phases, its nominal current is 32 A and its nominal frequency is 50 Hz. SpotLink EVO protection grade is IP54, the impact resistance is IK08 and the protection system is differential type A and type B, with an automatic unlocking of the connector in case of power failure. It equips a single-board computer, a certified MID energy meter and a RFID reader. SpotLink EVO connectivity is through RJ45 port (LAN) or 3G modem.

The QC45 quick charging station provides a rapid battery charge and supports two EVs simultaneous AC and DC charging with multiple power output options. The QC45 is a flexible and open charging station able to charge in a standalone mode or integrated in any network with any central system. The QC45 has DC output with power up to 50 kW and optional AC output with power up to 43 kVA. The battery charging status is displayed in a TFT color screen. The QC45 has high quality and robust enclosure with corrosion protection, equivalent to stainless steel, to ensure extended equipment lifetime [14].

Figure 27: Efacec QC45

H2020-ICT-2016-2 – 762013: NRG-5



Renewable Energy Sources

Two PV arrays (180 kWp and 60 kWp), connected to the LV network (Figure 28) will be part of the DDRaaS demonstration. Production of these plants are plotted, as example, in Figure 29.

Figure 28: PV plants at the Terni trial site

Figure 29: PV production at the Terni trial site

H2020-ICT-2016-2 – 762013: NRG-5



Monitoring & Data Transmission Device

In ASM headquarters, a server farm is already installed and a virtual machine will be devoted to UC3 demonstration. The devoted server will have 30 GB Hard disk, 8 GB RAM.

EMOT will use two server machines for the UC3, following the server details:

EMOT server machine 1 details:


• HDD: 50 GB;

• RAM: 4 GB;

• S.O.: Ubuntu 15.04.

EMOT server machine 2 details:


• HDD: 50 GB;

• RAM: 8 GB;

• S.O.: Ubuntu 17.10.

EMOT charging stations will exchange data through their single-board computer, a Raspberry Pi 3, with a CPU of quad-core ARM Cortex A53 1.2 GHz, a SD of 16 GB, a RAM of 1 GB and a Raspbian Stretch 4.14 S.O.; EVSE data collected will be mainly the energy data (power, voltage, current) and the number of plugs in use (0/1/2).

Regarding EV monitoring, EMOT will use an OBD device to retrieve data from the EV; OBD is a IoT component that utilize a TCP/IP communication to a TCP/IP server. The network connectivity of the OBD device is via data SIM (UMTS) and the server is a python software, which queries the EV each 5 seconds. The OBD connects to the diagnostic interface from which it is able to extract the information from the electric vehicle control unit using the CAN-bus protocol. The output data format of the OBD is an ASCII string; when the data is sent to the server, it is reorganized into a wrapper, thus obtaining a grouping of the data in JSON format. From the EV will be retrieved the following data: battery state-of-charge (SoC), geolocation, doors car state and engine car state.

Furthermore, also in the UC3 will be used the same smart meters involved in UC1 (5G-NORM), shown and described in UC1 hardware catalogue.

Regarding the battery storage system, it will be managed by ABB inverters, each module (12 kWh) has its own inverter and control module developed by Boygues during ELSA project [13]. The new power converter system proposed by ABB is composed of a single reversible inverter AC/DC of 24 kW and one to eight DC/DC charger of 12 KW. Every AC/DC or DC/DC power component is accompanied by an ARM chip based micro-controller named respectively ACC and DCC. These microcontrollers are in charge of the power converter operation monitoring and control, as well as the communication by CAN bus with SC and SSC controller.

Figure 30: ABB inverters (single module)

H2020-ICT-2016-2 – 762013: NRG-5




In the Terni Pilot site, the software, in addition to the VNFs, that will handle the entire flow of the UC3 and manage the NS will be:

• OSM installation;

• MAPE installation;

• OpenStack;

• Application Logic issuing DR campaign;

• EV fleet Dashboard.

VNFs

General Core VNFs:

• vTSD: virtual Terminals Self-Discovery;

• vSON: virtual Self-Organizing Networks;

• vMCM: virtual Machine-Cloud-Machine;

• vMME: virtual Mobility Management Entity;



Smart Energy Specific VNFs:

• vPMU: virtual Phasor Measurement Unit;

• vESR: virtual Electricity Substation & Rerouting;

• vRES: virtual Renewable Energy Sources;

• vDES: virtual Distributed Energy Storage.


• EMOT Charging Station API;

• EMOT Charging Session API;

• EMOT Electric Vehicle API.

Furthermore, to carry out the advanced metering infrastructure functionalities for UC3, the following software components will be employed:

• Grafana: dashboard offering flexible graph and plot capabilities;

• Influx DB: time series database acting as temporary persistence layer feeding Grafana.

H2020-ICT-2016-2 – 762013: NRG-5



3 Storengy Pilot Site ENGIE is a leading worldwide energy company, Engie Ineo is part of ENGIE Energy Services.

For the pilot site, Engie Ineo called on Storengy (UK - Stublach) instead of the initially planned site of Montoir de Bretagne (France), for facilities in England for the regular use of drones.

Storengy owns and operates the Stublach Gas Storage Facility located in Cheshire near the town of Northwich.

Natural gas is stored over 500 metres below the surface in salt caverns. The salt caverns are formed by pumping water into ground (solution mining) to dissolve the salt to create a large underground chambers connected to the surface by a series of metal tubes cemented into the overlying rock.

Gas is withdrawn from the national transmission system (network of underground pipes crossing the UK) and stored in the salt caverns until it required by our customers. A gas compression station is located on the Stublach site to move the gas in and out of the caverns.

Once fully developed, Stublach will be the largest onshore gas storage facility in the UK and will enhance the security of gas supplies to the UK. The 450 million cubic metres of gas stored a Stublach is enough to supply 270,000 homes with gas for cooking and heating for 12 months.

Figure 31: Stublach Gas Storage Facility

The Stublach site consist of 3 types of separate areas:

• One Main plant;

• Some well pads;

• Meadows and cultivated fields in which the pipelines are buried. The Stublach site short overview:

• 420 Hectare Site Farmland – Livestock;

• 400 million cubic metres of working Gas Volume;

• Inject or Withdraw up to 30 million cubic metres of gas per day;

• Twenty caverns;

• Pressure 30 to 95 Bars;

• Depth 500 m;

• 12 km underground pipe lines.

H2020-ICT-2016-2 – 762013: NRG-5




For ENGIE (Storengy) activity, there are 2 major reasons to use drones for predictive maintenance (and safety):

1. Optimize the manufacturing value stream through new technologies, detecting early failures and saving money. In this way, the use of drones will drive to more often and efficient surveys, accessing areas of difficult access for humans.

2. Recognition of the potential for major accidents to occur from its operations and is committed to providing a high level of protection to its employees and contractors. In this way, the use of drones becomes evident to minimize the risks during human interventions in sensitive areas.

The NRG-5 UC2 objective is to perform drones real-time video analysis to extract risks and associated alarms and to engage all the information and decision chain up to control the drone automatically and remotely. To reach this objective, a reproduction of an xMEC is going to be in place. This xMEC is composed by a server, a Wi-Fi access point, and connection ports, for internet connection and control room connection. The internet connection may be used to remote control the drone from another place.

This trial set up would be based on the results of NRG-5 Task 4.3 [Drones Integration & Validation] where the systems will be tested in a laboratory environment and will detect any need or issue previous real trial deployment.

VSAT

Flight Control

+ Sensors

NRG5 remote

control

RF modules WIFI

Camera

Thermal, HD

Predictive Maintenance as a Service

vMPA

vDFC

DRONE modules

TRIAL PERIMETER Simulation of Remote Equipment s

Internet

Server

API Console

Server

Sat ComSat Com

Remote

Control Unit

Figure 32: Overview of the components involved in UC2

H2020-ICT-2016-2 – 762013: NRG-5



Figure 33: Workflow of a PMaaS scenario [8]

H2020-ICT-2016-2 – 762013: NRG-5






<1000

2 Mobility > 50 (fast moving vehicles)

3 Infrastructure Macro cell coverage

4 Traffic type Continuous

Burst

5 User Data Rate (Mbps) 100 ÷ 1000 (≥ 1000 very high)

6 Latency (ms) 1 ÷ 10 (alarms) > 50 (video)




In order to prepare the trial demonstration, the VNFs have to be deployed at the reproduced xMEC evaluating their ability to real-time analyse the videos sent from the drone and the self-control of the drone from the results of the video analysis. As well as functionalities already identified in D3.2, the installation of related HW/SW equipment is done according to the context. Regarding this PMaaS case, the lack of good infrastructures to rely on forces us to emulate the xMEC in place for completing the real testing. This xMEC emulation has the following components:

- Laptop acting as a server for the xMEC core, having a GPU processing unit;

- Access point acting as a wireless connection to the drone from the xMEC;

- Switch acting as external connectivity for the xMEC.

Other equipment needed for the trial are:

- The drone itself, charged and ready to fly;

- The drone control unit, as an emergency control for the drone in case of the vDFC failure;

- A laptop to act as a client to be able to access the vDFC and vMPA, see the video and control the

drone;

- Satellite modem to connect through the satellite link, as a backup and backbone down or

catastrophe link.

H2020-ICT-2016-2 – 762013: NRG-5



During the UC preparation, the following requirement will be fulfilled:

- Drone shall be compliant with their environment and local regulation.

Three main triggering events can be identified as the starting point of the UC2:

- Scheduled maintenance work by pre-planned flight;

- The surveillance manager goes to an area to do an unscheduled maintenance work;

- An emergency on the plan area where the drone is launched to get what it the emergency, impact

and how to do the intervention.

The PMaaS may validate the following requirements:

- The VNF shall be able to drive the drone among common maintenance paths for multiple and

autonomous failure detection;

- The drone shall cover a wide range of installations within the plant;

- The VNF shall be able to allow drone remote controlled;

- The VNF shall have autonomous functionalities for drone diving;

- The VNF shall be able to capture data from the drone sensors, as well as flight data from the drone

and transmit it in real time to control centre.

The UC sequences can be split within the three main triggering events.

Scheduled maintenance work by pre-planned flight. In a planned way, by setting predefined maintenance paths having in mind the weakest parts of the plant. The drone battery has to be charged, so having spare replacement batteries ready to go is highly recommended. The drone is placed in the take-off location and the VNFs are started. After few seconds, the whole system is ready to fly. Drone automatically drive through the predefined path and video is sent to the control room. If anything is detected among the predefined alarms developed in D3.2, an alarm is raised and the drone change automatically the flight mode to loiter around the detected area to take more detailed images. The surveillance manager, who is watching the video, decides if the alarm is of not a false alarm and get more details from the detailed video. The drone finishes the pre-defined path going back to the launch point.

The surveillance manager goes to an area to do an unscheduled maintenance work. In an unplanned way, the drone fly to wherever the surveillance manager wants. The drone battery has to be charged, so having spare replacement batteries ready to go is highly recommended. The drone is placed in the take-off location and the VNFs are started. After few seconds, the whole system is ready to fly. Surveillance manager send the drone to the location in map where to get detailed images to coordinate an intervention if needed in case one of their sensors detect an anomaly. Drone goes back to the launch point.

An emergency on the plan area where the drone is launched to get what it the emergency, impact and how to do the intervention. In an unplanned way, the drone fly to survey the area where the emergency status is. The drone battery has to be charged, so having spare replacement batteries ready to go is highly recommended. The drone is placed in the take-off location and the VNFs are started. After few seconds, the whole system is ready to fly. Surveillance manager send the drone to the location in map where to get detailed images to coordinate an intervention. Drone goes back to the launch point.

H2020-ICT-2016-2 – 762013: NRG-5




Drone with HD camera

Drone description:

• Manufacturer/Model: Custom, Open Hardware;

• Diameter: ~650 mm;

• Autonomy: 30 min;

• Camera: HD 720p;

• Weight: 3.5 Kg;

• Coverage: 2 Km;

• Wireless control: WiFi 2,4 / 5 GHz + 868MHz RF backup.

Drone with thermal camera

For the Thermal video’s, it will be used the drone provided by the local maintenance team of Storengy Stublach. Drone control system vDFC is not engaged for this case as remote control is not possible with this drone. Although, it engages the video capture during flights and the analyse by vMPA software.

Drone description:

• Manufacturer/Model: DJI Inspire 1 [15];

• Autonomy: 18 minutes’ battery flight time;

• Camera: Thermal Imaging Camera FLIR XT;

• Weight: 2953G.

Figure 34: Drone with thermal camera

H2020-ICT-2016-2 – 762013: NRG-5



Flight Controller

The flight of the drones will be managed by the flight controller Pixhawk 2.1 [16], a flexible autopilot intended primarily for manufacturers of commercial systems. It is based on the open FMUv3 hardware project of the Pixhawk project and runs PX4 [17] or Ardupilot [18] on the NuttX operating system. The controller is designed to be used with a domain-specific carrier board in order to reduce the wiring, improve reliability, and ease of assembly.

Pixhawk description:

• Processor: 32bit STM32F427 Cortex-M4F® core with FPU (168 MHz / 252 MIPS);

• RAM: 256 KB;

• Flash Memory: 2 MB (fully accessible);

• Failsafe Co-Processor: 32 bit STM32F103.

Figure 35: Pixhawk 2.1 flight controller

Local hardware platform

Server local site details:

• CPU: i7 8th gen;

• GPU: GTX1060 6Gb;

• HDD: SSD 512Gb;

• RAM: 16Gb DDR4;

• S.O.: Ubuntu 16.04 LTS.

H2020-ICT-2016-2 – 762013: NRG-5



Server remote site details:

• CPU: i7 8th gen;

• GPU: GTX1060 6Gb;

• HDD: SSD 512Gb;

• RAM: 16Gb DDR4;


Laptop details:

• CPU: i5;

• HDD: 512Gb;

• RAM: 8Gb DDR4;


Satellite ground station details:

• Antenna: VSAT 1.2 m diameter;

• BUC: 6 W;

• Modem: iDirect X7.

WiFi Access point: an AP should be connected to the local site server in order to access the drone.

Router: a router should be connected to the WiFi AP to let the AP get internet access.

Ideally should be able to connect to it from the surveillance room of the plant, so surveillance personal can connect to the server in order to get images, video analysis and drone control. So server local and remote (surveillance room are connected).

Access networks

Internet access: Stublach partners will provide 2 external internet access via optical fiber, these access permit to simulate the interconnexion with remote vDFC and vMPA which shall be remote located in the final NRG5 configuration.

The VSAT connect the local server with the remote server (surveillance room), so in case the normal link is broken, a backup connectivity is still working, even if the delay is high.

Regarding drone control wireless technology, refer to drone description section.

H2020-ICT-2016-2 – 762013: NRG-5




In the Stublach Pilot site, the software, in addition to the VNFs, that will handle the entire flow of the UC2:

• OSM installation;

• OpenStack, running under version Ocata;

• Drone platform (Ardupilot, loaded into flight controller Pixhawk 2.1).

VNFs

General Core VNFs:



General Applications VNFs:

• vMPA: virtual Media Processing & Analysis;

• vDFC: virtual Drones Flight Control.


• Media processing alert API;

• Drone telemetry information API.

H2020-ICT-2016-2 – 762013: NRG-5



4 Conclusions The NRG-5 Trials Set-up described in this deliverable provides the basis for the validation of the AMI as a Service, the PM as a Service and the DDR as a Service in the NRG-5 pilots.

Following the laboratory validations of the NRG-5 integrated prototypes, which are described firstly in D4.3 [1] and will be described lastly in D4.4 [19], the new 5G-NORM prototypes will be placed in Terni to support the operations in the smart grid in real time, allowing the evaluation of decentralized, trusted lock-in free plug 'n' play capability, while electric vehicles and charging stations will be used for energy grid stability and resilience, enabling the validation of uMTC communications along with VNF deployment optimization. In Stublach, drones will be interconnected with the NRG-5 edge routers to validate the NRG-5 proof of concept demonstrator by monitoring ENGIE gas critical infrastructure.

Finally, the measurements collected from the trials will be gathered, analysed and compared with historical data, so as to understand the performance of the NRG-5 ecosystem and validate the energy “vertical” 5G KPIs, demonstrating that 5G will enable massive capacity, zero delay, faster service development, elasticity and optimal deployment, less energy consumption, enhanced security, privacy by design and connectivity to billions of devices with less predictable traffic patterns.

H2020-ICT-2016-2 – 762013: NRG-5



5 Acronyms

Acronym Description

HV High Voltage

MV Medium Voltage

LV Low Voltage

RES Renewable Energy Sources

DER Distributed Energy Resources

DR Demand Response

LNG Liquefied Natural Gas

RAT Remote Access Terminal

SCADA Supervisory Control And Data Acquisition

AMI Advanced Metering Infrastructure

EV Electric Vehicle

EVSE Electric Vehicle Supply Equipment

V2G Vehicle To Grid

DC Direct Current

AC Alternate Current

PV Photovoltaic

BoEU Block of Energy Unit

NORM New-generation Open Real time smart Meter

GSM Global System for Mobile Communication

DSO Distribution System Operator

TSO Transmission System Operator

MTC Mobile Telecommunications Company

H2020-ICT-2016-2 – 762013: NRG-5



MEC Mobile Edge Computing

xMEC Extended Mobile Edge Computing

SM Smart Meter

SMG Smart Meter Gateway

PMU Phasor Measurement Unit

AMIaaS Advanced Metering Infrastructure as a Service

VNF Virtual Network Function

DaaS Dashboard as a Service

MaaS Marketplace as a Service

vTSD Virtual Terminals Self-Discovery

vSON Virtual Self-Organizing Networks

vMME Virtual Mobility Management Entity

vMCM Virtual Machine-Cloud-Machine

vBCP Virtual Blockchain Processing

vAAA Virtual Authentication, Authorization, Accounting

vPMU Virtual Phasor Measurement Unit

vESR Virtual Electricity Substation & Rerouting

vRES Virtual Renewable Energy Sources

vDES Virtual Distributed Energy Storage

HW Hardware

SW Software

API Application Programming Interface

AMQP Advanced Message Queuing Protocol

DB Database

RBAC Role Based Access Control

H2020-ICT-2016-2 – 762013: NRG-5



SMX Smart Meter Extension

SLAM Smart Low-cost Advanced Meters

PUF Physical Unclonable Function

CPU Central Processing Unit

HDD Hard Disk Drive

RAM Random Access Memory

S.O. Operating System

DDRaaS Dispatchable Demand Response as a Service

PMaaS Predictive Maintenance as a Service

SoC State of Charge

STaaS Storage as a Service

VPP Virtual Power Plant

NEDC New European Driving Cycle

MID Measuring Instruments Directive

RFID Radio-Frequency Identification

TFT Thin Film Transistor

OBD On-Board Diagnostic

TCP Transmission Control Protocol

IP Internet Protocol

SIM Subscriber Identity Module

UMTS Universal Mobile Telecommunications System

ASCII American Standard Code for Information Interchange

CAN Controller Area Network

JSON JavaScript Object Notation

ARM Advanced RISC Machine

H2020-ICT-2016-2 – 762013: NRG-5



ACC Analogic Command Control

DCC Digital Command Control

NS Network Simulator

HTPP HyperText Transfer Protocol

GPU Graphics Processing Unit

HD High Definition

RF Radio Frequency

SSD Solid-State Drive

AP Access Point

uMTC ultra-reliable Machine Type Communications

KPI Key Performance Indicator

H2020-ICT-2016-2 – 762013: NRG-5



6 References

[1] H2020 NRG-5 project, “D4.3: Intermediate NRG-5 laboratory validation,” 2019.

[2] SUCCESS, H2020 project, http://success-energy.eu/.

[3] I. A. f. E. E. (ARERA), “298/2016/R/eel PRIMA FASE DELLA RIFORMA DEL MERCATO PER IL SERVIZIO DI DISPACCIAMENTO: APERTURA ALLA DOMANDA, ALLE FONTI RINNOVABILI NON PROGRAMMABILI E ALLA GENERAZIONE DISTRIBUITA,” 2016.

[4] “DIRECTIVE (EU) 2018/2001 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 December 2018 on the promotion of the use of energy from renewable sources”.

[5] H2020 NRG-5 project, “D1.1: Use Case scenarios analysis and 5G requirements,” 2018.

[6] M. Sanduleac, G. Lipari, A. Monti, A. Volukidis, G. Zanneto, A. Corsi, L. Toma, G. Fiorentino, D. Federenciuc;, “Next generation real-time smart meters for ICT based assesment of grid data inconsistencies,energies 2017,10(7),857”.

[7] H2020 NRG-5 project, “D3.2: NRG-5 Application logic framework,” 2018.

[8] H2020 NRG-5 project, “D1.3: Final 5G Network Architecture to Support Smart Energy,” 2018.

[9] SUCCESS, “H2020 SUCCESS D3.7 Next Generation Smart Meter v1.0,” [Online]. Available: https://success-energy.eu/files/success/Content/Library/Deliverables/700416_deliverable_D3_7.pdf.

[10] NOBEL GRID, H2020 project, http://nobelgrid.eu/.

[11] RENAULT, “ZOE Technical Specification,” 2018. [Online]. Available: https://www.renault.co.uk/vehicles/new-vehicles/zoe.html.

[12] NISSAN, “LEAF Technical Specification,” 2018. [Online]. Available: https://www.nissan.co.uk/vehicles/new-vehicles/leaf.html.

[13] ELSA, H2020 project, https://www.elsa-h2020.eu/.

[14] EFACEC, “QC45 Technical Specifications,” 2016. [Online]. Available: http://electricmobility.efacec.com/wp-content/uploads/2016/10/CS119I1307D1_QC45.pdf.

[15] DJI, “Inspire 1 Technical Specifications,” [Online]. Available: https://www.dji.com/uk/inspire-1-pro-and-raw/info#specs.

[16] “http://www.proficnc.com/,” [Online].

[17] “https://github.com/PX4/Firmware,” [Online].

[18] “https://github.com/ArduPilot/ardupilot,” [Online].

[19] H2020 NRG-5 project, “D4.4: Final NRG-5 laboratory validation,” 2019.

[20] “H2020 Success project,” [Online]. Available: http://www.success-h2020.eu/ .

[21] G. E. S. a. S. Devadas, “Physical unclonable functions for device authentication and secret key generation,” 2007. [Online]. Available: http://verayo.com/pdf/2007_puf_dac.pdf. [Accessed 25 1 2019].

H2020-ICT-2016-2 – 762013: NRG-5



[22] B. F. K. I. a. R. K. C. M. Spain, “Robust keys from physical unclonable functions,” 2014. [Online]. Available: http://ieeexplore.ieee.org/document/6855575. [Accessed 25 1 2019].

[23] C. H. L. a. D. P. M. BrightSky, “Reliable physical unclonable function for device authentication,” 2013. [Online]. Available: https://patents.google.com/patent/us8741713b2/en. [Accessed 25 1 2019].

[24] M. E. M. T. L. B. P. Sanduleac, “Integrating the Electrical Vehicles in the Smart Grid through Unbundled Smart Metering and multi-objective Virtual Power Plants,” in IEEE PES 2011 2nd IEEE PES International Conference and Exhibition on Innovative Smart Grid Technologies (ISGT Europe), Manchester, 5-7 December 2011.

[25] “H2020 Nobel Grid project,” [Online]. Available: www.nobelgrid.eu.

[26] A. T. Z. K. W. S. M. B. M. D. Mohammad Mozaffari, “Beyond 5G with UAVs: Foundations of a 3D,” 2 November 2018. [Online]. Available: https://arxiv.org/pdf/1805.06532.pdf.

[27] H2020 NRG-5 project, “Deliverable D1.1: Use Case scenarios analysis and 5G requirements,” 2017.

[28] H2020 NRG-5 project, “Deliverable D3.2: NRG-5 application logic framework”.

[29] “RENAULT, “ZOE Technical specification”, 2018,” [Online]. Available: https://www.renault.co.uk/vehicles/new-vehicles/zoe.html.

[30] “NISSAN, “LEAF Technical specification”, 2018,” [Online]. Available: https://www.nissan.co.uk/vehicles/new-vehicles/leaf.html.

[31] “Gestore Servizi Energetici (GSE), “Rapporto delle attività 2017”, 2018 March 21,” [Online]. Available: https://www.gse.it/documenti_site/Documenti%20GSE/Rapporti%20delle%20attivit%C3%A0/GSE_RA2017.pdf.

[32] “Navigant Research, “Transportation Forecast: Light Duty Vehicles”, 2017,” [Online]. Available: https://www.navigantresearch.com/reports/transportation-forecast-light-duty-vehicles.

[33] ETSI, “OSM,” [Online]. Available: https://osm.etsi.org/.

[34] H2020 NRG-5 project, “Deliverable D4.2: Integration Guidelines & Open DMP v2,” 2018.

[35] “Gitlab pipelines,” [Online]. Available: https://docs.gitlab.com/ee/ci/pipelines.html.

[36] “https://github.com/PX4/Hardware,” [Online].

[37] “https://github.com/ArduPilot/ardupilot,” [Online].

[38] “https://github.com/PX4/Firmware,” [Online].

[39] “NOBEL GRID, H2020 project,” [Online]. Available: http://nobelgrid.eu/.

[40] H2020 NRG-5 project, “Deliverable D2.2: NRG-5 Virtual Network abstraction,” 2018.

[41] “OpenDSS,” [Online]. Available: http://smartgrid.epri.com/SimulationTool.aspx.

[42] G. E. Suh and S. . Devadas, “Physical unclonable functions for device authentication and secret key generation,” , 2007. [Online]. Available: http://verayo.com/pdf/2007_puf_dac.pdf. [Accessed 25 1 2019].

H2020-ICT-2016-2 – 762013: NRG-5



[43] M. . Spain, B. . Fuller, K. . Ingols and R. K. Cunningham, “Robust keys from physical unclonable functions,” , 2014. [Online]. Available: http://ieeexplore.ieee.org/document/6855575. [Accessed 25 1 2019].

[44] M. . BrightSky, C. H. Lam and D. . Pfeiffer, “Reliable physical unclonable function for device authentication,” , 2013. [Online]. Available: https://patents.google.com/patent/us8741713b2/en. [Accessed 25 1 2019].

[45] RASPBERRY PI FOUNDATION, “Raspberry Pi 3 Model B,” [Online]. Available: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/.

[46] H2020 NRG-5 project, “Deliverable D1.2: Reference Architecture & Functional Decomposition,” 2018.

[47] H2020 NRG-5 project, “Deliverable D1.3: Final 5G Network Architecture to support smart energy ,” 2019.

[48] H2020 NRG-5 project, “Deliverable D2.3: 5G trusted, scalable & lock-in free plug' n' play,” 2019.

[49] H2020 NRG-5 project, “Deliverable D2.1: NRG-5 Low-Layer Networking VNFs,” 2018.

[50] Taih ́u Pire, Thomas Fischer, Gaston Castro, Javier Civera, Julio Jacobo Berlles, “S-PTAM: Stereo Parallel Tracking and Mapping,” 2017. [Online]. Available: http://webdiis.unizar.es/~jcivera/papers/pire_etal_ras17.pdf.

[51] F. e.V., “VILLASnode,” [Online]. Available: https://www.fein-aachen.org/projects/villas-node/. [Accessed 08 12 2018].

[52] F. e.V., “VILLASframework,” [Online]. Available: https://www.fein-aachen.org/projects/villas-framework/. [Accessed 08 12 2018].

[53] F. e.V., “VILLASweb,” [Online]. Available: https://www.fein-aachen.org/projects/villas-web/. [Accessed 08 12 2018].

deliverable 5.1 nrg-5 trials set-up

Documents