Ref.

Ares(2020)1416866 - 06/03/2020
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

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-762013

Enabling Smart Energy as a Service via 5G Mobile Network

advances

Deliverable 4.2
Integration Guidelines & Open DMP v2
Author(s): RWTH, POPs
Status -Version: Final
Delivery Date (DOW): 30th November 2018
Actual Delivery Date: 06 March 2020
Distribution - Confidentiality: Public
Code: 10.5281/zenodo.1240277
Abstract:
This document is the updated version of D4.1, which includes the NRG-5 Data Management Plan (DMP)
and the Integration Guidelines. The document is due in project month M18. After that, it will be
maintained as a living document.
In particular, this deliverable provides a description of data management in the project, identifies different
data sets including data security and privacy aspects. The expected data to be used and generated in
the project is categorized by datasets and organized in factsheets. A detailed description of filetypes
used in the project is reported in this document. A description of the different Virtual Network Functions
and Application logic metadata takes place, reflecting the questions asked by the DMP. The different
aspects of making data Findable, Accessible Interoperable and Re-usable (FAIR) are discussed.
In the second part of this document, software integration infrastructure, techniques for software quality
assurance and general best practices used in NRG-5 are described. The focus is set on continuous
integration and continuous delivery of the software developed in the project, which as a result will
decrease the time between development and deployment or update on the target system. Deployment
and integration recipes, used in NRG-5, are also presented in this deliverable.

© The NRG-5 consortium partners, 2017 1

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

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:

Participant Short
Participant organisation name Country
number name
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 SI 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 Sorbonne Université SU France
18 Centro Romania Energy CRE Romania
19 Rutgers State University of New Jersey Rutgers USA

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.

© The NRG-5 consortium partners, 2017 2

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Document Revision History

Date Issue Author/Editor/Contributor Summary of main changes
16/05/18 0.1 M. Ginocchi D4.1 review for the preparation
of 1st version of D4.2
22/05/18 0.2 M. Ginocchi Integration of the inputs from
all partners for DMP datasets
21/08/18 0.3 M. Ginocchi Enrichment of the “File type
description” with all the data
formats not described in D4.1
23/08/18 0.4 M. Ginocchi Addition of tables for VNF and
source code descriptions
02/11/18 0.5 A. Voulkidis Enhancement of Chapters 3
and 5 – Integration Guidelines
16/11/18 0.6 M. Pitz Enrichment of the content.
19/11/18 M.R. Spada, C. Fortuna Peer revision
28/02/20 1.0 M. Pitz, G. Lipari Addressed comments from
final project review

© The NRG-5 consortium partners, 2017 3

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Table of Contents
1 Introduction __________________________________________________________________ 8
2 Data Management Plan ________________________________________________________ 9
2.1 Introduction ______________________________________________________________________________ 9
2.2 Data Summary ____________________________________________________________________________ 9
2.2.1 List of datasets .............................................................................................................................................. 9
2.2.2 Topology and asset description .................................................................................................................. 11
2.2.3 Video recordings / CCTV .............................................................................................................................. 13
2.2.4 Measurement data ..................................................................................................................................... 15
2.2.5 Log and access data .................................................................................................................................... 17
2.2.6 Prediction, forecast and planning data ....................................................................................................... 19
2.2.7 Positioning and location data ..................................................................................................................... 21
2.2.8 Codes........................................................................................................................................................... 22
2.2.9 Configuration and Orchestration data ........................................................................................................ 22
2.2.10 File type description .................................................................................................................................... 24
2.2.11 Description of the software products .......................................................................................................... 33
2.3 FAIR data ________________________________________________________________________________ 41
2.3.1 Findable data .............................................................................................................................................. 41
2.3.2 Accessible data ........................................................................................................................................... 42
2.3.3 Interoperable data ...................................................................................................................................... 43
2.3.4 Re-usable data ............................................................................................................................................ 43
2.4 Allocation of resources _____________________________________________________________________ 43
2.5 Data security _____________________________________________________________________________ 44
2.6 Ethical aspects____________________________________________________________________________ 44

3 Integration Guidelines_________________________________________________________ 46
3.1 Introduction _____________________________________________________________________________ 46
3.2 Software ________________________________________________________________________________ 46
3.2.1 Conventions ................................................................................................................................................ 46
3.2.2 What is CI/CD .............................................................................................................................................. 48
3.2.3 Integration of VNFs ..................................................................................................................................... 52

4 References __________________________________________________________________ 54
5 Annex ______________________________________________________________________ 56
5.1 Python web service docker deployment _______________________________________________________ 56
5.2 Python web service direct installation with testing ______________________________________________ 57
5.3 Java web service served by Tomcat ___________________________________________________________ 58
5.4 Generic VNF update _______________________________________________________________________ 58
5.4.1 The NRG-5 CI/CD framework ...................................................................................................................... 64

© The NRG-5 consortium partners, 2017 4

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Table of Figures

Figure 1: Principle CI/CD [42] _____________________________________________________________________________ 49

Figure 2: Continuous integration infographic (source: [45]). _____________________________________________________ 51
Figure 3: Indicative GitLab pipeline graph (source: [47]). _______________________________________________________ 51
Figure 4: View of the NRG-5 source code repository at gitlab.com. _______________________________________________ 52
Figure 5: CI/CD template for deploying a Python web service in a packaged in a docker container. _____________________ 57
Figure 6: Setting the required variables at the CI/CD settings of the GitLab project. __________________________________ 61
Figure 7: CI/CD job logs. _________________________________________________________________________________ 62
Figure 8: Depiction of the CI/CD job running on a private GitLab Runner instance. ___________________________________ 63
Figure 9: OpenStack dashboard indicating the successful creation of the VNF snapshot. ______________________________ 63
Figure 10: GitLab CI/CD job being successfully conducted. ______________________________________________________ 64
Figure 11: The file and directory structure of the project. _______________________________________________________ 65

© The NRG-5 consortium partners, 2017 5

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

List of Abbreviations
5G-PPP 5G Infrastructure Public Private Partnership
AMIaaS Advanced Metering Infrastructure as a Service
API Application Programming Interface
ATEX ATmosphères EXplosibles EU directive 99/92/EC or 94/9/EC
CCTV Closed Circuit Television
CD Continuous Delivery
CERN European Organization for Nuclear Research
CI Continuous Integration
DC Data Centre
DevOps Development and Operations
DMP Data Management Plan
DOI Digital Object Identifier
DR Demand Response
DDRaaS Dispatchable Demand Response as a System
EU European Union
EV Electric Vehicle
EVSE Electric Vehicle Supply Equipment
FIT Future Internet Testing Facility
IG Integration Guidelines
NFV Network Function Virtualization
NORM Next generation Open Real-time Meter
NS Network Service
PMaaS Predictive Maintenance as a Service
PMU Phasor Measurement Unit
REST Representational State Transfer
SDN Software defined network
UC Use Case
uMTC Massive Machine Type Communication
uRLLC Ultra Reliable and Low Latency Communication
VNF Virtual Network Function
VNFFP Virtual Network Functions Forwarding Path
VNFFG Virtual Network Functions Forwarding Graph
xMEC extended Mobile Edge Cloud
© The NRG-5 consortium partners, 2017 6
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

© The NRG-5 consortium partners, 2017 7

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

1 Introduction
The handling of data by means of different data types, restriction for privacy and openness is an
important part of projects with multiple partners. If there is software development involved in the project,
then the project partners need to clarify how - and according to which coding standards - they intend to
develop software. Both aspects are considered in this document. Chapter 2 will be the Data
Management Plan (DMP), while Chapter 3 will contain Integration Guidelines (IG), where a further
discussion regarding the software aspects is provided.

The DMP is a formal description of the procedures of data handling during and after a project. By
providing an assessment of data used in a project and a structured approach for aspects such as
naming conventions, metadata and versioning, the DMP should also support data quality, efficient
processing and sharing of data. This is required for projects in the Horizon 2020 framework program,
which have not opted out of the Open Research Data Pilot [1].

The IG are a description on how the developers of the different partners are developing and handling the
source code. In a modern development environment, continuous integration plays a major role to support
the developer with automated code testing and deployment. To make transfer and reusability easier for
the partners but also for possible third-party users, the partners have to agree on the IG on a formal
level.

Naturally, not all questions regarding the handling and type of data and source code can be answered at
the first stages of a project, as procedures have to be coordinated and implemented and the
infrastructure has to be set up. To meet this lack of knowledge, the entire deliverable is meant to be a
living document, which should be adapted and completed during the project lifetime. The first document
version has been released in deliverable D4.1 “Open Data Management Plan & Integration Guidelines
V1” in M06. The present document, “Integration Guidelines & Open DMP v2”, is an updated version of
D4.1.

© The NRG-5 consortium partners, 2017 8

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2 Data Management Plan

2.1 Introduction
Chapter 2 is structured according to Annex 1 of the “Guidelines on FAIR Data Management in Horizon
2020” [1]. Data appearing in the NRG-5 project are assessed in Section 2.2 and structured in datasets.
In Section 2.3, the approach towards making data “FAIR” (Findable, Accessible, Interoperable, Re-
usable) is described in regard to the tools, conventions and procedures to be used in NRG-5. The
allocation of resources for making the data “FAIR” is explained in Section 2.4.

2.2 Data Summary

Within NRG-5, there will be trials conducted by different project partners. One of the trials will test drone
behaviour in a swam and offloading of video processing to the edge cloud. This trial will take place at
Pilot#1, which will be a Natural Gas network/LNG Terminal provided by ENGIE [2]. At the second trial
site, the integration of smarter energy and 5G will be tested. This trial will take place a Pilot#2: Optimized
Energy Network Management and Control (Italy) [3]. Besides these trials, there will be software
development, testing and simulation done by different project partners. Since data to be collected and
generated in the NRG-5 project are highly heterogeneous, in Chapter 2.2 they are differentiated in
datasets. Structuring by datasets allows for a detailed assessment of the data collection and generation
as well as issues of data privacy and security. To assess the data, each dataset is described in a fact
sheet, following a sub-division in datatypes.

2.2.1 List of datasets

The following datasets have been identified to appear in the NRG-5 project and will be described in more
detail in the following subchapters. Since this document is considered a living document, changes or
additions may be made later on and the information about the datasets is not necessarily complete.
Each table (fact sheet) is divided into two parts. First, there is a generic description and an example for
the dataset, together with general security and privacy considerations. Then, the dataset specific for that
fact sheet is divided into datatypes. This sub-division should take into account the diversity of data
generated during the project. With that information, the DMP can identify the potential of data generated
by a partner even if another partner is generating the same data from a different source. This
terminology is flexible in adding datasets, datatypes or a new partner who is generating the same kind of
data but with different content.
The generic information in the datasets is based on the Grant Agreement. The content for the dataset is
based on either the Grant Agreement or information gathered from the project partners.

© The NRG-5 consortium partners, 2017 9

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Dataset 1: Topology and asset description

IT System topology data
Terrain map files
Charge point description
FIT infrastructure
Dataset 2: Video recordings / CCTV
Drone video material
Drone recording still images
Dataset 3: Measurement data
Voltmeter/Current meter/Custom recordings
NORM data
Dataset 4: Log and access data
Alarm and heartbeat Logs
System Logs
Network Traffic Logs
Dataset 5: Prediction, forecast and planning data
Flight planning data
Power exchange data
Demand response data
Energy or Power forecast of PV generation
Dataset 6: Positioning and location data
GPS position data
Dataset 7: Codes
Source codes
Dataset 8: Configuration and Orchestration data
Configuration files
Management data

© The NRG-5 consortium partners, 2017 10

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.2 Topology and asset description

Fact sheet Dataset 1

Dataset name Topology and asset description
Dataset description The topology and asset description includes plans and documentation about
assets and equipment. The description of network topologies of electrical, gas
and other energy distribution grids is included. In addition, the topologies of IT
networks wired and non-wired are included.

General security and privacy considerations

Information about critical infrastructure may need to be handled confidentially so the security of that
infrastructure cannot be compromised. Further assessments of the data is needed, before taking a
decision about making it public and to which extent.

Datatype specific answers

Datatype name IT system topology data
Data description This data describes the IT infrastructure of a facility, including the
hardware specifications.
Purpose of the data Information about the available resources and their performance is needed
for dynamic NFV resource allocation.
Relation to project In the project, there will be an automated way for the allocation of
objective computational resources.
File types .json
(Data provider) Origin Size (xByte) Access for Partners Access for the public
of the data
Information about kBs Access will be provided, if Restricted, only available to
hardware infrastructure needed for the project application context.
for CI/CD will be objectives.
provided
Information about the kBs Access will be provided, if Restricted, only available to
used SDN infrastructure needed for the project application context.
will be provided objectives.

Datatype name Terrain map files

Data description This data describes facilities topology (e.g. substations)
Purpose of the data For automated drone flights, information about the facilities and the terrain
is needed.
Relation to project Part of the project is to do maintenance of drone flights at trial sites with
objective autonomous drones.
File types .map, .jpg, .kml, .kmz
(Data provider) Origin Size (xByte) Access for Partners Access for the public
of the data
A ground floor map of MBs to 1 GB Access will be provided, if The facility is critical
Pilot#1 will be provided needed for the project infrastructure therefore the
objectives. data cannot be made public

© The NRG-5 consortium partners, 2017 11

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

A map with information MBs to 1 GB Access will be provided, if The facility is critical
about industrial needed for the project infrastructure therefore the
structures e.g. buildings, objectives. data cannot be made public
energy lines, pylons of
Pilot#1.
Information about MBs to 1 GB Access will be provided, if The facility is critical
forbidden zones, public needed for the project infrastructure therefore the
or industrial restrictions objectives. data cannot be made public
(e.g. ATEX zones) at
Pilot#1 will be provided.

Datatype name Charge point description

Data description This data describes EVSE status
Purpose of the data EMOT goal is to optimize the electric power consumption of the EV’s
charging point using energy from renewable sources
Relation to project Test the 5G network through an electric mobility service
objective
File types .json
(Data provider) Origin Size (xByte) Access for Partners Access for the public
of the data
Information about web Some KBs Access will be provided, if The data will not be made
service infrastructure at needed for the project public
Pilot#2 will be provided. objectives.
Information about the Some KBs Access will be provided, if The data will not be made
charge point needed for the project public
infrastructure at Pilot#2 objectives.
will be provided.
A map of charging Some MBs Access will be provided, if The data will not be made
station at Pilot#2 will be needed for the project public
provided. objectives.

Datatype name FIT infrastructure

Data description This data describes the FIT infrastructure
Purpose of the data For performance and correctness evaluation
Relation to project It will be used to validate the NRG-5 IoT requirements, namely M2M and
objective MCM communications, xMEC efficiency, self* VNFs using constrained
devices and moving IoT nodes and sensors.
File types .txt, .csv, .jpg
(Data provider) Origin Size (xByte) Access for Partners Access for the public
of the data
(SU) will provide Some KBs All the partners have access SU promotes the open
information about their to the data access data policy.
FIT infrastructure

© The NRG-5 consortium partners, 2017 12

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.3 Video recordings / CCTV

Fact sheet Dataset 2
Dataset name Video recordings / CCTV
Dataset description Video recordings of landscape in the visible spectrum.
Security and privacy considerations
Video and image data recorded by a drone can contain information, which has to be assessed from a
privacy but also a security point of view.
Datatype specific answers
Datatype name Drone video material
Data description Video material gathered during drone flights
Purpose of the data Video and still images are needed to test the implementation of drone
path planning algorithms and to do the on-fly path planning. To analyse
the results of the flight trial, the video material can be of benefit too.
Relation to project The offloading of image data from a drone, to do path planning on a cloud
objective system is part of the NRG-5 project. To do so, video or image data need
to be acquired and then transferred.
File types .mpeg, .mkv, .avi
(Data provider) Origin of Size (xByte) Access for Access for the public
the data Partners
(VIS) Video recordings Minimum per 10min All the partners have Selected videos could be
from a drone perspective flight: access to the data made public.
will be made at Pilot#1
~600MB @ 720p Videos of critical zones
cannot be made public.
~1,5GB @ 1080p
~3,5GB @ 4K
(VIS) Video recordings of Minimum per 10min All the partners have Selected videos could be
the drone from a ground flight: access to the data made public.
perspective at Pilot#1
~600MB @ 720p Videos of critical zones
cannot be made public.
~1,5GB @ 1080p
~3,5GB @ 4K

Datatype name Drone recording still images

Data description Still images extracted out of video recordings
Purpose of the data To analyse and document the flight behaviour, still images extracted out
of video recordings are needed
Relation to project After flight, analysis will be part of the drone trial. To do so, still images of
objective the flight are useful.
File types .jpg, .png, .tif
(Data provider) Origin of Size (xByte) Access for Access for the public
the data Partners
Still images from the Minimum per All the partners have Selected videos could be

© The NRG-5 consortium partners, 2017 13

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

drone video recording image: access to the data made public.

~150KB @ 720p Videos of critical zones
cannot be made public.
~500KB @ 1080p
~2MB @ 4K
Still images of the drone Minimum per All the partners have Selected videos could be
from a ground perspective image: access to the data made public.
~150KB @ 720p Videos of critical zones
cannot be made public.
~500KB @ 1080p
~2MB @ 4K

© The NRG-5 consortium partners, 2017 14

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.4 Measurement data

Fact sheet Dataset 3
Dataset name Measurement data
Dataset description Data gathered from sensors.
Security and privacy considerations
The combination of the collected information about driving and charging habits, as well as the forecast
information could have an impact on the privacy of the user. Before making this data public, this issue
needs to be addressed.
Datatype specific answers
Datatype name Voltmeter/Current meter/Custom recordings
Data description Voltmeter/Current meter/Custom recordings
Purpose of the data To control the charging behaviour of an EV, it is important to know the
current state of charge of the EV battery, but also the current state of the
power grid. A forecast about the use of the EV and the needed energy,
based on historical information, can also use information about the driving
behaviour.
Relation to project In Pilot#2, multiple EV’s will be controlled in state of charge and the
objective charging schedule. The schedule takes the current state of the power grid
into account. Therefore, it is important to measure the grid state. To
calculate a charging plan it is important to know a forecast of the user’s
behaviour. For that, information about the user’s behaviour needs to be
collected.
File types .csv, .xls, .raw, .json
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Measurements on EV’s at 2 kB/sec Due to the sensitive nature Due to the sensitive nature
Pilot#2 will be done. of the data, available only of the data, they will only be
after request and proper available on application and
statement of purpose. their use, only of their own
data

Information about the 2 kB/sec Due to the sensitive nature Due to the sensitive nature
energy consumption of of the data, available only of the data, they will only be
the EV chargers will be after request and proper available on application and
measured. statement of purpose. their use, only of their own
data

The state of charge of 0.2 kB/sec Due to the sensitive nature Due to the sensitive nature
EV’s will be measured. of the data, available only of the data, they will only be
after request and proper available on application and
statement of purpose. their use, only of their own
data

(SU) Will provide data Hundreds of All the partners have access SU promotes the open
gathered from use of the KBs to the data access data policy.
FIT platform.

© The NRG-5 consortium partners, 2017 15

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Datatype name NORM data

Data description Measurements from grid extracted from NORM
Purpose of the data NORM values are used as processed data for project applications. In
particular, they are needed for the calculation of DR campaign. NORM
values related to frequencies and energy consumption allow the
calculation of baseline needed for issuing DR. Also values from PMU are
useful for energy rerouting policies.
Relation to project These data support VNF functionalities for the project. They allow for the
objective fine tuning of DR algorithm in the use cases and enable also the
Dispatchable Demand Response as a Service (DDRaaS)
File types .csv, .xls, .json
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Data gathered from 2 kB/sec All data acquired by NORM, Due to the sensitive nature
NORM units will be used. subject of privacy data of the data they will only be
consent between end-user available on application and
and site responsible their use, only of their own
data

© The NRG-5 consortium partners, 2017 16

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.5 Log and access data

Fact sheet Dataset 4

Dataset name Log and access data
Dataset description Data which documents the current state or change in state of a system.
Security and privacy considerations
Alarm and logging data can reveal information about critical infrastructure or the behaviour and identity
of users who are connected to the systems storing the alarm and logging data. Therefore, these data
needs to be assessed before a decision about making it public can be taken.
Datatype specific answers
Datatype name Alarm and heartbeat Logs
Data description Log with a history of alarm and heartbeat states from EVs.
Purpose of the data Alarm and heartbeat data is needed for analysis of a systems behaviour
Relation to project EV’s will be smartly connected together. To do so status information (e.g.
objective alarms and heartbeats) about the EV’s are needed.
File types .json
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Alarm data from EV’s will 1 kB/min Access will be provided, if Due to the sensitive nature
be logged. needed for the project of the data they will only be
objectives. available on application and
their use, only of their own
data.
Heartbeat data from EV’s 0.5 kB/min Access will be provided, if Due to the sensitive nature
will be logged. needed for the project of the data they will only be
objectives. available on application and
their use, only of their own
data

Datatype name System Logs

Data description Logs with a history of system states.
Purpose of the data Log data is needed for analysis of a systems behaviour
Relation to project The project will do multiple trials and lab tests. Part of the project is to
objective create and further develop VNF’s. When testing this VNF’s, log files will
be created to analyse the behaviour of the tested function.
File types .csv, .json, .xml
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
System log data from Some MBs All data acquired by NORM, Due to the sensitive nature
EV’s will be stored. subject of privacy data of the data they will only be
consent between end-user available on application and
and site responsible their use, only of their own
data

© The NRG-5 consortium partners, 2017 17

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Log data from trials will be Very large All data acquired by NORM, Due to the sensitive nature
gathered GBs subject of privacy data of the data they will only be
consent between end-user available on application and
and site responsible their use, only of their own
data
(VIS) Log data from Some MBs All data acquired by NORM, Due to the sensitive nature
SDN’s will be used subject of privacy data of the data they will only be
consent between end-user available on application and
and site responsible their use, only of their own
data
(VIS) Access data from Some MBs All data acquired by NORM, Due to the sensitive nature
SDN’s will be used subject of privacy data of the data they will only be
consent between end-user available on application and
and site responsible their use, only of their own
data

Datatype name Network Traffic Logs

Data description Logs of Network traffic including packet raw data
Purpose of the data For an offline analysis of generated or simulated network traffic, a traffic
recording is needed
Relation to project To tune/validate the behaviour of orchestration strategies before actual
objective deployment
File types .pcap
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Network traffic will be In hundreds All data acquired by NORM, Due to the sensitive nature
recorded in trials and lab of MB per subject of privacy data of the data they will only be
tests. trace consent between end-user available on application and
and site responsible their use, only of their own
data

© The NRG-5 consortium partners, 2017 18

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.6 Prediction, forecast and planning data

Fact sheet Dataset 5

Dataset name Prediction, forecast and planning data
Dataset description Data to plan the path of an object. Also included is data with forecast or
schedule character.
Security and privacy considerations
Prediction and forecast data can have an impact on the privacy of individuals and may contain
information that has safety and security implications for project partners. Therefore, it will be made
sure that the personal rights of individuals and the rights of the partners are considered during the
acquisition as well as processing of data. This may result in restricted access to data.
Datatype specific answers
Datatype name Flight planning data
Data description Flight path recorded with GPS position and height to be able to
reconstruct the flight
Purpose of the data After flight, analysis is an essential part of evaluating the flight path
planning algorithm. To do so the actual flight data and path planning data
needs to be recorded.
Relation to project Testing the behaviour of a drone swarm with automated flight path
objective planning is one part of the project. To evaluate the path planning and the
5G performance information about the path planning is important.
File types .kmz, .kml, .gpx
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
(VIS) Planning data from Some MBs Access will be provided, if All the partners have access
drone flights will be needed for the project to the data
stored. objectives.

Datatype name Power exchange data

Data description Power exchange within the charge point depending on the electrical
output
Purpose of the data To manage the power flog in an electrical grid information about the
current state is needed
Relation to project Test the 5G network through an electric mobility service
objective
File types .json
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Information about the 2 kB/min Access will be provided, if Due to the sensitive nature
power exchange within needed for the project of the data they will only be
the charge point will be objectives. available on application and
recorded. their use, only of their own
data

© The NRG-5 consortium partners, 2017 19

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Datatype name DR data

Data description DR signals and available resources for DR
Purpose of the data These data will be both generated and then collected to train the entire
system
Relation to project These data are needed for the calculation of the flexibility needed for the
objective DR
File types .csv, .json
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
DR data from trials and Some KBs Access will be provided, if The data will not be made
lab tests will be stored. needed for the project public.
objectives.

Datatype name Energy or power forecast of PV generation

Data description Energy or power forecast of PV generation
Purpose of the data EV charging plans/vehicle charging demand profile
Relation to project These kind of information is the trigger of UC2
objective
File types .csv
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
EV’s charging plans will Some MBs Access will be provided, if The data will not be made
be stored. needed for the project public
objectives.
EV’s charging demand Some MBs Access will be provided, if The data will not be made
profiles will be stored. needed for the project public
objectives.

© The NRG-5 consortium partners, 2017 20

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.7 Positioning and location data

Fact sheet Dataset 6

Dataset name Positioning and location data
Dataset description EV and drone position tracking
Security and privacy considerations
EV positioning data are not related to a natural person, they are only related to EV-id, but they can
give information about the routes of company fleets or car-sharing fleets and, therefore, can be
restricted and not be made public.
For drone positioning data, subject to Dataset 5. As there would be GPS coordinates, it can be public,
but it may be restricted due to routine inspection paths.
Datatype specific answers
Datatype name GPS position data
Data description GPS position points where EV and drone have been
Purpose of the data Information about the position of facilities or recorded positions of object
movement are needed to navigate
Relation to project To forecast the EV usage information, historic information about the car
objective movement is important. In the drone trials there is a need to know the
locations of facilities to monitor with the drones, but also the information
about the current drone position is essential for the path planning
File types .json, .csv, .xlsx, .kmz, .gpx
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
EV’s geolocalization data Some kBs Access will be provided, if The data will not be made
will be recorded. needed for the project public
objectives
(VIS) Positioning data for Some MBs Access will be provided, if The data will not be made
drones will be recorded. needed for the project public
objectives.

© The NRG-5 consortium partners, 2017 21

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.8 Codes

Fact sheet Dataset 7

Dataset name Source codes
Dataset description Software source codes including build instruction. Their description for each
single VNF/Application Logic is given in Section 2.2.11.
Security and privacy considerations
Different according to each VNF/Application logic. Please refer to Section 2.2.11 for further details.
Datatype specific answers
Datatype name Source codes
Data description Source codes
Purpose of the data To further develop models but also software developed during a project, it
is important to have the source files, but also instructions on how to build
those files to generate a model or a binary.
Relation to project In the NRG-5 project, new VNF’s will be developed. Part of that process
objective is to further develop existing source code or to implement new functions.
The project also aims to make as much information public and open
source as possible. To do so, the developed source code needs to be
stored.
File types .c, .cpp, .h, .py, .java, .html, .js, .css, .sol
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
Source code will be Less than Access will be provided, if Probably most of it could be
stored during 1 GB needed for the project made available as a
development. objectives. platform

2.2.9 Configuration and Orchestration data

Fact sheet Dataset 8

Dataset name Configuration data
Dataset description Configuration data contains parameters that can control the behaviour of a
software, without redeploying or recompiling software packages and/or parts of
a software.
Security and privacy considerations
Configurations might be critical from a partner security perspective. Credentials of users will not be
circulated at no time. Integration credentials will only be shared among integrating parties.
Datatype specific answers
Datatype name Configuration files
Data description Configuration files and login credentials
Purpose of the data Configuration of software components or login data for automated data

© The NRG-5 consortium partners, 2017 22

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

push services
Relation to project Building a CI/CD environment is part of the project. To automatically
objective deliver software, configuration files are needed. Further information about
CI/CD can be found in Section 3.2.2
File types .sh, .json, .xml, .custom1
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
(VIS) Configuration files A few MBs Due to the sensitive nature Due to the sensitive nature
for running software will of the data, they will only be of the data they will not be
be created. available to the pilot partner released to the public
running each trial
(VIS) Credentials for A few MBs Due to the sensitive nature Due to the sensitive nature
different services will be of the data they will not be of the data they will not be
provided. released to all partners but released to the public
rather only to integrating
ones

Datatype name Management data

Data description Management of network and functions.
Purpose of the data Effective scaling and placement configuration
Relation to project Effective scaling and placement configuration
objective
File types .txt
(Data provider) Origin of Size Access for Partners Access for the public
the data (xByte)
(VIS) MANO messages Some MBs Access will be provided, if Available to the public after
will be recorded. needed for the project anonymization
objectives.
(VIS) SDN messages will Some MBs Access will be provided, if Available to the public after
be recorded. needed for the project anonymization
objectives.

© The NRG-5 consortium partners, 2017 23

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.10 File type description

In this paragraph, the file types identified in the previous datasets are described. For every file type a
short description is provided which will answer the following requirements/questions:
- Describe the file type.
- What software is needed to open the file?
- Is there a standard which describes the file in detail?
- In the case of file types defined by a partner, describe the content definition.

2.2.10.1 .avi (Audio Video Interleave)

Description:
AVI is a multimedia container format. AVI files can contain both audio and video data in a file container
that allows synchronous audio-with-video playback. AVI files support multiple streaming audio and video.
Software:
VLC media player is a good application to reproduce almost every video format.
Standard:
AVI is a sub-format of the Resource Interchange File Format (RIFF) [4]

2.2.10.2 .c
Description:
A C file is a source code file for a C or C++ program. It may include an entire program source code, or
may be one of many source files referenced within a programming project.
Software:
Any text editor like Notepad++, Emacs, the Windows Notepad program, EditPlus, TextMate, and others,
can open and view a C file if it's a C/C++ Source Code file. Most of them support syntax highlighting,
which is usually preferred since it makes editing and sifting through the source code much easier.
However, C files are usually opened within the context of a software development program like Visual
Studio, Eclipse, C++Builder, Dev-C++, or Code::Blocks.
Standard:
A C library reference guide can be found in [5]. The C programming language standard is given in [6].

2.2.10.3 .cpp (C Plus Plus)

Description:
A CPP file is a source code file written in C++. It can be a standalone program or one of many file
references in a development project. CPP files must be compiled by a C++ compiler for the target
platform before run.

Software:
CPP files are most commonly edited with programs that provide syntax highlighting. CPP files may still
be opened using any text editor, but programs that provide syntax highlighting, auto-completion, and
other helpful tools are most often used. However, CPP files are usually opened within the context of a
software development program like Visual Studio, Eclipse, C++Builder, Dev-C++, or Code::Blocks.
© The NRG-5 consortium partners, 2017 24
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Standard:
The interface of C++ standard library is defined in [7].

2.2.10.4 .css (Cascading Style Sheet)

Description:
A CSS is a plain text file format used for formatting content on web pages. CSS is used by web pages to
help keeping information in the proper display format. CSS files can help defining font, size, color,
spacing, border and location of HTML information on a web page, and can also be used to create a
continuous look throughout multiple pages of a website.

Software:
CSS files can be opened and edited with programs such as Novell Extend Director.

Standard:
A CSS developer guide can be found in [8]. The CSS specifications are maintained by the World Wide
Web Consortium (W3C). Internet media type (MIME type) text/css is registered for use with CSS by
RFC 2318 (March 1998). The W3C operates a free CSS validation service for CSS documents [9].

2.2.10.5 .csv (Comma Separated Values)

Description:
A CSV is a file type commonly used by spreadsheet programs such as Microsoft Excel or OpenOffice
Calc. It contains plain text data sets separated by commas with each new line in the CSV file
representing a new database row. CSV files are often opened by spreadsheet programs to be organized
into cells or used for transferring data between databases. The file is also helpful for transferring data
saved in a proprietary format, such as an XLSX file, into another program that does not support the
XLSX format.

Software:
The CSV data exchange format is supported by a large amount of personal, business, and scientific
programs. Because of its wide support, the format is especially useful in transferring tabular data
between programs (e.g. KSpread, OpenOffice Calc and Microsoft Excel). Many other applications
support CSV in some fashion, to import or export data.

Standard:
The CSV file format is not fully standardized. RFC 4180 [10] proposes a specification for the CSV format,
and this is the definition commonly used.

2.2.10.6 .custom1 (Customized file type)

Description:
These files contain encrypted data.
Software:
Because of the encrypted nature of the data, the software for opening it needs to be accordingly
specified from case to case.
Standard:
© The NRG-5 consortium partners, 2017 25
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

The standard for data interchange of encrypted data will be negotiated per individual case.

2.2.10.7 .gpx (GPS Exchange Format)

Description:
GPX is an XML schema designed as a common GPS data format for software applications. It can be
used to describe waypoints, tracks, and routes.
Software:
Almost every GPS software can read this file. For example, OpenStreetMap, a collaborative project to
create free editable maps, uses (among others) GPX traces.
GPSBabel can be used to upload/download/convert GPX files.

Standard:
The complete specification for GPX files can be found at [11].

2.2.10.8 .h (Header)
Description:
An H file is a header file referenced by a C, C++ or Objective-C source code document. It may contain
variables, constants, and functions that are used by other files within a programming project. H files
allow commonly used functions to be written only once and referenced by other source files when
needed.
Software:
H header files can be opened with many programs, like Visual Studio, Eclipse, C++Builder, Dev-C++, or
Code::Blocks.
Standard:
For standard specification, more information can be found at [6] and [12].

2.2.10.9 .html (Hyper-Text Markup Language)

Description:
HTML is a file format used as the basis of a web page. HTML is a file extension used interchangeably
with HTM. HTML consists of tags surrounded by angle brackets. The HTML tags can be used to define
headings, paragraphs, lists, links, quotes, and interactive forms. It can also be used to embed
JavaScript, and CSS. The current version of HTML as per the W3C (World Wide Web Consortium) is
4.01, though HTML5 is currently in a draft phase.
Software:
HTML source code is parsed by a web browser and is typically not seen by the user. For viewing the
HTML of a webpage, one could select "View Source" from the web browser View menu.
Standard:
HTML specifications are reported in [13].

© The NRG-5 consortium partners, 2017 26

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.10.10 .java
Description:
A JAVA file is a source code file written in the Java programming language, which was originally
developed by Sun Microsystems but is now maintained by Oracle. It uses an object-oriented approach,
where structured data types, called “classes”, are used to instantiate objects at runtime. A file with the
JAVA extension may contain a single Java program or a variety of source code files that are combined
into a single executable app. Many compilers use these files to create Java source code.
Software:
JAVA files are opened with common text editors and programs like Eclipse. JAVA source code files are
compiled into CLASS files using a Java compiler (javac command). A CLASS file contains bytecode
that can be executed by the Java Virtual Machine (JVM). The JVM can be downloaded for every major
operating system, including Windows, Mac OS X, and Linux.
Standard:
JAVA specifications are reported in [14].

2.2.10.11 .jpg
Description:
A JPG file is an image saved in a compressed image format standardized by the Joint Photographic
Experts Group (JPEG). It is commonly used for storing digital photos and used by most digital cameras
to save images. JPG files are among the most common image files along with .PNG, .TIF, and .GIF.
Software:
There are a lot of different examples for software with which JPG files can be opened. GIMP is one of
them which is open-source and available for the different operating system platforms. More information
about GIMP and a download source can be found on the GIMP webpage [19].
Standard:
The file type is defined in ISO/IEC 10918 and more material can be found in [15].

2.2.10.12 .json (JavaScript Object Notation)

Description:
A JSON file is a file that stores simple data structures and objects in JavaScript Object Notation (JSON)
format, which is a standard data interchange format. It is primarily used for transmitting data between a
web application and a server.
Software:
The JSON file can be opened for human reading or machine interpretation.
For human reading, a standard text editor can be used, e.g. the free software Notepad++ on Windows or
the command line editor Vim on other operating systems.
For machine interpretation, the file type can be read with any programming language which can open
such files.

Standard:
The file type is standardized in two competing standards, namely RFC7159 and ECMA-404 [16].

© The NRG-5 consortium partners, 2017 27

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.10.13 .kmz (compressed .kml)

Description:
KMZ is a file extension for a placemark file used by Google Earth. KMZ stands for Keyhole Markup
language Zipped. It is a compressed version of a KML (Keyhole Markup Language) file. Keyhole was the
founding company of the Earth Viewer software that Google Earth was built upon.
KMZ files can contain placemarks featuring a custom name, the latitudinal and longitudinal coordinates
for the location, and 3D model data.
Software:
KMZ files can be opened by Google Earth, or unzipped with a compression utility, such as WinZip on
Windows, MacZip for Macintosh users, and Zip and UnZip for UNIX systems.
Standard:
KMZ has an open standard officially named the OpenGIS® KML Encoding Standard (OGC KML). It is
maintained by the Open Geospatial Consortium, Inc. (OGC). The complete specification for OGC KML
can be found at [17].

2.2.10.14 .kml (Keyhole Markup Language)

Description:
A KML file stores geographic modeling information in XML format. It includes points, lines, polygons, and
images. KML files are used to identify and label locations, create different camera angles, overlay
textures, and add HTML content.
Software:
KML files can be opened by programs like Google Earth and ESRI ArcGIS.
Standard:
The complete specification for OGC KML can be found at [17].

2.2.10.15 .mkv (Matroska Multimedia Container)

Description:
MKV is an open standard, free container format. This file format can hold an unlimited number of videos,
audios, pictures, or subtitle tracks in one file.
Software:
VLC media player is a good application to reproduce almost every video format.
Standard:
MKV specifications can be found at [18].

2.2.10.16 .mpeg (Moving Picture Experts Group)

Description:
MPEG is a popular video format standardized by the Moving Picture Experts Group (MPEG), often used
for creating movies that are distributed over the Internet. Videos in this format are compressed using
either MPEG1 or MPEG2 compression. This makes MPEG files popular for online distribution, since they
can be streamed and downloaded quicker than some other video formats.

© The NRG-5 consortium partners, 2017 28

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Software:
Files that actually have the MPEG file extension can be opened with many different multi-format media
players, like Windows Media Player, VLC, QuickTime, iTunes, and Winamp. Some commercial software
that support playing MPEG files include Roxio Creator NXT Pro, CyberLink PowerDirector, and
CyberLink PowerDVD. Some of these programs can open MPEG1, MPEG2, and MPEG4 files, too. VLC,
in particular, is known for its support for a huge range of audio and video file formats.

Standard:
More information regarding the MPEG specifications can be found in [19].

2.2.10.17 .pcap (Packet Capture)

Description:
In the field of computer network administration, PCAP consists of an application programming interface
(API) for capturing network traffic. Unix-like systems implement PCAP in the libpcap library; Windows
uses a port of libpcap known as WinPcap. Monitoring software may use libpcap and/or WinPcap to
capture packets travelling over a network and, in newer versions, to transmit packets on a network at the
link layer, as well as to get a list of network interfaces for possible use with libpcap or WinPcap.

Software:
The PCAP API is written in C, so other languages such as Java, .NET languages, and scripting
languages generally use a wrapper. C++ programs may link directly to the C API or use an object-
oriented wrapper.

Standard:
PCAP specifications can be found in [20].

2.2.10.18 .png (Portable Network Graphic)

Description:
A PNG file is an image file stored in the Portable Network Graphic (PNG) format. It contains a bitmap of
indexed colors and uses lossless compression, similar to a GIF file but without copyright limitations. PNG
files are commonly used to store graphics for web images.

Software:
The default photo viewer program in Windows is often used to open PNG files because it's included as
part of a standard Windows installation, but there are many other ways to view one. All web browsers
(like Chrome, Firefox, Internet Explorer, etc.) will automatically view PNG files opened from the internet,
without need of downloading every PNG file. There are also several standalone file openers, graphic
tools, and services that open PNG files. A few popular ones include XnView, IrfanView, FastStone Image
Viewer, Google Drive, Eye of GNOME, and gThumb. To edit PNG files, the XnView program just
mentioned can be used, as well as the Microsoft Windows included graphics program called Paint, the
Windows 10 Paint 3D tool, the popular GIMP utility, and the very popular (although not free) Adobe
Photoshop.

Standard:
PNG specifications are given in [21].

© The NRG-5 consortium partners, 2017 29

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.10.19 .py (Python)

Description:
A PY file is a script file format used by Python (open source object oriented programming language).

Software:
PY files can be created in any text editor, but need a Python interpreter to be read.

Standard:
PY reference documentation can be found in [22].

2.2.10.20 .raw
Description:
A RAW file is an image (not yet processed) generated by digital cameras such as Panasonic, Leica, and
Casio cameras. It contains uncompressed, raw image data that can be adjusted for exposure and white
balance using software that supports the format. RAW files are used for storing unaltered image data as
captured by a digital camera's CCD.

Software:
Several image tools support camera raw formats, many of which also advertise support for files that end
in the RAW extension. Some of these programs include Microsoft Windows Photos, Able RAWer, GIMP
(with UFRaw plug-in), and RawTherapee - all free. Although certainly not free, Adobe Photoshop also
supports a number of RAW formats.
Standard:

Providing a detailed and concise description of the content of raw files is highly problematic. There is no
single raw format; formats can be similar or radically different. Different manufacturers use their own
proprietary and typically undocumented formats, which are collectively known as RAW format. The ISO
standard raw image format is ISO 12234-2, better known as TIFF/EP. (TIFF/EP also supports "non-raw",
or "processed", images). More informations regarding the standard can be found in [23].

2.2.10.21 .sh (Shell)

Description:
An SH file is a script programmed for bash, a type of Unix shell (Bourne-Again SHell). It contains
instructions written in the Bash language and can be executed by typing text commands within the shell's
command-line interface. Files that contain the SH file extension are self-extracting archive files. The SH
file archive contains selected files and a shell script along with instructions on how to extract the contents
of the SH file archive.

Software:
SH files can typically only be used on computers that are run on the Unix operating system, although
systems similar to Unix may also use this file format. SH can be opened by programs like Notepad++
and gVim.

Standard:

More information can be found in [24].

© The NRG-5 consortium partners, 2017 30

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.10.22 .sol (Solidity)

Description:
A SOL file is a script written in the Solidity scripting language, which is similar to C++ and JavaScript. It
contains Solidity source code, which is used to create smart contracts for blockchain transactions.
Solidity is utilized by several blockchain platforms, such as Ethereum, Tendermint, and Counterparty.
Smart contracts are executable programs built in the Solidity scripting language. They allow users to
send value (money) to others using a digital currency, such as Ethereum. The value is called “Ether” and
is similar to Bitcoin, another cryptocurrency. SOL files used to complete Ethereum transactions are
processed by the Ethereum Virtual Machine (EVM). They record information such as the sender,
receiver, and amount transferred. When the contract is completed, the transaction information is added
to the blockchain.

Software:
SOL files are supported by Dapp, which is a Solidity package manager, build tool, and deployment
assistant. They are also supported by various programs with the Solidity plug-in installed, such as Visual
Studio, Visual Studio Code, Vim, and Sublime Text.
Standard:

Informations regarding Solidity can be found in [25].

2.2.10.23 .tif (Tagged Image File)

Description:

A file with the TIF or TIFF file extension is a Tagged Image file, used for storing high-quality raster type
graphics. The format supports lossless compression so that graphic artists and photographers can
archive their photos to save on disk space without compromising quality.

Software:
For just viewing a TIF file without editing it, any photo viewer included in any operating system will work
perfectly fine. For working with TIFF/TIF files directly, free photo editing programs like GIMP can be
used. Other popular photo and graphics tools work with TIF files as well, most notably Adobe Photoshop,
but that program is not free.

Standard:
Information can be found in [26].

2.2.10.24 .txt
Description:

TXT is a file extension for a text file, used by a variety of text editors. TXT is a human-readable
sequence of characters and the words they form that can be encoded into computer-readable formats.

Software:
TXT files are recognized by any text editing or word processing program and can also be processed by
most other software programs.

Standard:

© The NRG-5 consortium partners, 2017 31

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

There is no standard definition of a text file, though there are several common formats, including ASCII
(a cross-platform format), and ANSI (used on DOS and Windows platforms). Information can be found in
[27].

2.2.10.25 .vsd (ViSio Drawing)

Description:
These files contain vector graphics data.
Software:
This file can be opened with Microsoft Office Visio for Windows. The software is not open source. The
costs for a single license are below 100 Euro.
Standard:
This file type has a proprietary binary-format maintained by Microsoft.

2.2.10.26 .xls/xlsx (eXceL Spreadsheet)

Description:

An XLS file is a spreadsheet file created by Microsoft Excel or exported by another spreadsheet
program, such as OpenOffice Calc or Apple Numbers. XLSX is the compressed version. It contains one
or more worksheets, which store and display data in a table format. XLS files may also store
mathematical functions, charts, styles, and formatting.

Software:
XLS files can be opened by Microsoft Excel but also (between the others) by Microsoft Excel Viewer and
OpenOffice.
Standard:
More information are given in [28].

2.2.10.27 .xml (eXtensible Markup Language)

Description:
XML is a file extension for an Extensible Markup Language (XML) file format used to create
common information formats and share both the format and the data on the World Wide Web, intranets,
and elsewhere using standard ASCII text. They are plain text files that don't do anything in and of
themselves except describe the transportation, structure, and storage of data.

XML is similar to HTML. Both XML and HTML contain markup symbols to describe the contents of a
page or file. XML is considered extensible because, unlike HTML, the markup symbols are unlimited and
self-defining. XML is a simpler and easier-to-use subset of the Standard Generalized Markup Language
(SGML) standard for how to create a document structure. It is expected that HTML and XML will be used
together in many Web applications. XML markup, for example, may appear within an HTML page.

Software:

XML files have become a standard way of storing and transferring data between programs and over the
Internet. However, they can be used by many other types of programs. The XML syntax has been
utilized in a large variety of file formats, such as Microsoft Office Open XML, LibreOffice OpenDocument,
© The NRG-5 consortium partners, 2017 32
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

.XHTML, and .SVG. Many programs open XML files, including Code Beautify's Online XML Viewer and
some web browsers. There are several popular programs that can edit XML files as well. Some notable
free XML editors include Notepad++ and XML Notepad 2007. EditiX and Adobe Dreamweaver are a
couple other popular XML editors but they are only free to use if you can manage to get a trial version.
Standard:
More information are given in [29].

2.2.11 Description of the software products

This section is intended to be an Annex to Section 2.2.8. In the following, a brief “identity card” is
provided for each VNF and application logic (running on top of the VNFs) which have to be developed in
the project. Some information regarding the associated source codes is also given.
The responsible partners for the development of each VNF/application logic are hereafter summarized.

Responsible Partner VNF/Application logic to be developed

vTSD (virtualized Terminal Self-Discovery)

SU vSON (virtualized Self-Organized Networks)
vDES (virtual Distributed Energy Storage)
vMME (virtual Mobility Management Entity)
TEISTE
vRES (virtualized Renewable Energy Resources)
BT vMCM (virtualized Machine-Cloud-Machine communications)
vBCP (virtual Blockchain Processing)
POPs, TCS
vAAA (virtualized Authentication, Authorization, Accounting)
vMPA (virtual Media Processing Analyzer)
VIS
vDFC (virtual Drone Flight Control)
CRE, RWTH, ENG vPMU (virtualized Phasor Measurement Unit)
RWTH vESR (virtualized Electricity Substation & Rerouting)
SiLO, JSI AMIaaS (Advanced Metering Infrastructure as a Service)
EMOT, ENG DDRaaS (Dispatchable Demand Response as a Service)
VIS PMaaS (Predictive Maintenance as a Service)

In the following, the details for each VNF/application logic are provided according to a standard table.

2.2.11.1 vTSD

VNF description

Size Approx. 1GB

Access Only for partners
The virtual Terminal Self Discovery is the control plane function of the
xMEC node used to establish the first contact with the User Equipment
Purpose
processing registration beacons. It also provides for the deployment of
new Data Plane Translator on the needs
Relation with the project Low Layer networking VNFs designed for xMEC

© The NRG-5 consortium partners, 2017 33

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Associated Source Codes

Source Code
Size Approx. 10KB
File types .py

2.2.11.2 vSON

VNF description

Size Approx. 1GB

Access Only for partners
The virtual Self Organizing Network is the control plane function of the
xMEC node responsible for collecting topology information and to run
Purpose
the centralized network optimization algorithm. It also exposes a
northbound RESTful interface to the Application plane.
Relation with the project Low Layer networking VNFs designed for xMEC

Associated Source Codes

Source Code
Size Approx. 50KB
File types .py

2.2.11.3 vDES

VNF description

Size Approx. 1GB

Access Only for partners
Virtual Distributed Energy Storage gives aggregated per-geographical
area information about the storage capacity and the stored energy,
Purpose
receives requests for increasing the stored energy in a certain area and
triggers the recharging process for the involved storage points
Relation with the project Energy specific VNF

Associated Source Codes

Source Code
Size Approx. 50KB
File types .py

© The NRG-5 consortium partners, 2017 34

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.11.4 vMME

VNF description

Size At the range of MB

Access Not publicly available. Only for partners.
vMME provides for idle mobile devices registration, paging and tagging
Purpose (e.g. safeguarding the location of electric vehicles or mobile terminals
such as drones in proximity to the associated base station).
Component of the UC1 "3.1 Realizing a decentralized, trusted, lock-in
Relation with the project
free - Plug & Play vision"
Further notes vMME will be integrated with Openair (Interface & core network - CN)

Associated Source Codes

Source Code - Openair (Interface and Core network)

Size At the range of MB
File types .c
Security and privacy No security consideration for the source code. Source code is publicly
considerations available (Opensource). Openairinterface is licensed under OAI Public
License V1.1 while Openair-CN is licensed under Apache V2.0
License.
Source Code - vMME
Size At the range of MB
File types .py
Security and privacy Since the source code itself does not come in contact with any
considerations aspects of personal privacy, the source code can be made public.
Further notes Will be integrated with Openair (Interface & CN)

2.2.11.5 vRES

VNF description

Size In the range of MBs

Access Not publicly available. Only for partners.
vRES is responsible for abstracting the monitoring and control
Purpose operations of RES, particularly focusing on NORM-controlled RES
installations.
Relation with the project vRES is part of the Energy VNFs of the NRG-5 Project

Associated Source Codes

Source Code
Size In the range of MBs
File types .py

© The NRG-5 consortium partners, 2017 35

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.11.6 vMCM

VNF description

Size Approx 1.5G memory usage (Docker containers)

vMCM is based on Eclipse Ditto and it uses this as the digital twin
service. Ditto is available as open source software under the Eclipse
Access license. In addition, vMCM also includes bespoke wrappers and
interface software which have been written as part of NRG-5. These are
available to project partners on request.
vMCM provides a digital representation of physical infrastructure
enabling increased scalability and flexibility. The vMCM will allow utility
Purpose
resources and assets, nodes and communication network resources to
be modelled as digital twins
vMCM is part of WP2 and is deployed in the xMEC. It liaises with other
Relation with the project VNFs from WP2 for authentication (vAAA) and mobility management
(vMME)
The data stored could potentially contain personally identifiable
Security and privacy
information so appropriate security / encryption should be employed if
considerations
this is the case.

2.2.11.7 vBCP

VNF description

Size At the order of GBs

Access Public
This VNF allows for trusted entities (Smart Meters, Drones, VNFs,
Purpose
Applications) to easily interact with NRG-5 Blockchains infrastructures
Relation with the project Acts as an enabler for the security/trust features of NRG-5
Security and privacy No privacy or security considerations; this is a security and privacy
considerations enabler

Associated Source Codes

Source Code
Size At the level of KBs
File types .py, .sh

© The NRG-5 consortium partners, 2017 36

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.11.8 vAAA

VNF description

Size At the order of GBs

Access Not yet defined.
The purpose of the VNF is to provide AAA capabilities to NRG-5. It
includes two ways of AAA, one being based on blockchains (used
Purpose
together with vBCP) and one related to OAuth2.0, based on the open
source software Keycloak.
Relation with the project Enabler for security/trust operations

Associated Source Codes

Source Code
Size At the level of KBs
File types .js, .sol

2.2.11.9 vMPA

VNF description

Size ~6 Gb
Access Only for partners until the end of the project. Developments ongoing.
Image processing analyzer to recognize and alert some well defined
patters that ENGIE (gas plant operator) told VIS to search: field
Purpose
changes, color changes in vegetation, people and vehicle detection and
hot points.
Relation with the project Processing of the images taken by the drone and raise alerts.
Security and privacy To access videos and alerts, an authentication and authorization
considerations method has been implemented. Users have to be set up.

Associated Source Codes

Source Code
Size ~100 Mb + libraries
File types .py, .sh
Security and privacy
Algorithms are proprietary. An executable can be provided.
considerations

© The NRG-5 consortium partners, 2017 37

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.11.10 vDFC

VNF description

Size ~100 MB
Access Only for partners until the end of the project. Developments ongoing.
Purpose Control of the drone through a VNF.
Drone is the main tool used in preventive maintenance for critical
Relation with the project
infrastructure.
Authentication and authorisation mechanism has been built. Users have
Security and privacy to be set up to enter the application of the VNF. User level users are
considerations only able to read parameters while admin level users are able to
interact with the drone.

Associated Source Codes

Source Code
Size ~3 Mb
File types .sh, .py, .json, .yml, .html, .js, .css
Security and privacy
Private repository.
considerations

2.2.11.11 vPMU

VNF description

Size Not yet available.

Access Publicly available
Purpose To assess PMU data received from different grid points of the microgrid
It is a functionality which is assumed in the NRG-5 project to provide
Relation with the project
grid observability for UC1 and UC3
Privacy: data is not with private character, as being grid data which can
Security and privacy
be measured by any actor.
considerations
Security is solved with a separate VPN established for each actor

© The NRG-5 consortium partners, 2017 38

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

2.2.11.12 vESR

VNF description

Size Less than 10GB

The vESR algorithm can be made publicly available. For security
Access reasons, there may be parts of the vESR that cannot be made public,
like the description of real substations in any form.
The vESR enables control of the local substation and electricity
Purpose
rerouting activities.
The vESR can control substations, which is considered a critical
Security and privacy
infrastructure. Therefore, any description of real substations should not
considerations
be made public.

Associated Source Codes

Source Code
Size 10-20 MB
File types .cpp
Security and privacy The source code itself should not contain any safety relevant
considerations information and therefore can be made publicly available.
Source Code
Size 10-20 MB
File types .py
Security and privacy The source code itself should not contain any safety relevant
considerations information and therefore can be made publicly available

2.2.11.13 AMIaaS

Advanced Metering as a service description

Size At the range of MB

Access Restricted for intellectual property right reasons, only for partners
Achieving real-time overview of the smart grid status and allowing
Purpose
secure energy trading at the local level
Relation with the project Implements UC1
Since energy prosumers are going to participate in the local energy
Security and privacy marketplaces, there will be security and privacy considerations.
considerations AMIaaS is based on vAAA and vBCP to be as secure and private
(pseudo-anonymous) as possible.

Associated Source Codes

Source Code – Marketplace

Size of the source code At the range of MB
File types .js, .html, .py
Security and privacy No security consideration for the source code, the configuration of the
considerations sites will not be revealed. Will be integrated with vAAA/vBCP.

© The NRG-5 consortium partners, 2017 39

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Source Code – Dashboards

Size of the source code At the range of KB
File types .json (for Grafana configuration)
Security and privacy No security consideration for the source code, the configuration of the
considerations sites will not be revealed. Will be integrated with vAAA/vBCP.
Further notes Will be based on OSS Grafana
Source Code – VNF integration
Size of the source code At the range of KB
File types .py
Security and privacy No security consideration for the source code, the configuration of the
considerations sites will not be revealed. Will be integrated with vAAA/vBCP.

2.2.11.14 DDRaaS

Application logic description

This application logic is still in a proof of concept phase. To date, no

Size
information regarding the size is not finalized.
Access Only to the users involved, by means of username and password.
The purpose of the DDRaaS is to create a bridge between the DSO,
Purpose
which needs flexibility, and the aggregator, which provides flexibility
Relation with the project The DDRaaS is essential to perform the demonstration of the UC3

Associated Source Codes

Source Code – Raspberry Application

Size of the digital service 11 MB
File types Python 3.6 - Javascript - Html - Php
Source Code – Web Service
Size of the digital service 1 MB
File types Python 3.6
Source Code – Web Portal
Size of the digital service 15 MB
Size of the Source code 500 MB
File types Typescript - Framework Angular 2

2.2.11.15 PMaaS

Predictive Maintenance as a service description

Size 6 Gb
Access Only to the users involved, by means of username and password.
The purpose of PMaaS is to control and supervise drone flights for
Purpose
maintenance and supervision.
Relation with the project The PMaaS is essential to perform the demonstration of the UC2.
During tests of the PMaaS use case no image data of people faces
Security and privacy
(from people of outside the project) are recorded. Recordings of critical
considerations
infrastructure are always coordinated closely with the infrastructure

© The NRG-5 consortium partners, 2017 40

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

responsible to avoid risks during the recording as well as the recording

of sensitive data.

Associated Source Codes

Source Code – Web Service

Size of the digital service ~110 Mb
File types .sh, .py, .json, .yml, .html, .js, .css

It should be remarked that security and privacy considerations for VNFs/Application logics and the
associated source code highly depend on their nature and purpose. Furthermore, the developed
software may contain company secrets of one or multiple partners which are involved in the
development. In that case this particular software or source code may not be published openly.
Nevertheless all involved partners will do their best to grant public open access to developed software,
promoting the FAIR data principle (Section 2.3). Where eligible, authentication/authorization
mechanisms and restricted access will be put in place in the case of software products which are built for
purposes related to critical fields (e.g., energy markets, electric substation control, etc.) or deal with data
containing personal information.

2.3 FAIR data

The “Guidelines on FAIR Data Management in Horizon 2020” [1] helps Horizon 2020 beneficiaries make
their research data Findable, Accessible Interoperable and Re-usable (FAIR). This concept (so-called
FAIR data principle) is required to be used in EU-Projects. It should support the exchange of scientific
data and lead to knowledge discovery and innovation.

The FAIR data approach is described by the acronym:

Findable data Clear naming and versioning of (meta-) data, use of search keywords and DOI
Accessible data Specification of how data are made available and what tools are needed to access
data
Interoperable data Use of standards and vocabularies for (meta-)data and datatypes
Reusable data Specification of when - and for which duration - data are made available, licensing
of data

Parts of the data gathered during the project could be used to identify subjects, both individuals and
business entities. Before making data public, compliance with EU 2016/679 [30] regulation must be
checked.
Besides that, it may be part of the project to gather private, sensitive or security relevant data. Therefore,
each specific category of data needs to be assessed. After that, a decision is taken about making that
particular data type public or not.
The effort spent for data assessment should be reasonable compared to the foreseen value of the FAIR
data.

2.3.1 Findable data

© The NRG-5 consortium partners, 2017 41

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

First, to make the data generated by the NRG-5 project Findable (FAIR), a fixed naming and versioning
convention is needed. For documents, this convention was defined during the project kick-off. In
particular, deliverables and working documents should be named as follows:

Deliverables: NRG5_Dw.d_ACR_Vx.y-YYYYMMDD.ext
Working Documents: NRG5_Ww_Ttt_ACR_Vx.y-YYYYMMDD.ext
Where w is the work package number
d is the deliverable number
tt is the task number
ACR is the partner acronym
x is the version major number
y is the version minor number
YYYY is the year
MM is the month
DD is the day
ext is the file extension
Besides the naming convention, the “Guidelines on FAIR Data Management in Horizon 2020” [1] also
propose to have DOI for the data generated during the project. For this purpose, the project will use the
Zenodo platform [31] to fulfil the DOI requirement. In particular, Zenodo is a platform for long term
storage of data. The service is provided by CERN and financed by the EU. The platform can handle
single datasets of size up to 50 GB. If more storage space per dataset is needed, the user is encouraged
to contact CERN itself. The amount of space is not limited. The platform intends to help research project
to share data all over the world. To do so, Zenodo also helps by defining and storing some additional
metadata provided by the uploader. It is possible to grant access to the data only to a specific group of
users or the public. The platform also gives the user the possibility to restrict or open access to data for a
fixed period of time.

2.3.2 Accessible data

Another important part of the FAIR data principle is to make the data Accessible (FAIR) to the project
partners and, when possible, also to other researchers and to the public. To do so, NRG5 project will use
the Zenodo platform [31] for making the data accessible, when the consortium decides for a data open
access.
In the project, while Zenodo platform will be used for storing data such as project deliverables, GitLab
[32] will be used for the storage of any kind of software product. In particular, GitLab is a web-based
hosting service for version control, mostly used for computer code. It offers the functionality of distributed
version control and source code management, providing access control and several collaboration
features like task management, feature requests and bug tracking for every project. Projects on GitLab
can be accessed and manipulated using the standard Git command-line interface and all of the standard
Git commands work with it. GitLab also allows registered and non-registered users to browse public
repositories on the site.
The set of data collected and intended to be made available on a public platform must have a
broadcasting authorization by the operator of the site of origin. This requisite is to guarantee any
confidentiality and risk of fraudulent use of this data in a competitive context. This is also applicable for
data issued from industrial captors, and all pictures and videos.
© The NRG-5 consortium partners, 2017 42
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Making an example related to NRG-5 project, videos taken during drone overflights must be validated by
the local operator to be stored and shared on the public platform. The view angles will be predefined to
preserve confidential industrial processes. These shots on the public area are regulated by the local
authorities and require special agreements (to be confirmed, depending on the country).

2.3.3 Interoperable data

Making data Interoperable (FAIR) mainly relies on using suitable standards for data and metadata
creation along with appropriate vocabularies (e.g. for providing search keywords).
The details regarding the standards followed by project data together with the software applications for
its handling are widely reported in Section 2.2.10, where the file type description takes place.

2.3.4 Re-usable data

Re-usability (FAIR) of data is the last aspect of FAIR data principle. In this regards, data will be
published either after the release of the respective deliverables or after the end of the project.
Data availability after the end of the project depends highly on the type and content of data. Therefore
storing data on a public platform needs to be discussed with the contributor of the data. The
requirements for making data public also have an ethics aspect, which is discussed in WP8, whose
reference is D8.1 (please see also Section 2.6 below).
Regarding the licensing of deliverables, Zenodo encourages the users to share their research as openly
as possible to maximize use and re-use of the research results. However, since one size does not fit all,
Zenodo platform allows for uploading under a variety of different licenses and access levels, obviously
shifting to the user the responsibility for respecting applicable copyright and licence conditions for the
uploaded files. Alternative options are Embargoed Access (when a publisher has specified an embargo
period for a journal article), Restricted access (only available to specific users), and Closed access (only
available to the user uploading the document). Additional options will appear for the selected access
right, during the uploading procedure. For open access, it has to be specified the licence which the
publication is distributed under. Usually the default Creative Commons Attribution 4.0 licence [33] is
appropriate.

2.4 Allocation of resources

The costs of making data FAIR depend on the amount of data, which may be published due to the cost
of long term storage solutions and additional effort for publication. All the project data made FAIR will be
uploaded in Zenodo or GitLab, trying to make it as public as possible. Whenever a partner thinks it
differently, he will have to justify the choice, managing everything by himself.

The Data Manager (DM) is the person in charge of making sure that both the project and the data
handled and stored during project lifetime are compliant to EU 2016/679 [30] and EU 2016/680 [34].
The responsibilities related to data management are specified as follows:
Data Management Plan: Task 4.1 partners, lead: RWTH
Data storage and backup: ENG by administrating the internal repository
Data archiving and publication: Zenodo and GitLab. Each of the partners are responsible on

© The NRG-5 consortium partners, 2017 43

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

their own.

2.5 Data security

Each partner is responsible for recoverability of its own generated data (backup plan in place, according
to institution or company practice). The assessment of potential privacy issues and security risks with the
content of gathered data is done by the entity who is collecting the data.

2.6 Ethical aspects

NRG-5 targets the Smart Energy sector utilizing the 5G innovations. In the majority of the experiments
no ethical issues are predicted; however especially in the case of Automatic Metering Infrastructure
(AMI) and utilization of drones for Preventive Maintenance some clarifications are given. For more
detailed information, the reference is D8.1 (submitted on 30th November 2017).
The NRG-5 use case trials will operate a strict information security policy that will apply to the project.
The policy, and the information security risk register, will be adopted by the project. As a direct result, all
participants data will be anonymised, and access to data will obey to clearly defined rules. All systems
will be developed in strict compliance with ISO 27001 and ISO 25237 for pseudonymization of data.
The consortium partners are fully aware of the national data protection authorities and will meet the
requirements of their local data protection legislation. All NRG-5 partners that handle personal data are
aware of their National Data Protection Authorities and their data controllers will request the necessary
permission before the start of relevant NRG-5 activities. Overall, NRG-5 pilot experiments will be
developed and operated in full consideration of data protection principles and will satisfy data protection
requirements in accordance with EU directives and national implementations thereof. Personal data that
will be captured, after consent from participants, will be processed according to the applicable data
protection provisions, as presented in Chapter 2 of D8.1.
NRG-5 consortium guarantees that all legal provision of personal data and any location-aware service
will be respected during all phases of the project. Also, NRG-5 is aware of existing technological
measures necessary to minimize associated privacy risks.
NRG-5 implements cryptography and other privacy-preserving state-of-the-art technologies/techniques,
including: anonymization of data; privacy-preserving data aggregation; automatic video processing; data
storage and processing as close to the source as possible.
Furthermore, all partners will sign a specific contractual template to legally bind the individuals who can
access the collected data. Each partner has been invited to have these confidentiality statements signed
by the relevant team members.
The Ethics board will make sure that all NRG-5 pilots will present confidentiality statements to legally
bind the individuals who can access collected data, as well as to ensure the upholding of ethics
requirements on the participation of humans. Statements regarding the possible ethics issues arising
from each sub-project shall be submitted. The template for these documents is presented in Appendix III
of D8.1.
Security measures for accessing transferred data could be applied during the NRG-5 pilots. The
personal data of energy consumption research participants are pseudonymized. The list of pseudonyms
must be kept separated from the data sources.
Each research must keep the data of participants in the NRG-5 experiments in a separate computer or
hard disk, which can be accessed only by authorised personnel.

© The NRG-5 consortium partners, 2017 44

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Finally, as NRG-5 runs pilots where individuals are indirectly involved and personal data could be
collected, it is mandatory to define the procedures and methodology for identifying/recruit research
participants directly in the NRG-5 project or indirectly in the NRG-5 pilots. The basic principles covering
the involvement of humans as study participants are defined in Chapter 5 of D8.1.

© The NRG-5 consortium partners, 2017 45

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

3 Integration Guidelines
3.1 Introduction
Software and hardware development can be a very complex task. In order to ensure code quality, to test
the developed product and to track the changes made by different developers, Integration Guidelines
(IG) are needed. For example, IG define coding standards to be followed, in order to ensure that the
code is readable and understandable by different developers involved in the process.

To track changes in the software, repositories are used, where the different versions committed by the
developers are stored. In the following sections, guidelines for code development are discussed.

3.2 Software
3.2.1 Conventions
NRG-5 proposes “behavioural” guidelines/conventions to be respected during both the development and
integration phases. In the following, design patterns and code comments are proposed for facilitating
communication among the developing teams. Moreover, IG include the flowchart of actions to be
conducted, in order to share the latest pieces of code among the members of the development team.

3.2.1.1 Conventions related to development

Since software development will be conducted by geographically dispersed distributed teams of the
NRG-5 Consortium, efficient communication among them as well as comprehension of affected or
affecting code branches are vital for optimizing integration in terms of time and effectiveness. NRG-5
development guidelines constitute a set of rules, which will ensure consistent and standardized coding
practices. For a full list of good practices during code development, please refer to [35].

3.2.1.1.1 Design Patterns

Design patterns have been derived as general reusable solutions to commonly occurring problems within
a given context. The design pattern concept was introduced by the architect Christopher Alexander in
the field of architecture [36]. However, the concept has been adapted and applied in other fields as well,
including software design. Software design patterns do not imply designs which can be directly
transformed into code. Rather, they constitute a formal way of documenting the solution to a known
specific problem.
Developers within NRG-5 are encouraged to use design patterns, where applicable. Through design
patterns NRG-5 developers can have a common standard terminology for a common problem, facilitating
communication among them. Moreover, specified as common solutions, design patterns have been
evolved by developers over time, so that they describe best practices in common diagnosed problems.

3.2.1.1.2 Code comments

Code documentation is highly recommended within NRG-5, as it is beneficial for both the developer
developing a specific piece of software, but also for the ones revising or enhancing it or wishing to
interface with it. Since this process will typically take place significantly later after the time of
development, even the initial developers often find difficulty in instantly identifying their own code
functionality, often costing significant time and effort to recover memories. This bottleneck can be
overcome by including short comments throughout the code explaining functionalities. However, NRG-5
developers are encouraged to take into account the following principles while documenting their code:
© The NRG-5 consortium partners, 2017 46
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

 Comments should precede the code they refer to. During the course of development, additions
and modifications on the existing code could result in displacement of comments with regard to
the referred code. Developers should take care of their code structure and their comments
placement, after code updates.
 Comments should be consistent with the code they refer to. As code gets modified, comments
are often not updated accordingly, so that they could describe different functionalities or
parameters than the ones eventually developed or used. Thus, NRG-5 developers are
encouraged to provide consistent documentation of their code.
 Comments should be short and concise, so that their effectiveness and readability does not get
compromised.
 Comments should consist of the author name and date, so that potential incompatibilities can be
reported to the original developers.

3.2.1.1.3 Programming languages

NRG-5 aims at integrating a large number of services and third-party applications along with the
standard developments of the project per se. The applications and services that should be integrated
and supported have vastly diverse specifications and, therefore, requirements, resulting in the selection
of a single programming language as preferred to be an unrealistic consideration. Instead of agreeing on
the use of a single programming language, NRG-5 has opted for orchestration at the level of APIs that
are technology agnostic.
Hence, RESTful APIs and publish subscribe client-server architectures have been considered across all
the development activities of NRG-5. By means of this approach, there is no programming language
lock-in, allowing all interested parties to integrate by simply respecting the specifications of the APIs of
interest.

3.2.1.2 Conventions related to integration

In this section, guidelines facilitating integration activities are outlined. They mostly refer to NRG-5
developers as well, but in the prism of integration.

3.2.1.2.1 Respect over Interfaces and Data Models

A major principle for effective code integration relates to interfaces and data models. Data models define
classes, parameters and allowed methods, while the same classes can be used by several developers
during the development of a system framework, like NRG-5. On the other hand, interfaces specify the
communication among software components, defining the information flow, the interacting entities, their
role in this interaction and the way this interaction is realized. In the same way, well-defined data model
and interfaces specifications may facilitate and actually enact components interaction, while not
respected specifications may result in significant incompatibilities and lack of interaction.
As NRG-5 progress will be realized in an evolutionary manner, enhancements and modifications over
existing code will necessarily take place. As a result, data models and interfaces may need to be
modified as well. NRG-5 developers are required to respect specified interactions, data models and
processes, to the extent possible. In the case of mandatory changes over specified processes, NRG-5
developers are required to concretely specify the changes required, communicate them to the
developing teams and include them in the revised version of the NRG-5 data model or architecture, if
there is one to be delivered.

3.2.1.2.2 Source Commits

When software development takes place in geographically dispersed places by different developing
teams, a common code repository can be of great help, as a means of collecting different pieces of code
and gradually integrating individual software parts. This way, distant teams can be updated with the work
conducted with other teams, identify points and potential problems of interaction and thus have a better
© The NRG-5 consortium partners, 2017 47
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

picture of the code they develop as a whole. Although source control appears as a greatly helpful
solution for distributed software development, its benefits may be burdened by improper use of the
characteristics offered by the source code management platform.
First, serious integration problems may arise, when broken code is committed. Interaction with other
pieces of software requires that the already committed code is working and functional. Thus, NRG-5
developers should test their code before uploading it in the common repository.
Moreover, effective communication among different developing teams is achieved only if code commits
take place on a frequent and systematic basis. Small pieces of code can be easily reviewed and
integrated, while big pieces of code committed at once are harder to manipulate. As a result, NRG-5
developers should commit their code on a frequent and meaningful basis, providing the other developing
teams with basic ideas and interactions of their solution. Software commits should start from basic API
skeletons and gradually construct full-functional code parts.

3.2.2 What is CI/CD

Continuous Integration (CI) refers to having a framework allowing developers to work on both
differentiated branches of code and on a core (master) branch, effectively referring to the integration of
code into a known or working code base [37]. All source-code related actions and control operations
(e.g. branching requests, review requests, merge requests, unit testing procedures, software package
building etc.) are related to CI, as well [38]. CI functionality are generally exposed by advanced source
code management tools like Git, Subversion, Mercurial etc, Git being the most prominent and widely
used of all. However, nowadays, there exist multiple platforms offering added value services on top of
these source code management tools, such as Github, GitLab, Bitbucket etc.
Continuous Delivery (CD) refers to the automated process of delivering a complete software package or
service to an environment, be it integrated testing or production. In other words, it refers to controlling the
deployment of the software package or service to designated target application containers or servers for
immediate consumption. Most of the aforementioned source code management platforms also provide
the ability to integrate CD technologies either as third party (e.g. use Github combined with Jenkins [39]
or Travis [40]) or integrated (e.g. GitLab with GitLab-CI [41]) services.
Based on the above definitions, CI/CD refers to integrating the entire source code management and
service delivery processes into one single pipeline that would cater for the deployment of a software
package or service whose code has been mutually accepted by either automated routines (e.g. related
to testing) or human-based activities (e.g. code review requests, branch merge requests etc.).
In the above context, testing plays a critical role as to the quality of the service being delivered in the end
of the process. Three main types of testing are defined in general:
 Unit testing refers to testing the behaviour of the smallest part of software design, like functions.
The goal is to identify code-related issues, pertaining to the syntactical correctness of the code
and the rationality of the produced outcomes.
 Integration testing combines several software components (already unit-tested), such as libraries
and modules, and test them as a whole. It ensures certain subsets of the system work as
expected, from an interworking perspective.
 System testing focuses on the user’s or customer’s perspective, checking whether the overall
system meets the given specification.
Figure 1 provides an overview of an integrated CI/CD framework:

© The NRG-5 consortium partners, 2017 48

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Figure 1: Principle CI/CD [42]

Note that the CI part practically ends on the Automated Acceptance tests; thereafter, the CD part takes
place.
Completing the automated testing and quality enforcement status quo of the CI/CD framework, one may
apply source code inspection through automation frameworks such as SonarCube [43]. Although code
quality is not vital for the successful testing of a system or even its deployment, it can largely affect its
efficiency in terms of resource allocation and/or performance, hence it is, in general, recommended.
Overall, the above could highly benefit our work as automated testing, though cumbersome and very
time consuming, can assure that development over heterogeneous infrastructure and of different scope
remain working and inter-working at any time. Under a CI/CD approach and considering the project
orientation towards using OSM as base platform for NFV, the CI/CD approach would imply e.g.:
1. The developer implements a certain piece of software that wishes to integrate to the core
system functionality, irrespectively of whether this piece of code corresponds to the
development of a VNF or a platform component;
2. The developer introduces (or should have already introduced) a test case that unit tests the
relevant piece of code at the level of rationality checking and outcomes consistency. The unit
testing should be as thorough as possible.
3. The developer commits the code to a dedicated development branch defined in the CI
infrastructure.
4. The developer initiates a request for code merging.
5. The CI platform performs the determined unit testing;
a. If the unit testing is successful, the code is subject to further integrated system testing.
i. If the integrated system testing is successful, then the merge request is accepted
and the newly committed source code gets part of the code master branch.
ii. Otherwise, the merge request is rejected.
6. If either the unit or integrated system testing fails, the pull request is rejected. In this case, the
developer should consider either a code rewrite to satisfy the unit testing procedures, or the

© The NRG-5 consortium partners, 2017 49

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

unit testing rewrite (to avoid situations of erroneous unit testing. The workflow should be re-
initiated at step 1.
7. The source code management platform move to the CD part, building the package and
deploying it;
8. After successful CD, the new code is running on the deployment infrastructure and is subject
to user testing/production.

Although multiple CI/CD frameworks and platforms are available, Gitlab.com appears as a good
candidate for hosting the developments of the NRG-5 project. It is an open source management platform
which suites the needs of the NRG-5 project and can provide the following needs:
1. Multiple projects are possible, grouped under groups and subgroups;
2. Multiple private projects can be created; no need for opting for a pro account to have private
(non-public) projects. This is particularly important in the development phase; maybe we
would prefer to proceed with the development up to a point, then making the projects public
(open source).
3. It has native CD mechanisms.

Complying with NRG-5 view of end-to-end CI/CD, GitLab promotes conversational development [44] to
speed-up the coding activities, increase errors visibility and establish proper, controlled CI/CD
operations. To achieve this, GitLab exposes the conversational development status of a project using the
following tabulated stages and calculated values to calculate the project’s conversational development
index (ConvDev Index), providing an overview of the project adoption of Concurrent DevOps from
planning to monitoring.
Table 1: The values considered in GitLab’s ConvDev index calculation.
Stage Description
Issue (Tracker) Median time from issue creation until given a milestone or list label (first
assignment, any milestone, milestone date or assignee is not required)
Plan (Board) Median time from giving an issue a milestone or label until pushing the first
commit to the branch
Code (IDE) Median time from the first commit to the branch until the merge request is
created
Test (CI) Median total test time for all commits/merges
Review Median time from merge request creation until the merge request is merged
(Merge Request/MR) (closed merge requests won’t be taken into account)
Staging (Continuous Median time from when the merge request got merged until the deploy to
Deployment) production (production is last stage/environment)
Production (Total) Sum of all the above stages’ times excluding the Test (CI) time. To clarify, it’s
not so much that CI time is “excluded”, but rather CI time is already counted
in the review stage since CI is done automatically. Most of the other stages
are purely sequential, but Test is not.

In technical terms, GitLab promotes the term “pipeline” to describe sets of sequential CI and CD
operations. In this course, CI pipelines include code building followed by automated unit and integration
tests. Next, CD pipelines deploy the code to different environment, most usually for review, for actual
user testing (staging phase) and, finally for production use. The above is depicted in Figure 2.

© The NRG-5 consortium partners, 2017 50

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Figure 2: Continuous integration infographic (source: [45]).

GitLab organizes the CI/CD pipelines by employing pipeline graphs (e.g. as depicted in Figure 3) that are
described via sets of simple YAML scripts (with a static filename .gitlab-ci.yml) referred to as job files
[46], where the various pipelines are organized in stages. Jobs are executed by designated GitLab
runners.

Figure 3: Indicative GitLab pipeline graph (source: [47]).

More information on how to properly configure a GitLab CI/CD job are given in [46]. It is worth
mentioning, however, that the aforementioned GitLab runners refer to services that connect to the
project GitLab instance -either the public or a private one- and listen for code changes so that they can
actually perform the source code building/testing/deploying. The code execution is performed in sandbox
Docker containers that are automatically generated by the GitLab runners and get automatically deleted
when all the stages have been successfully completed.
Figure 4 offers a snapshot of the NRG-5 source code repository hosted under the public instance of
gitlab.com [48].

© The NRG-5 consortium partners, 2017 51

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Figure 4: View of the NRG-5 source code repository at gitlab.com.

3.2.3 Integration of VNFs

Following the CI/CD integration guidelines documented in the previous section, the lifetime of the VNFs
development, testing, qualification and deployment will be defined in a likewise manner. This approach is
also in accordance to the overall CI/CD-oriented approach of OSM, which, in the NRG-5 context,
effectively defines the following steps as necessary for accepting new VNF- and platform-related code
into the master source code branch:
1. Follow the steps 1 - 6 of the generic CI approach described in the previous paragraph,
including tests, defined and implemented by the responsible VNF developers.
2. The successful merge of the code should be followed by a subsequent instruction to the
MANO framework to integrate the updated component to an a-priori designated infrastructure
which can vary as follows:
• The xMEC if it is a VNF intended to be used at base station level (e.g. a VNF
intended to fulfil a set of uRLLC or uMTC requirements);
• At local DC level if it is a VFN intended to be used at non-real-time applications
whose delay constraints are average;
• At regional DC level if it is a VNF or VNF extract intended to be used for
operations that imply large processing times, hence higher response times.

Note that in any case, OSM is responsible for creating or updating the respective VNF instance, together
with the re-configuration of the VNFFPs, VNFFGs and NSs that such a creation/update might imply. At
all times, the deployment process will be monitored in terms of time spent for the actual deployment, in
an attempt to acquire metrics of performance of the particular deployment site. This continuous
monitoring approach will assist the work of the determination of the optimal placement of the VNFs,
avoiding to utilize deployment sites that exhibit lower performance profiles for delay intolerant VNFs and
NSs.
Since NRG-5 has opted for using OpenStack as core VIM, a generic platform for enabling CI/CD
integrating OpenStack and OSM functionalities has been defined and developed and is presented in the
Annex. The script shown in the Annex enable a fully automated way from commit to deployment. This
approach can reduce time to market of new functionalities and the deployment of bug fixes significantly.

© The NRG-5 consortium partners, 2017 52

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

© The NRG-5 consortium partners, 2017 53

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

4 References

[1] “Guidelines on FAIR Data Management in Horizon 2020,” 26 6 2016. [Online]. Available:
http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-oa-
data-mgt_en.pdf. [Accessed 24 11 2017].
[2] NRG5 Grant Agreement page 141.
[3] NRG5 Grant Agreement page 142.
[4] “AVI RIFF File Reference,” [Online]. Available: https://msdn.microsoft.com/en-us/library
/ms779636(VS.85).aspx.
[5] [Online]. Available: https://www-s.acm.illinois.edu/webmonkeys/book/c_guide/index.html.
[6] “C programming standards,” [Online]. Available: https://www.iso.org/standard/29237.html.
[7] “C++ library,” [Online]. Available: https://en.cppreference.com/w/cpp/header.
[8] “Css learn docs,” [Online]. Available: https://developer.mozilla.org/en-US/docs/Learn/CSS.
[9] “Css validator,” [Online]. Available: http://jigsaw.w3.org/css-validator/.
[10] “Csv,” [Online]. Available: https://tools.ietf.org/html/rfc4180.
[11] “GPX definition,” [Online]. Available: http://www.topografix.com/gpx/1/1/.
[12] “Header,” [Online]. Available: https://en.cppreference.com/w/cpp/header.
[13] “HTML specification,” [Online]. Available: https://www.w3.org/TR/html5/.
[14] “Java specifications,” [Online]. Available: https://docs.oracle.com/javase.
[15] “JPG,” [Online]. Available: https://jpeg.org/ .
[16] “Json,” [Online]. Available: https://www.json.org/ .
[17] “KML definition,” [Online]. Available: http://www.opengeospatial.org/standards/kml/.
[18] “MKV definition,” [Online]. Available: https://matroska.org/technical/specs/index.html.
[19] “mpeg,” [Online]. Available: https://en.wikipedia.org/wiki/Moving_Picture_Experts_Group.
[20] “Pcap,” [Online]. Available: https://www.tcpdump.org/.
[21] “Png,” [Online]. Available: https://www.iso.org/standard/29581.html.
[22] “Python,” [Online]. Available: https://www.python.org/.
[23] “raw,” [Online]. Available: https://www.iso.org/standard/29377.html.
[24] “Sh,” [Online]. Available: http://www.faqs.org/docs/air/tsshell.html.
[25] “Solidity,” [Online]. Available: https://solidity.readthedocs.io/en/v0.4.24/index.html.
[26] “tif,” [Online]. Available: https://www.adobe.io/open/standards/TIFF.html.
[27] “txt,” [Online]. Available: https://en.wikipedia.org/wiki/Text_file.

© The NRG-5 consortium partners, 2017 54

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

[28] “xlsx,” [Online]. Available: https://support.office.com/en-us/article/file-formats-that-are-supported-in-

excel-0943ff2c-6014-4e8d-aaea-b83d51d46247.
[29] “xml,” [Online]. Available: https://support.office.com/en-us/article/Open-XML-Formats-and-file-name-
extensions-5200d93c-3449-4380-8e11-31ef14555b18.
[30] “Regulation (EU) 2016/679” [Online].,” [Online]. Available: Available: http://eur-lex.europa.eu/legal-
content/EN/TXT/PDF/ ?uri=CELEX:32016R0679&from=DE.
[31] “https://zenodo.org/,” [Online].
[32] “GitLab,” [Online]. Available: https://about.gitlab.com/.
[33] “CC licence,” [Online]. Available: https://creativecommons.org/licenses/by/4.0/.
[34] “Directive (EU) 2016/680,” [Online]. Available: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/
?uri=CELEX:32016L0680&from=EN.
[35] D. Spinellis, “15 Rules for Writing Quality Code,” 9 06 2014. [Online]. Available:
http://www.informit.com/articles/article.aspx?p=2223710. [Accessed 17 09 2014].
[36] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel, A Pattern
Language, Towns, Buildings, Construction, New York: Oxford University Press, 1977.
[37] “CI-CD,” [Online]. Available: https://www.nwcadence.com/blog/continuousintegration-
continuousdelivery.
[38] “CI,” [Online]. Available: https://en.wikipedia.org/wiki/Continuous_integration.
[39] “https://jenkins.io/,” [Online].
[40] “https://docs.travis-ci.com/user/deployment,” [Online].
[41] “https://about.gitlab.com/features/gitlab-ci-cd/,” [Online].
[42] “https://en.wikipedia.org/wiki/Continuous_delivery,” [Online].
[43] “https://www.sonarqube.org/,” [Online].
[44] [Online]. Available: https://docs.gitlab.com/ee/user/instance_statistics/convdev.html.
[45] [Online]. Available: https://docs.gitlab.com/ee/ci/.
[46] “Gitlab jobs,” [Online]. Available: https://docs.gitlab.com/ee/ci/yaml/README.html#jobs.
[47] “Gitlab pipelines,” [Online]. Available: https://docs.gitlab.com/ee/ci/pipelines.html.
[48] “NRG-5 source code repository,” [Online]. Available: https://gitlab.com/NRG-5.
[49] [Online]. Available: https://docs.gitlab.com/ee/ci/yaml/README.html.
[50] A. . Maven, “Maven,” , . [Online]. Available: http://maven.apache.org. [Accessed 12 11 2018].
[51] [Online]. Available: https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html.
[52] [Online]. Available: https://docs.gitlab.com/ee/ci/variables/README.html.
[53] “NRG-5 Openstack-OSM-CICD,” [Online]. Available: https://gitlab.com/NRG-5/aux/openstack-osm-
cicd.

© The NRG-5 consortium partners, 2017 55

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

5 Annex
In this Annex, indicative examples of GitLab CI job descriptors are presented. In Sections 5.1 to 5.3
some generic descriptors are presented targeting at technologies adopted by the NRG-5 partners,
whereas in paragraph 5.3 a more complex CI/CD job assisted by a set of Python scripts that allows for
automatically updating OpenStack VNF snapshot images and OSM VNFDs is presented. More
information on the templating language of the GitLab CI jobs may be found in [49].

5.1 Python web service docker deployment

This indicative CI/CD job description refers to the deployment of a Python web service in a docker. The
job consists of one stage only (the deployment one) and the steps followed to perform the deployment
are:
1. Specify the key to SSH into the server;
2. Specify the docker container name;
3. Handle the key permissions so that the SSH can be performed to the target server;
4. Accept the authenticity of the server, by default;
5. Remove the existing code on the server;
6. Create the directories structure required for placing the new code in the server;
7. Securely transfer the code to the server;
8. Fix the permissions for files and directories;
9. Perform the Docker configuration;
10. Install the docker container

As per the very latest command of the job description, the above are meant to be performed in every
source code commit that is done on the master branch of the repository.

image: rastasheep/ubuntu-sshd:16.04

stages:
- deploy

deployment:
stage: deploy
script:
- KEY="$BUILD_DIRECTORY/$SSH_KEY"
- CONTAINER_NAME="simple-django-example"
- chmod 400 $KEY
- ssh-keyscan -H $TARGET_SERVER >> ~/.ssh/known_hosts
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "rm -rf $TARGET_DIRECTORY*"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "mkdir $TARGET_DIRECTORY && mkdir
$TARGET_DIRECTORY/$SOURCE_DIRECTORY"
- scp -i $KEY -r ./*
$TARGET_SERVER_USER@$TARGET_SERVER:$TARGET_DIRECTORY/$SOURCE_DIRECTORY
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "find
$TARGET_DIRECTORY/$SOURCE_DIRECTORY -type d -exec sudo chmod -R 755 {} \;"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "find
$TARGET_DIRECTORY/$SOURCE_DIRECTORY -type f -exec sudo chmod 664 {} \;"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "chmod a+x
$TARGET_DIRECTORY/$SOURCE_DIRECTORY/deployment/run.sh
$TARGET_DIRECTORY/$SOURCE_DIRECTORY/deployment/clean.sh"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "cp
$TARGET_DIRECTORY/$SOURCE_DIRECTORY/deployment/Dockerfile $TARGET_DIRECTORY/Dockerfile"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "cd $TARGET_DIRECTORY && sudo docker
build -t $SOURCE_DIRECTORY . && source $SOURCE_DIRECTORY/deployment/clean.sh && sudo docker
run -p 3338:3333 --name $CONTAINER_NAME --restart always -dit $SOURCE_DIRECTORY"
only:

© The NRG-5 consortium partners, 2017 56

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

- master

Figure 5: CI/CD template for deploying a Python web service in a packaged in a docker container.
Note that for the template to work, the variables TARGET_SERVER_USER, TARGET_SERVER,
TARGET_DIRECTORY, SOURCE_DIRECTORY, CONTAINER NAME should have already been defined as job
variables.

5.2 Python web service direct installation with testing

This template refers to a direct installation of a Python web service (based on Python Django framework
combined with PostreSQL) onto an existing OpenStack VM. The job considers two stages, one handling
the testing of the component functionality and one being responsible for the deployment. The full
description of the steps is omitted. In short, during the testing phase, the software requirements are
being installed, then the DB is being configured and the tests are being conducted. The steps of the
deployment phase are almost identical to the previous case.

image: python:3.5.2

stages:
- test
- deploy

testing:
stage: test
script:
- apt-get update
- apt-get install -y lsb-release locales debconf-utils redis-server
- apt-get install -y python3-dev python3-lxml python3-pip python3-cffi libcairo2
libpango1.0-0 libgdk-pixbuf2.0-0 libffi-dev shared-mime-info
- echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen
- locale-gen
- apt-get -y install postgresql postgresql-contrib libpq-dev libssl-dev libffi-dev
- service postgresql start
- service redis-server start
- su - postgres -c "psql -c \"ALTER USER postgres WITH PASSWORD '12345678'\""
- touch ~/.pgpass
- echo "*:*:*:postgres:12345678" > ~/.pgpass
- su - postgres -c "psql -c \"UPDATE pg_database SET datistemplate = FALSE WHERE datname
= 'template1';\""
- su - postgres -c "psql -c \"DROP DATABASE template1;\""
- su - postgres -c "psql -c \"CREATE DATABASE template1 WITH TEMPLATE = template0
ENCODING='UNICODE' LC_COLLATE='en_US.UTF8' LC_CTYPE='en_US.UTF8';\""
- su - postgres -c "psql -c \"UPDATE pg_database SET datistemplate = TRUE WHERE datname
= 'template1';\""
- su - postgres -c "psql -c \"UPDATE pg_database SET datallowconn = FALSE WHERE datname
= 'template1';\""
- su - postgres -c "psql -c \"CREATE DATABASE project_db WITH encoding='UTF8'\""
- pip3 install -r prod_requirements.txt
- export DJANGO_SETTINGS_MODULE=Success.settings.test
- python3 manage.py test

deployment:
stage: deploy
script:
- KEY="$CI_PROJECT_DIR/$BUILD_DIRECTORY/$SSH_KEY"
- chmod 400 $KEY
- mkdir ~/.ssh && touch ~/.ssh/known_hosts
- ssh-keyscan -H $TARGET_SERVER >> ~/.ssh/known_hosts
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "sudo rm -rf $SOURCE_DIRECTORY"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "sudo mkdir $SOURCE_DIRECTORY && sudo
chmod 777 $SOURCE_DIRECTORY"
- scp -i $KEY -r $CI_PROJECT_DIR/*
$TARGET_SERVER_USER@$TARGET_SERVER:$SOURCE_DIRECTORY
© The NRG-5 consortium partners, 2017 57
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "find $SOURCE_DIRECTORY -type d -exec

sudo chmod -R 755 {} \;"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "find $SOURCE_DIRECTORY -type f -exec
sudo chmod 664 {} \;"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "sudo cp
$SOURCE_DIRECTORY/updaters/update.sh /opt"
- ssh -i $KEY $TARGET_SERVER_USER@$TARGET_SERVER "sudo bash /opt/update.sh"
only:
- master

5.3 Java web service served by Tomcat

This CI/CD template is related to compiling and deploying Java/Scala WAR (web application resource or
web application archive) files generated via the Java Maven build system [50]. The script is
straightforward, containing only one stage for both compiling the source code and deploying it on a
Tomcat application container, granted that the latter has enabled the Manager application [51].

image: maven:latest

variables:
USER: "tomcat"
PASSWORD: "tomcat"
TOMCAT_IP: "192.168.1.2"
TOMCAT_PORT: "8080"
DEPLOY_PATH: "/"
WAR: "your_java_war#v0.1-SNAPSHOT.war"

stages:
- deploy

deploy:
stage: deploy
script:
- mvn clean
- mvn install
- curl --upload-file target/$WAR
"http://$USER:$PASSWORD@$TOMCAT_IP:$TOMCAT_PORT/manager/text/deploy?path=$DEPLOY_PATH&update=t
rue"
only:
- master

The execution context of the CI/CD job related to the deployment phase comprises three successive
commands:
1. Clean the target directory (the one holding the bytecode binaries);
2. Compile the source code, package it and install it in the local user maven cache;
3. Upload the resulting WAR file to the target tomcat installation (Manager App).

It is worth noting that the variables set in the script could be also integrated as project-level variables
rather than job-level variables (see [52] for details and discussion).

5.4 Generic VNF update

This template has been compiled by NRG-5 partners in order to facilitate the integration processes of
NRG-5, by setting up the CI/CD process in a controlled manner. The CI/CD job script is a fairly simple
one, comprising two stages (testing and deployment) and one common pre-stage where the
dependencies for executing the two stages are installed for each stage.

© The NRG-5 consortium partners, 2017 58

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

image: ubuntu:16.04

before_script:
- apt update
- apt install -y python python-pip
- pip install -r requirements.txt

stages:
- test
- deploy

test:
stage: test
script:
- echo "Your tests here"

deploy:
stage: deploy
script:
- echo "$OS_CONTROLLER controller" >> /etc/hosts
- python setup.py $OS_PROJECT "$VNF_IMAGE" $VNF_SERVER_NAME \
--os-user-name $OS_USER_NAME \
--os-password $OS_PASSWORD \
--os-domain-name $OS_DOMAIN_NAME \
--os-auth-uri $OS_AUTH_URI \
--cpu $VNF_vCPU \
--memory $VNF_vMEMORY \
--disk $VNF_vDISK \
--keypair $VNF_PUBLIC_KEY \
--version $CI_COMMIT_TAG \
--verbose
only:
- tags

The CI/CD job variables needed for running the script are as follows (only the VNF_IMAGE variable may
contain spaces):

Table 2: Required variables for configuring and running the NRG-5 CI/CD build job.
Variable Description Example
The commit tag; the name of the tag will be
used as version information in the VM image
name. Indicatively, with respect to the
CI_COMMIT_TAG 1.0.rev13
examplary variables on the right side of the
table, the resulting image name would be
vAAA-v1.0.rev13.

OS_AUTH_URI
The endpoint where the Identity service of http://controller:5000/v3
Openstack listens to.
The IP of the controller node of the cluster.
OS_CONTROLLER
This value is used to update the VM hosts in 192.168.1.2
case the controller advertises itself as
“controller” rather than using its IP.
The domain name (user and project) to use
OS_DOMAIN_NAME for authenticating against the OpenStack default
Identity service.

© The NRG-5 consortium partners, 2017 59

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

OS_PASSWORD The password of the Openstack user to use. p@$$0rd

OS_PROJECT
The project (tenant) of OpenStack to OSM
authenticate against

OS_USER_NAME
The user name of the OpenStack user to osm-user
use.

VNF_IMAGE
The image name to use for building the Centos 7.0
target VM.

VNF_PUBLIC_KEY
The public key to use to SSH to the created Osm
VM.
The name to give to the server that will later
VNF_SERVER_NAME be snapshotted. It should match the name of vAAA
the respective OSM VNF name.

VNF_vCPU
The number of virtual CPUs to use for 2
creating the target VM.

VNF_vDISK
The size of the disk (in GBs) to use for 10
creating the target VM.

VNF_vMEMORY
The amount of virtual RAM to use for 2048
creating the target VM in MBs.

© The NRG-5 consortium partners, 2017 60

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

The above is visualized in Figure 6, where a screenshot of a running NRG-5 VNF CI/CD repository is
depicted.

Figure 6: Setting the required variables at the CI/CD settings of the GitLab project.

The test stage is left empty, so that each VNF developer may write their own test scripts, without
depending on a specific programming language or framework.
The deploy stage, on the other hand, first configures the known hosts of the build docker container so
that communication with the OpenStack controller node may be achieved, then executes the setup.py
script which is the main entry point to the NRG-5 OpenStack-OSM processes. In detail, the setup.py
script sequentially performs the following:
1. Creates an OpenStack server (target VM) using the OpenStack user credentials, project details,
VM image and flavor options (vCPU, vRAM and vDisk) as well as the public keypair (.pem file)
defined in the variables of the build job.
2. When the image has been successfully created, it executes two scripts, a local and a remote
one. The local script should be used to possibly configure the source code, then initiate an SSH
connection to the created VM so that the code (binaries) may be properly deployed. Then, the
remote script should be executed to undertake the final deployment of the code, install the
necessary dependencies etc. The two scripts are located under the commands directory (see
Figure 11).
3. When the installation has been completed, it stops the server to preserve its memory state and
accelerate snapshotting, then instructs OpenStack to take a snapshot of the deployed service in
the target VM.
4. Updates the OSM catalogue as to the version of the OpenStack image to use for deploying the
corresponding VNF.
© The NRG-5 consortium partners, 2017 61
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

5. Deletes the target server.

The following listing presents a snapshot of the integration project running on a private GitLab Runner
instance.
2018-11-09 17:45:49,976 -- [ create: process_request:L 72] -- DEBUG -- Getting proper flavor

2018-11-09 17:45:50,086 -- [ create: process_request:L 75] -- DEBUG -- Getting proper image

2018-11-09 17:45:50,137 -- [ create: process_request:L 78] -- DEBUG -- Getting proper keypair

2018-11-09 17:45:50,220 -- [ create: process_request:L 81] -- DEBUG -- Setting security groups to 'default' (make sure
you have SSH on)

2018-11-09 17:45:50,220 -- [ create: process_request:L 84] -- DEBUG -- Getting proper network configuration

2018-11-09 17:45:50,819 -- [ create: process_request:L 89] -- DEBUG -- Creating server

2018-11-09 17:45:52,387 -- [ create: process_request:L100] -- DEBUG -- Server not ready, yet. Status: BUILD

. . .

2018-11-09 17:46:07,618 -- [ create: process_request:L100] -- DEBUG -- Server not ready, yet. Status: BUILD

2018-11-09 17:46:07,793 -- [ create: process_request:L103] -- DEBUG -- Server is ready.

2018-11-09 17:46:07,793 -- [ create: process_request:L105] -- DEBUG -- Attempting to add floating IP to server 025eb1e8-
0106-4d77-9ed5-d8876b590093.

2018-11-09 17:46:07,794 -- [ network: _get_floating_ip_network:L 55] -- DEBUG -- Getting the floating IPs of the project

2018-11-09 17:46:07,844 -- [ network: _get_floating_ip_network:L 69] -- DEBUG -- Available floating IP: 192.168.1.228

2018-11-09 17:46:08,189 -- [ network: get_floating_ip:L125] -- DEBUG -- Delivering existing floating IP with details:
{u'router_id': None, u'status': u'DOWN', u'description': u'', u'tags': [], u'tenant_id': u'8b938b5f678e4eaf84e445a0dbcea126',
u'created_at': u'2018-11-09T12:11:27Z', u'updated_at': u'2018-11-09T15:54:15Z', u'dns_domain': u'', u'floating_network_id': u'4fcf6681-
111a-402e-ace3-00a30d6699cb', u'fixed_ip_address': None, u'floating_ip_address': u'192.168.1.228', u'revision_number': 23, u'dns_name':
u'', u'project_id': u'8b938b5f678e4eaf84e445a0dbcea126', u'port_id': None, u'id': u'5b20a268-a76e-4122-bff9-30a094a2763e'}

2018-11-09 17:46:09,431 -- [ create: process_request:L112] -- DEBUG -- Success.

2018-11-09 17:46:09,432 -- [ deploy: process_request:L 50] -- DEBUG -- Running local command: bash /builds/pops/nrg-
5/cicd-os-osm/commands/local.sh 192.168.1.228

2018-11-09 17:46:09,432 -- [ deploy: process_request:L 55] -- DEBUG -- Running remote command: bash remote.sh

2018-11-09 17:46:09,433 -- [ deploy: process_request:L 56] -- DEBUG -- Make sure to have the script there :-)

Executing bash remote.sh

2018-11-09 17:46:14,494 -- [ common: run_command_over_ssh:L 77] -- WARNING -- Handled exception: [Errno None] Unable to connect
to port 22 on 192.168.1.228

2018-11-09 17:46:14,494 -- [ common: run_command_over_ssh:L 78] -- DEBUG -- Waiting for server @ 192.168.1.228 to wake up

2018-11-09 17:46:17,565 -- [ common: run_command_over_ssh:L 77] -- WARNING -- Handled exception: [Errno None] Unable to connect
to port 22 on 192.168.1.228

. . .

2018-11-09 17:46:46,902 -- [ common: run_command_over_ssh:L 77] -- WARNING -- Handled exception: [Errno None] Unable to connect
to port 22 on 192.168.1.228

2018-11-09 17:46:46,902 -- [ common: run_command_over_ssh:L 78] -- DEBUG -- Waiting for server @ 192.168.1.228 to wake up

2018-11-09 17:46:48,928 -- [ snapshot: snapshot:L 54] -- DEBUG -- Stopping server vAAA ()

2018-11-09 17:46:49,358 -- [ snapshot: snapshot:L 63] -- DEBUG -- Waiting for server vAAA (025eb1e8-0106-4d77-9ed5-
d8876b590093) to stop. Current status is ACTIVE

. . .

2018-11-09 17:46:52,031 -- [ snapshot: snapshot:L 63] -- DEBUG -- Waiting for server vAAA (025eb1e8-0106-4d77-9ed5-
d8876b590093) to stop. Current status is ACTIVE

2018-11-09 17:46:52,228 -- [ snapshot: snapshot:L 66] -- DEBUG -- Server vAAA (025eb1e8-0106-4d77-9ed5-d8876b590093)

stopped. Current status is SHUTOFF

2018-11-09 17:46:52,573 -- [ snapshot: snapshot:L 69] -- DEBUG -- Creating image with name vAAA-v1.0.rev13

2018-11-09 17:46:52,574 -- [ snapshot: process_request:L 95] -- DEBUG -- Got snapshot UUID bda24d47-c4c2-414e-9d15-7cc165

2018-11-09 17:46:52,608 -- [ snapshot: process_request:L106] -- DEBUG -- Image is not ready, yet. Status is queued

. . .

2018-11-09 17:47:23,148 -- [ snapshot: process_request:L106] -- DEBUG -- Image is not ready, yet. Status is saving

2018-11-09 17:47:24,264 -- [ snapshot: process_request:L103] -- DEBUG -- Image is ready

2018-11-09 17:47:24,529 -- [ delete: process_request:L 52] -- DEBUG -- Deleting server 9d36ec7a-2c6f-46ec-8faa-

ecac94e7366d

Figure 7: CI/CD job logs.

Notably, when running, in the private GitLab runner the Docker engine hinted over the CI/CD operations
taking place as shown in Figure 8.
© The NRG-5 consortium partners, 2017 62
H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Figure 8: Depiction of the CI/CD job running on a private GitLab Runner instance.

In the end of the exemplary execution process, OpenStack reported the existence of the newly created
VNF image:

Figure 9: OpenStack dashboard indicating the successful creation of the VNF snapshot.

At GitLab level, the indication that the CI/CD operation was successfully executed was as in the
following:

© The NRG-5 consortium partners, 2017 63

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

Figure 10: GitLab CI/CD job being successfully conducted.

5.4.1 The NRG-5 CI/CD framework

The NRG-5 CI/CD framework is composed of a structured set of files and directories that jointly
undertake the creation of the target VM, the code deployment, the target VM snapshotting, the OSM
update and the target VM deletion. Figure 11 presents the file and structure of the project, whereas the
following text indicates the areas of interaction with the NRG-5 CI/CD scripts:
 The commands directory contains the local and remote files to be executed inside the build docker
container and the target VM, respectively;
 The src directory contains the code of the VNF;
 The keys directory contains the .pem file for connecting to the target VM (should be named as
$OS_KEYPAIR.pem);
 The nfv directory contains the code related to updating the OSM catalogue;
 The settings directory contains a file for setting some optional settings;
 The vim directory contains the code related to handling the VIM actions. The actions
subdirectory of the openstack subdirectory (implicitly, more VIMs may be added by following the
existing code conventions) contains code related to orchestrating OpenStack commands towards
achieving the VM creation/snapshotting/deletion whereas the utils subdirectory contains utilities
and auxiliary functions wrapping OpenStack services functionalities (pertaining to the Identity,
Compute, Network, Image) and facilitating interaction with the host operating system.

$ tree .
.
├── __init__.py
├── commands
│ ├── local.sh
│ └── remote.sh
├── keys
│ └── osm.pem
├── nfv
│ ├── __init__.py

© The NRG-5 consortium partners, 2017 64

H2020-ICT-762013: NRG-5
D4.2: Integration Guidelines & Open DMP v2

│ └── osm
│ ├── __init__.py
│ └── v4
│ ├── __init__.py
│ └── update_vnf.py
├── requirements.txt
├── settings
│ ├── __init__.py
│ └── settings.py
├── setup.py
└── vim
├── __init__.py
└── openstack
├── __init__.py
├── actions
│ ├── __init__.py
│ ├── create.py
│ ├── delete.py
│ ├── deploy.py
│ └── snapshot.py
└── utils
├── __init__.py
├── common.py
├── compute.py
├── identity.py
├── image.py
├── log.py
└── network.py

10 directories, 26 files
Figure 11: The file and directory structure of the project.

The code will be made publicly available during the next months at the project source code repository
[53].

© The NRG-5 consortium partners, 2017 65