#  Introduction

This document describes the data management life cycle for the data to be
collected processed and/or generated by GAUSS, since it postulates as a
beneficiary of the Open Research Data Pilot (ORD pilot); it has been developed
following the H2020 guidelines and template [1].

It includes information on: the handling of research data during and after the
end of the project; what data will be collected, processed and/or generated;
which methodology will be applied; whether data will be shared/made open
access; and how data will be curated and preserved (including after the end of
the project).

The Data Management Plan (DMP) is intended to be a living document in which
information can be made available on a finer level of granularity through
updates as the implementation of the project progresses and when significant
changes occur; therefore this is a first version and it may be updated should
the need arise [2].

The ORD pilot aims to improve and maximise access to and re-use of research
data generated by Horizon 2020 projects and takes into account the need to
balance openness and protection of scientific information, commercialisation
and Intellectual Property Rights (IPR), privacy concerns, security as well as
data management and preservation questions. According to European Commission
figures [3] approximately an average of 67% of H2020 proposals opted in this
initiative in the period 2014-2016.

Research data will be findable, accessible, interoperable and reusable (FAIR),
to ensure it is soundly managed. Good research data management is not a goal
in itself, but rather the key conduit leading to knowledge discovery and
innovation, and to subsequent data and knowledge integration and reuse.

Several studies indicate that openness increases citations [4], which will be
a key asset for dissemination of GAUSS’ outcomes and “openness also improves
reproducibility of your research results – and it might introduce new and
perhaps unexpected audiences to your work” [5].

Nevertheless, sharing some information and data could be harmful not only for
the consortium and its members but also for drone operations. This is why,
although general guidelines are explained in this document, a consortium
decision  1  will be made in an individual basis before sharing any specific
information outside the consortium and/or making some information public,
besides the deliverables that were stated as public in the Project Management
Plan [6].

Some H2020 projects contemplate data management as one of the goals of the
project, for example to create or populate a database ( [7], [8]) or to
perform statistical studies and correlations ( [9] [10] [11]). On the other
hand, in this project data is used as a mean to develop the GAUSS system and
therefore the amount of data and information to publish and distribute at the
end is reduced and it will probably be focused on the form of written reports
and articles; nevertheless, other information is likely to be also published,
as it is explained in this document.

##  Structure of the document

The current Section 1 introduces the document and briefly describes the
information included.

Section 2 summarises the main type of data that GAUSS will work with.

Section 3 describes the procedures that will be followed to ensure that the
main research GAUSS data is as FAIR  2  as possible.

Section 4 describes how the costs related to data management will be assumed
within the project.

Section 5 deals with data security issues.

Section 6 briefly describes potential ethical aspects

#  Data summary

GAUSS will both collect and generate information; the former is essential to
have a proper view and knowledge of current technologies: UTM operation (WP2),
Positioning (WP3), Integrity and Security (WP4) and UTM technologies (WP5).
Furthermore, outputs from GAUSS will include technical reports (D3.2, D4.2,
D5.2, etc.) and also operational definition and requirements (D2.1, D2.4,
etc.).

This data generation will allow defining RPAS systems which will improve
precision, safety and security and will optimize their usability by improving
their coordination and enhancing their compatibility; these concepts are fully
aligned with the project objectives.

The most common format will be reports in the form of .pdf files and
datasheets, since they are an easy way to present post-processed data. GAUSS
includes both unitary and laboratory tests together with field trials, these
activities will generate huge amount of raw data in several formats: pictures
and videos for visual proofs, .txt/.csv files for GNSS locations, .kml for
wide use of geoposition information, etc.

Most data obtained during the unitary tests will be used to update and modify
the different systems that will be developed in order to fulfil GAUSS
objectives and furthermore successfully perform the final field trials.

Data will come from different sources depending on whether it is collected or
generated:

❑ Collected data:

  * GAUSS partner knowledge 

  

  * Proactive research 

  

  * Feedback from AB and stakeholders. 

  

  * Open source code ❑ Generated data: 

  

  * GAUSS partner internal development 

  

  * Tests 

  

  * Field trials 

  

Due to the complexity of the project and its duration collected and especially
generated data will be of considerable size. However, most of this size will
be due to raw experimental data (experiments and trials generate huge amounts
of data that need to be processed to elaborate results) and an effort will be
made to summarize such data to make it human-understandable and to eliminate
irrelevant or repetitive data that do not add value to the project, in order
to keep overall data size to a minimum.

##  Collected data

In order to develop GAUSS systems, each partner will gather data; this kind of
information will be managed by each partner individually and it is not
expected to be shared/published outside the consortium on behalf of GAUSS.
Therefore, this report does not focus on these type of data.

Some examples and sources of these type of data are papers,
journals/magazines, webpages information, other R&D projects  3  , etc. and
the most common formats are: .pdf and other office formats.

##  Working data

This type of data will be generated by different partners within the
consortium in order to design/develop the GAUSS systems they are responsible
for. Similar to the previous type of data, working data is not expected to be
shared/published outside the consortium on behalf of GAUSS. Therefore, this
report does not focus on these type of data.

Some examples of these type of data are assessment reports, datasheets,
minutes, etc. and the most common formats are: .pdf and other office formats.

##  Generated data

Finally, GAUSS will generate some data as outcome and results of the project,
some of these will become relevant information which will be of public domain
and therefore published, some information will only be shared among relevant
stakeholders (advisory board and other H2020 projects) and other information
will be confidential and will not be published; this report focuses on the
former two.

Several type of files are expected for this purpose:

  * Reports in the form of .pdf files. Some of GAUSS reports will be public, according to the 

  

GAUSS PMP (Project Management Plan) [6]: D2.1-Design of UTM Concept of
Operations; D2.2-Definition of UTM Scenarios and use cases report; D4.1-Report
on EGNSS securityenabling features relevant for RPAS; D6.4-First trials
results report; D6.5-Second trials results report; D6.6-Performance results
analysis and conclusions.

  * Presentations in the form of .pdf files; for example for GAUSS workshops or public events. 

  

  * Telemetry files with information of location and parameters to be assessed for each flight, mainly flight plans and 4D trajectories, GNSS signal integrity, GNSS signal security and security of UTM communications to name a few)  4  . This is expected to be a .csv file in order to increase dissemination potential since they are easy to work with and manipulate [12]  5  . The main source of these type of files will be the field trials where it is expected that for each flight of each aircraft a series of three telemetry files will be generated: 

    * Information coming from the current positioning system. 

  

    * Information coming from the GAUSS positioning system. 

  

    * True location information (coming from RTK or DGPS). 

  

  

Telemetry files will also be generated by means of a simulator (Gazebo
Simulator).

_Figure 1: example of a telemetry csv file_ 6

Overall GAUSS data will be useful to RPAS industry and ATM/UTM/U-space
community and lowlevel technical information will be useful for industries
related to RPAS such as OEM and R&D centres that could build their
developments on GAUSS information; other (present and future) R&D projects
(including H2020) could use this information like “Collected data” to design
and develop their systems.

#  FAIR data

##  Making data findable, including provisions for metadata

Files produced during the project will be tagged accordingly to ease their
discovery and access; furthermore, since GAUSS involves a high level of
experimental activities, raw data will be generated and their metadata
associated will also be managed.

In order to maximise accessibility to GAUSS results a straightforward naming
convention and keywords will be used together with a coherent and detailed
versioning; such keywords will include "European Union (EU)", "GSA",
“Galileo”, “EGNOS”, “GNSS”, “UTM”, “UAS”, “U-Space”, “satellite navigation
system”; the name of the action, acronym and grant number; the publication
date, and length of embargo period if applicable, and a persistent identifier
(DOI). DOI identifiers will be used to cite reports and data sets, they are
supported by most file repositories and its implementation will ease the
process of identifying content in addition to provide a persistent link to its
location on the Internet. The naming convention used for deliverables is the
following (following the internal nomenclature of GAUSS):

GAUSS-D _ <Deliverable code> _ \- _ <Deliverable name> _ -v _ <VV> _

where: <VV> is the Version number of the delivery. The naming convention in
place instructs to use underscores “_” instead of blank spaces “ “ and avoid
special characters such as “~ ! @ # $”. Where relevant, date designators will
be used with the following format: YYYYMMDD. This format makes sure that all
files can be sorted in chronological order.

In case metadata information is useful to be included in the files, several
standards will be assessed focusing on generic standards since a specific
standards for GAUSS metadata files has not been found; an initial assessment
has been performed, see Table 1.  
  
<table>  
<tr>  
<th>

**Metadata standard**

</th>  
<th>

**Brief description**

</th> </tr>  
<tr>  
<td>

**Data Package**

</td>  
<td>

Generic wrapper format for exchanging data.

</td> </tr>  
<tr>  
<td>

**ISA-Tab**

</td>  
<td>

General purpose to collect and communicate complex metadata

</td> </tr>  
<tr>  
<td>

**PREMIS**

</td>  
<td>

Defines a set of metadata that most repositories of digital objects work with

</td> </tr>  
<tr>  
<td>

**ISO 19115**

</td>  
<td>

Schema used for describing geographic information and services

</td> </tr>  
<tr>  
<td>

**Dublin Core**

</td>  
<td>

Basic, domain-agnostic standard and one of the most widely used as a metadata
standard. It is included in the OpenAIRE guidelines [13].

</td> </tr> </table>

_Table 1: potential standards for metadata [14]._

##  Making data openly accessible

Some deliverables will be publicly available (D2.1, D2.2, D4.1, D6.4, D6.5 and
D6.6) and other project information might be made public if agreed by all
partners and PO. In this sense, some GAUSS partners (especially research
centres) will publish scientific/technical publications  7  regarding their
field.

GAUSS results that are to be publicly available will be made accessible via
Zenodo (see Section 3.2.1 for further information), an open source repository,
although publication in other directories will also be encouraged. EVADS will
manage the upload and submission of the files to Zenodo although such files
are to be provided by the partner responsible of the task associated to each
file within the scheduled deadlines.

Some software implementations, especially regarding WP5, will be made openly
available by USE in Github.

Furthermore, in order to maximize project dissemination, some results are
likely to be published in scientific journals and GAUSS website, see [15] for
a potential list of scientific journals and public reports. EVADS will manage
the upload and submission of the deliverables to the website although they are
to be provided by the partner responsible of the task associated to the
deliverable within the scheduled deadlines.

###  3.2.1 Zenodo

Zenodo [16] is an interdisciplinary open research data repository service
built and operated by CERN and OpenAIRE that enables researchers from all
disciplines to share and preserve their research outputs, regardless of size
or format.

Other repositories were assessed [17] and Zenodo was chosen for its
simplicity, its wide use (Figure

2 shows how Zenodo is widely used among H2020 projects) some partners’
previous experience  8  and their relation with CERN and OpenAIRE.
Furthermore, Zenodo also contemplates the use of API.

A persistent identifier (DOI) is issued to every published record on Zenodo.
This is a top-level and a mandatory field in the metadata of each record which
helps to make uploads easily citable.

In order to upload data to Zenodo GAUSS consortium has created a project
account and all files to be made public will be submitted through this account
to maximize dissemination and project awareness. Files may be downloaded
directly without the need an account, which will increase dissemination reach.

Files uploaded to Zenodo have a size limit of 50 Gb (GAUSS files will be much
lighter that this) and will be retained online for the lifetime of the
repository, which is the same than for the CERN laboratory (the host) and it
has an experimental program defined for the next 20 years at least [18].
Metadata is exported in several standard formats such as MARCXML, Dublin Core,
and DataCite Metadata Schema [16].

Restricted access can be configured on Zenodo although this is not expected to
be used since the repository will be used to upload public information.

Furthermore, Zenodo provides analytics of uploaded information which will be
used for analysing dissemination impact, [19] and [15].

_Figure 2: Top 20 data providers for H2020 publications [20]._

##  Making data interoperable

As it has been explained in Section 2, data to be published will be in very
common formats so it is expected that they will be easily used by external
parties (researchers, institutions, organisations, etc.).

Standards could be used at some times for specific files and information
summarised in reports will also include a detailed glossary of the specific
notations used along the document to ensure concepts are clearly defined.

##  Increase data re-use

In order to maximize information reach and ease their access, GAUSS data
publicly available will be published under “Attribution-ShareAlike 4.0
International (CC BY-SA 4.0)”  9  as soon as possible and at the latest of
publication.

One of the main goals of GAUSS’ is to help in defining future drone
regulations so it is expected that most of GAUSS’ outcomes will be further
used.

Data to be published will be subject to quality assurance procedures (further
explained in [6] and [21]).

#  Allocation of resources

Most of this FAIR initiative will not involve direct costs such as licenses,
software or hardware since open source third parties servers and technologies
will be used to host public data (see Section 3.2). Nevertheless, it will
require spending time in managing such data (receiving, selecting, adapting,
uploading, etc.) which has been contemplated within the management activities
of both the project (WP1) and the dissemination activities (WP7). Although the
final upload to the repository and/or website will be performed by EVADS, each
partner is to deliver the required files to be uploaded within the agreed
deadlines.

Some activities with a direct cost associated have been contemplated (such as
publications in scientific journals under payment, attendance to specific
events, etc.) in order to maximize GAUSS dissemination. This cost has already
been contemplated within travel and other goods/services costs associated to
each partner and it has been specified in the Grant Agreement.

#  Data security

As it has been explained in Section 2, GAUSS will work with different type of
data and it may be classified into some groups:

  * Internal data: this is the data that each partner works with individually within the framework of GAUSS (reports, papers, software algorithms, etc.). Each partner has measures and procedures implemented within their company (secure storage, periodic backups, malware detection, etc.) to ensure CIA triad (Confidentiality, Integrity and Availability)  10  . 

  

  * Transferred data: this is the data/information that is transferred among the consortium within the framework of GAUSS, for example deliverables preliminary versions, specification documents, field trials telemetry, etc. As it was defined in the Grant Agreement, the highest level of security of the information within GAUSS is “Confidential”, which is not as restringing as other levels (such as Classified). 

  

  * Published data: this is the data/information that is published in the website and/or the repository. As it was defined in [6] the former will be operative during the project duration and information on how the repository manages the information is included in Section 3.2. The repository allows for restricted access to specific files, but this feature is not considered relevant at this point since all the information published there will be public for dissemination purposes. 

  

#  Ethical aspects

No ethical or legal issues are expected regarding data sharing since no
private data is expected to be included in the information that will be
published. Whenever such data is gathered (pilot data, serial numbers, etc.)
it will be omitted or anonymized before submitting it.

Furthermore, information that has been obtained through external means (for
example, AIS data and FIS data) will not be shared unless explicit agreement
from their provider is obtained even when it does not contain private data.