#  1.Introduction

BADGER is a Horizon 2020 project participating in the Open Research Data
Pilot. This pilot is part of the Open Access to Scientific Publication and
Research Data programme in H2020. The goal of the program is to foster access
to data generated in H2020 projects.

Open Access refers to a practice of giving online access to all scholarly
disciplines in formation that is free of charge to the end-user. In this way
data becomes reusable, and the benefit of public investment in the research
will be improved.

The EC has provided a document with guidelines [1] and a template (see Annex
I) for projects participants in the pilot. The guidelines address aspects like
research data quality, sharing and security. According to the guidelines,
projects participating will need to develop a Data Management Plan (DMP).

The DMP describes the types of data that will be generated or gathered during
the project, the standards that will be used, the ways how the data will be
exploited and shared for verification or reuse, and how the data will be
preserved.

This document has been produced following these guidelines and aims to provide
a consolidated plan for BADGER partners in the data management plan policy
that the project will follow. The document is the second version of the DMP,
delivered in M18 (June 2017) of the project. The DMP will be updated
periodically, every 6 months, during the lifecycle of the project.

##  1.1 Background of the BADGER DMP

The BADGER DMP will be written in reference to the Article 29.3. in the Model
Grant Agreement called “the open access to research data” (research data
management). Project participants must deposit their data in a research data
repository and take measures to make the data available to third parties. The
third parties should be able to access, mine, exploit, reproduce and
disseminate the data. This should also help to validate the results presented
in scientific publications. In addition, Article 29.3 suggests that
participants will have to provide information, via the repository, about tools
and instruments needed for the validation of project outcomes.

The DMP will be important for tracking all data produced during the BADGER
project. Article 29.3 states that project beneficiaries do not have to ensure
access to parts of research data if such access would lead to a risk for the
project’s goals. In such cases, the DMP must contain the reasons for not
providing access. According to the aforementioned DMP Guidelines it is planned
that research data management projects funded under H2020 will receive support
though the research Infrastructures Work Programme 2014-15 (call 3
e-Infrastructures). Full support services are expected to be available only to
research projects funded under H2020, with preference to those participating
in the Open Research Data

Pilot.

#  2.BADGER Data Management Plan

##  2.1 The BADGER Data Management portal

BADGER will develop a data management portal as part of its website. This
portal will provide to the public, for each dataset that will become publicly
available, a description of the dataset along with a link to a download
section. The portal will be updated each time a new dataset has been collected
and is ready for public distribution. However the portal shall not contain any
datasets that should not become publicly available.

The initial version of the portal will become available during the second half
of the 2  nd  year of the project, in parallel to the establishment of the
first versions of project datasets that can be made publicly available. The
BADGER data management portal will enable project partners to manage and
distribute their public datasets through a common infrastructure.

##  2.2 Datasets naming conventions

Concerning the convention followed for naming the BADGER datasets, it should
be noted that the name of each dataset comprises: (a) a prefix ‘DS’ indicating
a dataset, along with its unique identification number, e.g. ‘DS1’, (b) the
name(s) of the partner(s) responsible to collect it, e.g. SILO, along with an
identifier denoting the internal numbering of the dataset concerning the
specific partner, e.g. -01 and (c) a short title of the dataset summarizing
its content and purpose,

e.g. Underground Object Recognition Dataset.

##  2.3 Summary of foreseen BADGER datasets

In the following, Table 1 provides a list of the expected datasets, whereas
the detailed description of each dataset, in accordance to the H2020 DMP
template is provided in the following sections. At this stage (M18) there are
five datasets foreseen in the project, covering a series of research
dimensions on the skills the BADGER robot should develop. In the course of the
project more Datasets will be added in the Data Management Plan.

**Table 1. Summary of foreseen BADGER datasets (as of month 18)**  
  
<table>  
<tr>  
<th>

**No**

</th>  
<th>

**Dataset name**

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

1

</td>  
<td>

DS1_CERTH_GPR_Measurements

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

2

</td>  
<td>

DS2_TT_01_System_Requirements

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

3

</td>  
<td>

DS3_TT_02_Pilot_Experiments

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

4

</td>  
<td>

DS4_UoG_Ultrasonic_System

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

5

</td>  
<td>

DS5_UC3M_Control_system

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

6

</td>  
<td>

DS6_CERTH_Surface-Subsurface_Mapping

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

#  3.Datasets Description

In this paragraph, we provide detailed information about the datasets that are
planned to be captured by the partners of the BADGER project. These are the
foreseen datasets as of month 18 of the project. More datasets will be
included in the course of the project and the DMP will be updated every
semester.

In order to meet the requirements of the DMP according to the Pilot Open
Access of the Horizon 2020, each partner provided the description of their
datasets using the template given in Annex I, which was formed by following
the EC guidelines of the dataset aspects that should be reported in DMPs of
the H2020 projects.

Based on this information, partner SILO compiled the following tables.  
  
<table>  
<tr>  
<th>

**DS1_GPR_Measurements**

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

**Data description**

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

The GPR measurements dataset is collected due to the need for formulation of
consistent radar images during the surface rover navigation. The data to be
collected will be used for the detection of buried objects, such as pipes.
Also, a synthetic dataset is generated for training of the related algorithms.

The data will allow the training of the object detection algorithms to be
developed.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

IDSGEO and CERTH

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

Partner in charge of the data collection

</td>  
<td>

CERTH

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

Partner in charge of the data analysis

</td>  
<td>

CERTH

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

Related WP(s) and task(s)

</td>  
<td>

WP4

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

**Standards**

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

Info about metadata (production and storage dates, places) and documentation.

</td>  
<td>

tbd

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

Standards, format

</td>  
<td>

The data collected consist of raw GPR measurements in plain text (ASCII)
format. Other formats will be available, such as images (.png, .jpeg).

Also, data in .hdf5 and .out formats are generated by gprMax software.

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

Estimated data size

</td>  
<td>

The size of the files varies between 200KB – 20 MB.

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

Existing data are utilised for initial calibration of the GPR processing
algorithms. These data are provided by IDS Georadar.

The data will be useful to geoscience engineers by allowing further research
regarding GPR signal processing. These datasets will enable training of object
detection algorithms, as well as extracting of quantitative results

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

</td>  
<td>

regarding methods accuracy and robustness.

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

Data access policy/ dissemination level

</td>  
<td>

The data produced and/or used in the project are useable by any interested
party aiming to use them for research and development, especially by
geoscience engineers.

Part of the dataset could be made publicly available.

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

Embargo periods (if any)

</td>  
<td>

tbd

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will be stored and be accessible at the project open-data database
that will be linked to the project webpage.

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

**DS2_System_Requirements**

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

**Data description**

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

Data is generated and collected in order to identify relevant information to
define use cases, user requirements, geological conditions, and system
functionalities. Further data in terms of technical design are generated in
order to be able to produce mechanical components.

The generation / collection of these data is necessary to fulfil the tasks of
the WP in which TT is to collaborate.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

TT

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

Partner in charge of the data collection

</td>  
<td>

TT

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

Partner in charge of the data analysis

</td>  
<td>

TT, CERTH, UC3M

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

Related WP(s) and task(s)

</td>  
<td>

WP1, WP3, WP6

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

**Standards**

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

Info about metadata (production and storage dates, places) and documentation.

</td>  
<td>

tbd

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

Standards, format

</td>  
<td>

Text (e.g. docx, pdf), calculation files (e.g. xlsx), presentations (e.g.
pptx), photos (e.g. jpg), videos (e.g. mov), CAD files (e.g. dxf)

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

Estimated data size

</td>  
<td>

tbd

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

Data will be useful to consortium members, dissemination and

exploitation partners

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

Data access policy/ dissemination level

</td>  
<td>

TT will make openly available use case information, end user requirements,
geological information, prototype information as well as test requirement /
condition data. Information about test results and test validation as well as
market and business information will not be made available so competitors
cannot make use of it. This information forms the basis of the future
commercial exploitation of the BADGER technology.

Data will be available on the BADGER website as reports and during
dissemination as presentation or articles in magazines.

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

Embargo periods (if any)

</td>  
<td>

There are no restrictions for data meant to be published.

Confidential data will not be made available for public in a foreseeable
period of time.

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will also be stored and be accessible at the project open-data
database that will be linked to the project webpage.

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

**DS3_Pilot_Experiments**

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

**Data description**

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

Data will be generated during pilot experiments at TT industrial premisses in
Lennestadt, Germany.

The generation / collection of these data is necessary to fulfil the tasks of
the WP in which TT is to collaborate.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

TT

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

Partner in charge of the data collection

</td>  
<td>

TT

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

Partner in charge of the data analysis

</td>  
<td>

TT, CERTH, UC3M

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

Related WP(s) and task(s)

</td>  
<td>

WP3, WP6

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

**Standards**

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

Info about metadata (production and storage dates, places) and documentation.

</td>  
<td>

tbd

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

Standards, format

</td>  
<td>

Text (e.g. docx, pdf), calculation files (e.g. xlsx), photos (e.g. jpg),
videos (e.g. mov), sensor and instrumentation

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

</td>  
<td>

data (blob, .txt, .csv).

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

Estimated data size

</td>  
<td>

tbd

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

Data will be useful to consortium members, dissemination and

exploitation partners

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

Data access policy/ dissemination level

</td>  
<td>

TT will make openly available use case information, end user requirements,
geological information, prototype information as well as test requirement /
condition data. Information about test results and test validation as well as
market and business information will not be made available so competitors
cannot make use of it. This information forms the basis of the future
commercial exploitation of the BADGER technology.

Data will be available on the BADGER website as reports and during
dissemination as presentation or articles in magazines.

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

Embargo periods (if any)

</td>  
<td>

There are no restrictions for data meant to be published.

Confidential data will not be made available for public in a foreseeable
period of time.

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will be stored at the project open-data database that will be linked
to the project webpage.

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

**DS4_Ultrasonic_System**

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

**Data description**

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

Data will be collected to assess the performance of the ultrasonic systems,
actuation devices, and trajectory-following performance. Simulation data will
also be collected. These outputs are required to validate the objectives of
the project.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

UoG

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

Partner in charge of the data collection

</td>  
<td>

UoG

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

Partner in charge of the data analysis

</td>  
<td>

UoG

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

Related WP(s) and task(s)

</td>  
<td>

WP2

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

**Standards**

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

Info about metadata (production and storage dates, places) and

</td>  
<td>

The data will be stored on UoG’s own repository using a unique filename and
indexing system that will provide all

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

documentation.

</th>  
<th>

appropriate test metadata.

The definition of appropriate metadata will be such that all experimental
conditions can be recreated at a later date. As this is a new project there is
no standard as yet, but key parameters will include all internal gain
settings, the power settings for the ultrasonics, actuator position histories,
trajectories, and substrate parameters including sand type, depth, and
compaction.

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

Standards, format

</td>  
<td>

This data will be stored as numerical values in time domain, in a .csv or
similar format, and will be required on all appropriate test runs.

The data we envisage will be, for the post part, time domain logs and will not
result in complex interoperability problems.

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

Estimated data size

</td>  
<td>

The file size will depend on the length of the experimental runs carried out.

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

The data will be useful for UoG as we improve our systems, and to all partners
for validation purposes.

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

Data access policy/ dissemination level

</td>  
<td>

All data will be available upon reasonable request, but only those sections
required to disseminate our work will be actively published. This is because
not all runs will be successful and, although this will not be hidden,
confusion can easily result if external partners focus on off-optimal runs.

Publication of these datasets will generally be made through supporting files
in association with our publications. Many publishers, and indeed our own
library, can support this approach.

The files will not require specialist software to open.

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

Embargo periods (if any)

</td>  
<td>

There are no restrictions for data meant to be published.

Confidential data will not be made available for public in a foreseeable
period of time.

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will be stored and be accessible at the project open-data database
that will be linked to the project webpage.

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

</td>  
<td>

Dataset will also be preserved in UoG infrastructure.

The University of Glasgow library can support persistent, accessible, and
curated data storage as part of their centrally-funded role within the
university.

The data is not expected to be

sensitive, but will be securely backedup by our library.

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

**DS5_Control_System**

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

**Data description**

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

Input-output control data will be stored, aiming at benchmarking motion
control strategies (inverse simulation or other) for underground robot
control.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

UoG, UC3M

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

Partner in charge of the data collection

</td>  
<td>

UoG, UC3M

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

Partner in charge of the data analysis

</td>  
<td>

UoG, UC3M

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

Related WP(s) and task(s)

</td>  
<td>

WP2

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

**Standards**

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

Info about metadata (production and storage dates, places) and documentation.

</td>  
<td>

ROSbag added metadata

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

Standards, format

</td>  
<td>

ROSbag format

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

Estimated data size

</td>  
<td>

The file size will depend on the length of the experimental runs carried out.

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

The data will be useful for UoG and UC3M as we improve our systems, and to all
partners for validation purposes.

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

Data access policy/ dissemination level

</td>  
<td>

All data will be available upon reasonable request, but only those sections
required to disseminate our work will be actively published.

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

Embargo periods (if any)

</td>  
<td>

There are no restrictions for data meant to be published.

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will be stored and be accessible at the project open-data database
that will be linked to the

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

</td>  
<td>

project webpage.

Dataset will be preserved in UoG and UC3M infrastructure.

The University of Glasgow library can support persistent, accessible, and
curated data storage as part of their centrally-funded role within the
university.

The data is not expected to be

sensitive, but will be securely backedup by our library.

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

**DS6_Surface-Subsurface_Mapping**

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

**Data description**

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

The Surface-Subsurface_Mapping measurements will be collected from the
integrated surface rover - GPR unit. The data will be utilized for the metric
mapping of the surface rover and the subsurface mapping required for the
navigation of the underground robot. Moreover, the subsurface data will be
used for the utility mapping of the subsurface. Data collection will be
performed at the specific test site constructed at CERTH premises, necessary
for the developing and testing of all the mapping and surface rover navigation
methods. For this purpose pipes of different type and material have been
placed on the subsurface. The electromechanically integrated surface rover /
GPR unit will be used for the data collection of stereo images, B-Scan, along
with ground-truth measurements by performing multiple traverses of the field.

The data will contribute to the 3D reconstruction of an unknown environment,
which is one of the main objectives of the project.

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

**Partners activities and responsibilities**

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

Partner owner of the data; copyright holder (if applicable)

</td>  
<td>

CERTH

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

Partner in charge of the data collection

</td>  
<td>

CERTH

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

Partner in charge of the data analysis

</td>  
<td>

CERTH

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

Related WP(s) and task(s)

</td>  
<td>

WP4

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

**Standards**

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

Info about metadata (production and storage dates, places) and documentation.

</td>  
<td>

tbd

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

Standards, format

</td>  
<td>

The data collected consist of raw GPR measurements in plain text (ASCII)
format.

Radargrams of images format (.png, jpg)

Stereo Images with Calibration data (.bag)

Timestamp synchronizaiton data in plain text (ASCII)

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

Estimated data size

</td>  
<td>

The size of the files varies between

200KB – 1 GB.

Total size of dataset expected to be ~100GB

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

**Data exploitation and sharing**

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

Purpose use of the data analysis

</td>  
<td>

The data to be produced can be utilized for the development of:

  * Outdoors mapping methods 

  

  * GPR data processing and A-Assembly methods in B-Scans 

  

  * Registered surface/subsurface recordings  Coupled surface/subsurface mapping methods 

  

  * Further processing of subsurface data for utility mapping based on the extraction o semantics. 

  

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

Data access policy/ dissemination level

</td>  
<td>

The data produced and/or used in the project are useable by any interested
party aiming to use them for research and development, especially by robotics
and geoscience engineers.

Part of the dataset could be made publicly available.

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

Embargo periods (if any)

</td>  
<td>

tbd

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

**Archiving and preservation (including storage and backup)**

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

Data storage. Where? For how long?

</td>  
<td>

The data will be stored and be accessible at the project open-data database
that will be linked to the project webpage.

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

#  Timeline of release of datasets

Most of the datasets will be generated and released by the end of the second
year of the project. An indicative timeline for the release of the datasets
that are foreseen in the current version of the BADGER DMP is provided in
Table 2 below.

**Table 2. Timeline of the release of the datasets**

This timeplan a preliminary estimation of dataset release dates. The actual
timetable of the datasets expected to be released will be formulated
progressively, as the project evolves.

#  Data set security measures

The data set that will be generated during the Badger project does not contain
any personal data and therefore does not raise any issues with respect to the
GDPR regulation.

All data collected are strictly related to the underground environment. Data
generated by the BADGER robot during the project will not contain information
of any public infrastructure, because all tests will be carried out at the
premises of TT partner, as well as in the CERTH test site. Hence, during the
3- year period of the project there are no issues raised with respect to
sensitive infrastructure information. However, in the future, the commercial
Badger system will operate on construction sites and the collected information
might include public infrastructure (utilities etc.) which might be considered
sensitive and even raise national security issues. Therefore, appropriate
security measures should be put into effect. These measures should handle
Internet, Linux-machine and Wi-Fi communication security. Also, they should
address local database storage and data export security issues. These measures
are grouped and listed below:

The following simplified architecture in **Figure 1** depicts the main
communication lines and software modules that need to be secured. All measures
explained below refer to this figure. These measures will be implemented and
demonstrated on the badger software architecture in the context of Task 5.4 in
WP5.

**Figure 1: Main Communication architecture**

**Internet communication security measures include:**

  * Use VPN connection with key pairs for authentication instead of password. The end points are the construction site PC and a Tablet or a remote PC (at a remote office). 

  

  * Configure the Linux environment at the construction site so that Root access is granted only locally. This way no remote user can access Root privileges over the Internet 

  

**Linux machine security measures include:**

  * Harden the Linux at the construction site. This means: 

  

◦ Make sure Web browser uses https

◦ Follow strict password guidelines (do not allow for default passwords, no
weak passwords, change of password on a regular basis, etc.)

◦ Configure Linux for minimum port definition (

◦ Use only SSH

  * Harden the Apache server 

  

  
<table>  
<tr>  
<th>

◦

</th>  
<th>

Allow communication only through 443 port (installation of SSL certificate)

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

◦

</td>  
<td>

Disable directory listing

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

◦

</td>  
<td>

Disable not necessary modules

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

◦

</td>  
<td>

Restrict access to directories

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

◦

</td>  
<td>

Use mod_evasive and mod_security modules

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

◦

</td>  
<td>

Limit the default size of requests

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

**Wi-Fi security measures include:**  Use of WPA2 protocol **Database
security include:**

  * Encryption of the data which is exported. Encrypted data will be exported using a flush disk (hence data is encrypted on transit). When data is copied to an external database it will be decrypted. 

  

  * In case data from the local database is transmitted over the Internet it should be encrypted and the transmission should be done over a secure channel such as VPN. 

  

#  Conclusions

The current document provides preliminary, yet detailed information about the
datasets that are planned to be captured by the partners of the BADGER
project. These are the foreseen datasets as of month 18 of the project. A more
complete list of datasets will be included in the future, as the project
progresses. The DMP will be updated every semester. The report also presents a
set of data security measures that pertain to the Badger applications and
collected data.

BADGER will develop a data management portal as part of its website. The
initial version of the data management portal will become available during the
second half of the 2  nd  year of the project, in parallel to the
establishment of the first versions of project datasets that can be made
publicly available.