#  Executive Summary

RESIST (Resilient Transport Infrastructure to Extreme Events) is a H2020
framework project funded under grant agreement 769066 that aims to increase
the resilience of seamless transport operation to natural and man-made extreme
events, protect the users of the European transport infrastructure, and
provide optimal information to the operators and users of the transport
infrastructure.

The project addresses extreme events on critical structures, implemented in
the case of bridges and tunnels attacked by all types of extreme physical,
natural and man-made incidents, and cyber-attacks. The RESIST technology will
be deployed and validated in real conditions and infrastructures in 2 pilots,
first taking part in Egnatia odos T9 bridge and the second in Milleures
viaduct and st petronella tunnel in Italy.

The present deliverable represents the first updated version of the Data
Management Plan for the RESIST project, describing the procedures for data
collection, storage and processing within the framework of the project that
was produced on m4 and contains all the changes and adaptations required as
proposed on the DoA.

Additional to any updates to the text, and in order to make tracking of
changes easier the author has added a table of changes, located before the
executive summary. This table includes the page number and a description to
the change / update done.

The data collected, generated or reused within the context of the project,
will be processed only for scientific reasons.

All the data related activities within the RESIST project will comply with the
requirements of the General Data Protection Regulation. In parallel, RESIST is
part of the Pilot on Open Research Data so it will make sure that it follows
the FAIR principles thus making its data Findable, Accessible, Interoperable
and Re-usable.

This deliverable provides a brief description of the data managed by RESIST.
In principle, it’s worth noting that only pseudonymous or anonymous (depending
on the case) data that are necessary for the scientific analyses are expected
to be stored in the long term in RESIST databases hosted in secured servers
that will be regularly backed up, and accessible only by authorised users.

The consent of the users to the processing of their data will be asked prior
to their involvement in any of RESIST activities, upon being well informed on
the project’s nature. Additionally, users will have the option to easily
withdraw their consent and to exercise their rights deriving from the General
Data Protection Regulation, such as the right to be forgotten.

The RESIST outputs in terms of deliverables and/or any project outcomes
related scientific publications will be named and indexed with appropriate
keywords and will be available via the project website and in research fora.

_Keywords: Data Management, Protection of Personal Data, Informed consent,
Open Research Data Pilot, FAIR data._

#  Introduction

##  Participation in the Open Research Data Pilot

RESIST participates in the Pilot on Open Research Data launched by the EC
along with the Horizon2020 programme. The consortium supports open science,
and the large potential benefits to the European innovation and economy
stemming from allowing reusing data at a larger scale. Therefore, the majority
of data produced by the project will be published with open access. This
objective will obviously need to be balanced with the other principles
described below.

##  Objectives of the Deliverable

The overall objective of this deliverable is to update the RESIST Data
Management Plan with all and any updates have occurred from the evolvement of
RESIST technologies while keeping the spirit of the original DMP intact.. All
the principles and goals stated in the D 1.4 deliverable remain unchanged.
Those principles aim to improve and maximize access and re-use of research
data generated by Horizon 2020 projects and takes into account the need to
balance openness with the protection of scientific information,
commercialization and Intellectual Property Rights (IPR), privacy concerns,
security as well as data management and preservation questions. Dedicated
deliverables on Ethics such as “D12.1 H-requirements No.1” and “D12.2 POPD -
Requirement No. 2” are devoted to explain how the RESIST project activities
are complying with Protection of Personal Data (POPD) requirements established
by the EC and national regulations, as well as with GDPR with respect to the
privacy of EU citizen. The data management plan describes the principles on
data security to show how data are being collected, stored, documented, shared
and reused during and after the project’s lifecycle.

Some points raised and decisions reflected in this document that used to be
tentative since they required further specification of the tools and
platforms, along with the research in the Work Packages (WP) are now clearer.
However, the document will further updated according to findings project
developments since it is considered a living document that needs to be updated
over the course of the project when needed, or on-demand, when changes in
policies by the EU Commission or the local authorities or when a new
innovation potential has been identified. The RESIST Executive Board has the
responsibility to decide on changes.

##  Structure of the deliverable

The deliverable structure is as follows:

The first chapter offers a general introduction describing the participation
on the Open Research Data Pilot, the objectives of the data management plan,
the structure of the deliverable and the intended readership.

Chapter 2 offers a _current_ brief descriptive summary of the project data,
linked to the scope and relative objectives.

Chapter 3 sketches out the guidelines on FAIR data management and deals with
how the RESIST consortium will make sure that the data generated or used
follow the principles of FAIR data.

Chapter 4, discusses the allocation of resources related to the Open Research
Data Pilot.

Next, on Chapter 5 deals with data security matters and chapter 6 addresses
ethical issues concerning data management with reference to the deliverables
considering ethics.

Chapter 6 deals with data security provisions with respect to any data that
will be used in RESIST.

Chapter 7 is devoted to data protection in general describing the general
principles, matters regarding the data subject, cybersecurity and privacy
related information, and measures to be taken by RESIST.

Chapter 8 deals strictly with the protection of personal data in RESIST.

Chapter 9 concludes deliverable scope and main outcomes.

Finally, in the annexes section, presents the list of public deliverables.

##  Intended readership

This deliverable is intended for a public use aiming primarily at the
participants of RESIST, to inform them on how data are being collected,
stored, documented, shared and reused in the project’s lifecycle. In addition,
from a general dissemination strategy point of view, it may also be useful for
other H2020 projects

#  RESIST Data Summary

This section aims at providing an updated overview of the data collected and
produced in the context of RESIST, including details about:

  * The purpose of the data collection/generation and its relation to the objectives of the project 

  

  * The types and formats of data that the project will generate/collect 

  

  * The re-usability of any existing data 

  

  * The origin of the data 

  

  * The expected size of the data 

  

  * The data utility 

  

In RESIST, data collection and generation are key aspects in the sense that
the major project’s objective is to develop an integrated, interoperable and
scalable safety/security platform to offer high levels of resilience and
secure the nearly seamless transport operation in the event of critical
structures suffering all types of extreme physical, natural and man-made
incidents and cyber-attacks.

It networks in a unified manner the targeted groups: transport control room
operators, first responders and citizens/users to enable gathering, processing
and disseminating information for alternative planning in order to speed up
communication in real time, a factor that contributes to the seamless
transport operation.

This materializes in a multi-level approach which includes tools and
technologies for designing both preventive and predictive strategies for
transport network resilience in terms of vulnerability and predictive analysis
and risk assessment, as well as reactive ones in terms of emergency secure
communication and on demand rapid and accurate robotic in-depth structural
damage inspection of critical transport structures after disaster for offering
situation awareness to the control and (re)routing options to the users.

Following comes an analysis of the data types utilized by RESIST and their
origin. Their use will be also presented briefly in the sections that follow,
in a data type-level by the tool type/component that will be developed.

##  Time-Dependent Degradation Models

Time-dependent degradation models will be developed for metallic
bridges/tunnels exposed to ageing and climate changes (temperature, humidity),
focusing first on the degradation of coating and then on the ensuing evolution
of corrosion as coating becomes ineffective. Corrosion progress will influence
the capacity of concrete members through reductions in rebar cross-sections
and of metallic members through reduced thickness. Thus, the final output will
be reduced rebar cross-section in concrete members and reduced thickness in
metallic members.

_**Table 1: Time-Dependent Degradation Models data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

t

</td>  
<td>

time of corrosion initiation after commissioning

</td>  
<td>

double

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

tlim

</td>  
<td>

time limit for calculation of chloride coefficient of diffusion

</td>  
<td>

double

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

C  0  
</td>  
<td>

chloride concentration on the external face of the concrete

</td>  
<td>

double

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

w/c

</td>  
<td>

Water to cement ratio

</td>  
<td>

double

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

HR

</td>  
<td>

Relative humidity

</td>  
<td>

double

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

yco2

</td>  
<td>

CO2 concentration in atmosphere

</td>  
<td>

double

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

T

</td>  
<td>

Mean temperature after

commissioning

</td>  
<td>

double

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

A  s  (t)

</td>  
<td>

Remaining resistant steel area

</td>  
<td>

double

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

ε'su

</td>  
<td>

Ultimate strength of steel

</td>  
<td>

double

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

t  cr  
</td>  
<td>

time from corrosion initiation and first crack opening

</td>  
<td>

double

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

wcrack

</td>  
<td>

crack width

</td>  
<td>

double

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

texp

</td>  
<td>

Time of rebar exposure

</td>  
<td>

double

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

SP  w  
</td>  
<td>

Width of spalling

</td>  
<td>

double

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

SP  d  
</td>  
<td>

Depth of spalling

</td>  
<td>

double

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

tleach

</td>  
<td>

Time of leaching exposure

</td>  
<td>

double

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

A  l  
</td>  
<td>

Concrete area where leaching is detected

</td>  
<td>

double

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

Stiff_red

</td>  
<td>

Stiffness reduction after leaching

</td>  
<td>

double

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

f_red

</td>  
<td>

Concrete resistance reduction Cross section dimensions

</td>  
<td>

double

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

various

</td>  
<td>

Original Rebars diameter

</td>  
<td>

double

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

d  0  
</td>  
<td>

Original concrete cover thickness

</td>  
<td>

double

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

c  0  
</td>  
<td>

Carbonation exposure class [C1-C4]. This input determines the corrosion

current density icorr_20 (in mA/cm2) for t=20°.

</td>  
<td>

index [1-4]

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

Cn

</td>  
<td>

Chloride concentration

</td>  
<td>

double

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The collected data are geographic (region, temperature, humidity) and
structural (structure of the bridge and data about its structural elements,
geometrical data of cracks and defects) and shall be input in the module in
order to create a degradation model, which will calculate the deterioration
effect on the structural elements.

The types and formats of data that the project will generate/collect: The
result of the project is the model itself, which is a mathematical tool and
which will be used in the structural assessment of the bridge and, therefore,
in the integrated RESIST platform.

**The re-usability of any existing data:**

Data from previous projects will be used. Specifically, the model will be
based on other models already created, due to similarities to other projects,
such as AEROBI, 2015, which focuses on bridges, and ROBO-SPECT, 2013, which
aims at tunnels.

**The origin of the data:**

The generation and collection of data will be from the End users and the
Literature. The model will be based on data extracted, by the bridge and
tunnel handlers, information about the area, in order to specify the regional
climate conditions, previous projects with similar data.

**The expected size of the data:**

The data that will be collected, are expected to have a total size of tens of
KB.

**The data utility:**

The data will be used in the deterministic structural vulnerability assessment
of bridges and tunnels exposed to physical attacks, a crucial part in order to
estimate the defects of the bridge and evaluate the dangers of each structure.

##  Structural Vulnerability Assessment and Strengthening Intervention
Planning Tool

This Tool will help bridge/tunnel operators plan structural strengthening
interventions in order to increase resilience to specific attacks while the
results will be integrated with the BIM system for road management. A database
will be holding the construction data, relevant information from bridge/tunnel
inspections, data about the environment and operation and data on the
strengthening options. The User Interface will provide visualization of the
results, as well as current and historical data from the database. Data will
be visualized in a number of ways. Bridge components, as well as cross-
sections in these components, will change color to indicate high
vulnerability.

In the case of an incident, data on the damage and safety of structural
components and the whole structure will be sent to the crew on the scene in a
textural and graphical manner.

This Tool will enable the connection of external data
providers/databases/tools with suitable interfaces or by suitable data
exchange formats. There will be a strong commitment to interoperability.

Through this Tool the user will be able to estimate:

The internal forces and external loads applied on every point of the
bridge/tunnel members and the cross-section, component and system probability
of failure at the time of the inspection and at future times under extreme
events

The strengthening options to increase bridge/tunnel resilience to the specific
physical attacks under study.

The evolution with time of bridge damage and probability of failure in case of
monitored structures under impact.

The damage, shoring and demolition needs for each component and the overall
bridge/tunnel structure based on RPAS emergency inspection measurements of the
damaged structure.

The functionality of the damaged bridge/tunnel.

The required repair time and cost after a specific physical attack.

_**Table 2: Structural Vulnerability Assessment and Strengthening Intervention
Planning** _

_**Tool data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Input

</td>  
<td>

Bridge/ Tunnel Geometry

</td>  
<td>

String/ Double

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

Input

</td>  
<td>

Material properties

</td>  
<td>

Double

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

Input Crack

</td>  
<td>

  * Position (x,y,z) 

  

  * Type of Crack (Structural , Corrosion ) 

  

  * Length (m) 

  

  * Max Depth (m) 

  

  * Max Width (m) 

  

  * Angle (Degrees ) 

  

  * Multi Cracks (0,1,2,3) 

  

  * Distance Between multi 

  

  * Selfie of the crack 

  

</td>  
<td>

Double, image format (png/jpg)

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

Beam deflection

</td>  
<td>

Distance of 3 Fixed position (m)

</td>  
<td>

Double

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

Pier Inclination

</td>  
<td>

dx , dy

</td>  
<td>

Double

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

Defects

</td>  
<td>

  * Type of Defect (Spalling, Leaching, exposed rebar's) 

  

  * Position (x,y,z) 

  

  * Photo 

  

</td>  
<td>

String

Double

Image format (png/jpg)

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The structures’ geometry is crucial in order to create the 3D model, which
will contain any type of defect (cracks, deflection, spalling, inclination…),
as given by the inspections. Through this tool, the user should be able to
estimate the functionality of the bridge/tunnel and the user shall be able to
estimate the evolution of damage, the strengthening options as well as the
required repair time and cost after a specific physical attack.

**The types and formats of data that the project will generate/collect:**

This project will produce the structural vulnerability assessment tool, which
can export data either in text format or in more graphical ways (images, 3D
drawings of damage in the bridge).

**The re-usability of any existing data:**

There are no existing data, which will be used in this tool.

**The origin of the data:**

The designs of the structures will be provided from the operators of the
structures, and the rest of the data from other modules in the project.

**The expected size of the data:**

The collection of data is expected to have a total size of tens of Gigabytes.

**The data utility:**

The data produced in this tool are crucial to the integrated RESIST platform
and, therefore, to the end-user of the project’s platform.

##  Multirotor Flying Robot

The particular needs of sensor placement in RESIST by means of aerial robots
equipped with manipulators and the indoor navigation in tunnels will require a
new aerial robot design for the contact and non-contact inspection including
the accuracy, range of operation, duration of flight, required payload, safety
and regulations. Mechatronic concepts will be applied to design the platform,
arm and integrated control system, while the aerodynamic effects near surfaces
of bridges, and particularly tunnels, will be considered. Effort will be
devoted to increase the TRL of the RPAS and provide a solution that not only
solves technological challenges, but is also operationally efficient
(transportation, time to deploy, etc.). The robot will be integrated with all
the necessary sensors for navigation around bridges and in tunnels, and with a
high quality video camera to obtain information of the affected area and with
a laser ground station for high precision measurements of the structure.

_**Table 3: Multirotor Flying Robot data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Logged telemetry

</td>  
<td>

This dataset consists of a log data file in text file format or .csv. This log
data will contain all the telemetry information of the drone autopilot
(position, velocity, timestamp, state of drone, etc.). It will be used to
debug and improve the drone control and navigation system. The data is stored
on-board in the flying robotic system.

It will also contain sensor values.

</td>  
<td>

Text files in text file format or .csvs.

Sensor values will be float numbers.

A readme file describing the structure and meaning of each of the columns of
the log files will accompany each file. Files will be structured by date and
time of the experiment.

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

Images

</td>  
<td>

This dataset consists of image and video data of landscapes of the structure
being inspected. This data will be captured using the integrated sensors in
the drones during the experiments within the RESIST project.

</td>  
<td>

The format of this data dataset consists of raw sensor data. Metadata: The
dataset will be accompanied by text files describing if and where a drone is
located in the respective image/video data (metadata). This metadata will be
captured to be used in image recognition algorithms.

The format of these text files has not been established yet

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

Logged telemetry data collection in relevance with the multirotor flying robot
will have to do with the validation and debugging of the RPAS functionalities
developed in WP4. Other data collected will be used in a way to validate the
inspection-related functionalities that will be offered, like automated
processing of images.

**The types and formats of data that the project will generate/collect:**

Generation and collection of data regarding the RPAS are divided into two main
categories.

  * **Telemetry** : Under this category, data will be focused on measurements such as position, attitude, status, etc. Text files in .txt format or .csv file. A readme file describing the structure and meaning of each of the columns of the log files will accompany each file. Files will be structured by date and time of the experiment. 

  

  * **Images** : The collection of images directly from the on-board cameras will be offered under this task. The format of this data dataset consists of raw sensor data. Metadata: The dataset will be accompanied by text files describing if and where a drone is located in the respective image/video data (metadata). This metadata will be captured to be used in image recognition algorithms. The format of these text files has not been established yet 

  

**The re-usability of any existing data:**

Existing data from previous flights will be analyzed for calibration and
tuning of RPAS controllers and estimators. No further re-use of existing data
is anticipated.

Any archived images that will be collected (after the project’s beginning)
directly from the onboard cameras is expected to be reused in the lifecycle of
the project.

**The origin of the data:**

The generation and collection of data will be from the RPAS’s on-board sensors
such as inertial units, localization systems, camera, etc.

**The expected size of the data:**

  * **Telemetry:** The measurements that will be offered by the on-board sensors, are expected to have a total size of tens or a few hundreds of Mb. 

  

  * **Images:** The collection of images is expected to have a total size of tens of Gigabytes. **The data utility:**

  

The data collection will help in the validation of the RPAS functionalities
with a GPS-free localization and the onsite inspection-related
functionalities.

##  Photogrammetric Computer Vision System

The photogrammetric computer vision system will compute 3D measurements from
images of bridges/tunnels taken by the aerial robot. It will consist of a
software implementation and a camera system prototype for integration with the
UAV. 3D data will be computed by a structure-from-motion and dense stereo
algorithm. The system will be targeted to fulfil the specified requirements in
precision and completeness of the measurements and will be developed in such a
way, that it will integrate additional sensor measurements from the robotic
platform for robustness and efficiency.

Research will be performed to advance the state-of-the-art in terms of
accuracy, reliability and versatility and suitability to the target
application.

_**Table 4: Photogrammetric Computer Vision System data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Stereo images

</td>  
<td>

These are recorded images from the sensors

</td>  
<td>

png/jpg

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

Data collection will be used to compute 3D models and measurements of
bridges/tunnels.

**The types and formats of data that the project will generate/collect:**

The photogrammetric computer vision system will collect image data.

**The re-usability of any existing data:**

The software will be tested and evaluated on existing public datasets.

Any archived images that will be collected (after the project’s beginning)
directly from the photogrammetric computer vision system is expected to be
reused in the lifecycle of the project.

**The origin of the data:**

The generation and collection of data will be from the camera sensors.

**The expected size of the data:**

The collection of images is expected to have a total size of tens of
Gigabytes.

**The data utility:**

The data collection will help with the inspection of the observed structures,
especially in regard to detecting damages.

##  Ultrasonic Sensors

An ultrasonic sensor system will be developed to measure the Modulus of
Elasticity of concrete and steel. The ultrasonic sensors in will measure the
depth and width of cracks and the rebar diameter. To achieve sufficient
accuracy in the surface velocity measurements needed for evaluating the
Modulus of Elasticity, laboratory tests will be dedicated to the dependence of
the measurement accuracy on the stability of the contact between the
ultrasonic transducers and the material, and on the applied force on the
transducers/material interface, possibly investigating different interface
materials in order to enhance ultrasonic transmission towards the measured
structure. For crack width/ rebar diameter and void detection, optical-
acoustical devices will be used.

_**Table 5: Ultrasonic Sensors data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Crack depth

</td>  
<td>

Measured crack depth in mm unit

</td>  
<td>

Double

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

Crack width

</td>  
<td>

Measured crack width in mm unit

</td>  
<td>

Double

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

Elasticity Modulus

</td>  
<td>

Measured Elasticity modulus in GPa unit

</td>  
<td>

Double

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

Rebar/Void position

</td>  
<td>

Position of void or rebar with respect to concrete surface in mm unit

</td>  
<td>

Double

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

Rebar diameter

</td>  
<td>

Measured diameter of rebar in mm unit

</td>  
<td>

Double

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

All the reported measured parameters are fundamental in the structural health
monitoring of infrastructure and are required for in-depth structural
assessments of steel and concrete bridges/tunnels. They are strictly related
to the RESIST objective 2 (Remotely Piloted Aircraft System (RPAS) for
Inspection and Sensors’ Mounting to Critical Transport Infrastructures).

**The types and formats of data that the project will generate/collect:**

All the data are double in 32 bit format.

**The re-usability of any existing data:**

In the structural health monitoring of infrastructure is important to evaluate
the evolution of the cracks under inspection (for example analyzing variations
of cracks in term of depth and width) comparing the new acquired data with
previous measurements.

**The origin of the data:**

The parameters reported in Table 5 are measured by the ultrasonic measurement
systems developed from CNR. In particular, the crack depth, the elasticity
modulus and the rebar/void parameters are derived by using a custom
pulser/receiver ultrasonic unit controlled by using USB communication from the
drone platform. The crack width is instead measured by using an innovative
opto-acoustic ultrasonic module controlled always by USB.

**The expected size of the data:**

The data size for the ultrasonic sensor is quite limited and dependent on the
number of cracks and rebars/voids inspected. For every set of measurements the
overall data will be less than 1 Kbytes. The data size will sensibly increase
considering in addition to the essential measurement results, also the
detailed data related to the measurement itself, as the single waveforms
detected by the sensors, from where the results are derived, remaining anyway
widely below the MB range.

**The data utility:**

The measured parameters will be exploited for the assessment and management of
critical structures under extreme events.

##  Cognitive Computer Vision System

The legacy system for the identification and assessment of defects in concrete
bridges developed in AEROBI, will be extended to cover concrete tunnels and
steel bridges and tunnels. The focus will be to broaden the scope of
applicability of visual inspection workflows We are also currently exploring
was to improve the runtime of the system. Application specific system tasks,
performance requirements and contextual domain models will be mapped to verify
and enhance their hybrid vision architecture that exploits model-based and
data-driven components. Furthermore, simulation tools will be enhanced for
data generation and training and will be used in conjunction with real-data to
optimize the system design. Thus, the goal will be to bring more quantitative
understanding of modern machine learning architecture performance and to
enable algorithm designs with ability to operate on reduced amount of data.

_**Table 6: Cognitive Computer Vision System data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Images

</td>  
<td>

Images from different runs of UAV

</td>  
<td>

JPEG image

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

Meta-data

</td>  
<td>

Meta data (timestamp , sensor internal and external pose parameters)

</td>  
<td>

XML

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

3D data scans

</td>  
<td>

3D data from Photogrammetry system used in visual inspection and

measurement

</td>  
<td>

3D reconstruction/Point clouds from Photogrammetry system

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

We will collect data that will enable the testing, validation and benchmarking
of performance of the visual inspection system for crack and defect
classification. Specifically, the data will include images and videos taken
from multi-copter runs with various vantage points and scales. This data will
be the basis for offline training of the classification system, as well as
benchmarking of the visual inspection system. Manual ground truth of specific
measurements will be included as annotations in order to enable the
benchmarking and assessments of error characteristics of the measurements.

**The types and formats of data that the project will generate/collect:**

The video and image data collection and annotations along with metadata will
use readily available standards (e.g. MPEG, XML) and will be available for the
scientific community for evaluation of alternative inspection methods.

**Naming conventions** : Images and xml meta-data match in names (with changed
extension).

Image sets are organized in directories with each directory representing a
drone trial run. Within a given directory, the sequence of acquired images
have a running index.

**Standards for Meta Data creation** :

We provide a full specification of our metadata formats following the XSD (XML
Schema Definition) standard. This specification is a collection of XML files
itself, but can also be rendered as image for better visualization. When we
need to update our formats, we use semantic versioning, being the last version
the currently valid one. The version is specified in the corresponding name of
the XSD file.

On the top of the aforementioned, we follow for the annotations the standards
in the literature and adopt the ImageNet and Pascal VOC xml (human-readable
and parse-able) annotation formats as is the de-facto standard in the computer
vision machine learning domain.

**The re-usability of any existing data:**

Visual inspection data from past inspections done in the context of the
recently concluded EU H2020 project AEROBI will be used for early assessment
of vision algorithm performance and for machine learning training. This
includes data from the aerial robot is collected from multiple field trials in
Seville, Thessaloniki. The image data collected from these field trials is
roughly in the order of several Gigabytes. Image data along ground-truth
annotations are used for training machine learning algorithms.

**The origin of the data:**

The generation and collection of data will be from the UAV camera and sensors.

**The expected size of the data:**

The image data collected from these field trials is roughly in the order of
several Gigabytes.

**The data utility:**

The data collection will help with the inspection of the observed structures,
especially with regard to detecting damages. Image data along ground-truth
annotations will be used for training and validating machine learning
algorithms.

##  Radiometric Sensor

The radiometric sensor will be integrated on the RPAS so that it is fully
controlled by the robotic system. It will require the development of an
interface between the robotic system and the sensing device, as well as
configuration of the data interfaces for the data communication and exchanges.
The selected sensor is a commercially available, lightweight and small Ground
Penetrating Radar (GPR) that will be measuring the thickness and internal
features of the structural elements, such as rebars, min rebar cover etc. The
radiometric sensor interfacing that will be developed will also include system
triggering and measurement data acquisition to enable full automation of the
system at the required bridge/tunnel positions fully controlled by the RPAS.

_**Table 7: Radiometric Sensor data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

GPR

</td>  
<td>

Data obtained from GPR sensor and location coordinates (global or relative)

</td>  
<td>

Struct with location and GPR measurements at each depth

(floats)

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

Data will be collected from the radiometric sensor for internal structural
analysis of the elements being inspected. The relative location of the
measuring point with respect to the structure reference system will also be
collected.

Data collection in relevance with the multirotor flying robot will have to do
with the validation of the RPAS functionalities. Other data collected will be
used in a way to validate the inspection-related functionalities that will be
offered, like automated processing of images.

**The types and formats of data that the project will generate/collect:**

The main data will be the measurements of the radiometric sensor that will
consist in a struct or vector/matrix of float values. The location (three
float values) and possibly the orientation angles of the sensor device during
the measurement (three float values) will also be collected. **The re-
usability of any existing data:**

Existing data from previous inspections could be used jointly with the actual
measurements for the structural analysis.

**The origin of the data:**

The generation and collection of data will be from the RPAS onboard
radiometric sensor.

**The expected size of the data:**

The measurements that will be offered by the on-board sensors, are expected to
have a total size of tens or a few hundreds of Mb.

**The data utility:**

The data collection will help in the structural analysis of the elements being
inspected.

##  Vibration sensors

Vibration sensors for monitoring of structures will be implemented using
commercial MEMS accelerometers. The sensor modules will be characterized by
light weight and low-power in order to be suitable for being attached to the
structure by the RPAS and communicate in wireless mode with the control
center. They will have the ability to recognize the exceedance of thresholds.

_**Table 8: Vibration sensors data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Acceleration X

</td>  
<td>

Acceleration measured in the x-axis expressed in mg unit

</td>  
<td>

Double

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

Acceleration Y

</td>  
<td>

Acceleration measured in the y-axis expressed in mg unit

</td>  
<td>

Double

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

Acceleration Z

</td>  
<td>

Acceleration measured in the z-axis expressed in mg unit

</td>  
<td>

Double

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The vibration measurement is related to the RESIST objective 2 (Remotely
Piloted Aircraft System (RPAS) for Inspection and Sensors’ Mounting to
Critical Transport Infrastructures) where is described the possibility to
mount sensor modules on other structure under inspection for monitoring.

**The types and formats of data that the project will generate/collect:**

All the acceleration data are double in 32 bit format.

**The re-usability of any existing data:**

No re-use of existing data is anticipated.

**The origin of the data:**

The vibration is measured by using a sensor module mounted on the structure by
exploiting a tri-axial accelerometer and wireless controlled from the ground
main station.

**The expected size of the data:**

The size of the data will be dependent on the desired frequency of the
vibration measurements and it will be small for intermittent measurements and
large for continuous monitoring.

**The data utility:**

The vibration measurement will be exploited for the assessment and management
of critical structures under extreme events.

##  Ground Control Station

A fully operational Ground Control Station will be developed that will have
the following main characteristics:

  1. can be easily transported to a specific area 

  

  2. can be deployed in short time 

  

  3. is integrated with the Control Centre and compatible with the communication architecture of RESIST 

  

  4. allows a friendly interface to specify navigation commands to the aerial robot taking into consideration the specifics of bridge and tunnel inspections 

  

  5. offers the operator the required information to perform the different needed inspections 

  

  6. offers the required interfaces to manage the complete system (mission sensors, navigation system, alarms, etc.) in an integrated way. 

  

  

_**Table 9: Ground Control Station data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Flight plan

</td>  
<td>

This dataset consists of all the information relative to the planning of the
different missions for the aerial robotic vehicle. This includes the waypoints
position information in GPS or local coordinates, velocity reference, heading,
action for each waypoint, actions between waypoints, camera orientation, and
etcetera.

</td>  
<td>

All the information is stored in a text file.

A readme file describing the structure and meaning of each of the columns of
the log files will accompany each file. Files will be structured by date and
time of the experiment.

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

Satellite, terrain and 3D maps

</td>  
<td>

This dataset consists of satellite and terrain maps that can be downloaded
from third party public servers. Furthermore, 3D maps generated in the project
could be used as well in the GCS.

</td>  
<td>

This information is stored in any image format with its related metadata which
indicates the global position of the image in the world and the zoom level of
the visualizer. This applies to the satellite and terrain images. The 3D map
will be stored using images and a text file with the position of each point of
the point cloud.

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

Logged telemetry

</td>  
<td>

This dataset consists of the logged telemetry downloaded from UAV for its
analysis on the ground control station. This log data in text file format. It
will contain all the telemetry information of the drone autopilot (position,
velocity, timestamp, state of drone, etc.). It will be used to debug and
improve the drone control and navigation system. The data is stored on-board
in the flying robotic system.

</td>  
<td>

Text files in text file format.

A readme file describing the structure and meaning of each of the columns of
the log files will accompany each file. Files will be structured by date and
time of the experiment.

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The purpose of collecting the first two data categories (flight plan and maps)
is for the correct operation of the ground control station. All that data is
needed in order to be able to create, modify or for monitoring any mission for
the aerial robotic system that is going to be developed in the RESIST project.

**The types and formats of data that the project will generate/collect:**

There will be 3 types of data related to the ground control station developed
in the task 4.6 of the RESIST project. The types of data and their format is
defined as follows:

  * **Flight plan:** All the information is stored in a text file. A readme file describing the structure and meaning of each of the columns of the log files will accompany each file. Files will be structured by date and time of the experiment. 

  

  * **Satellite, terrain and 3D maps:** This information is stored in any image format with its related metadata which indicates the global position of the image in the world and the zoom level of the visualizer. This applies to the satellite and terrain images. The 3D map will be stored using images and a text file with the position of each point of the point cloud. 

  

  * **Logged telemetry:** Text files in text file format. A readme file describing the structure and meaning of each of the columns of the log files will accompany each file. Files will be structured by date and time of the experiment. 

  

**The re-usability of any existing data:**

The flight plan data will be reused as far as it is needed to repeat the same
inspection. This could be because the system is being debugged, or on the
contrary it is working correctly, and different inspections are needed during
the duration of the project or even after the end of it.

The data related to the satellite and terrain public maps will be stored and
reused if several flights on the same area are expected. If this is not the
case that data can be deleted and downloaded again from public servers in case
it is needed.

The 3D maps of the bridge will be re-used during the duration of the project
for testing multiple times in the same bridge. As the 3D map is provided by a
third-party system and not generated in the GCS, it can be deleted once it is
no longer going to be used.

There is no re-usability expected for the logged telemetry because it will be
only downloaded to the GCS for its analysis in order to debug the system.

**The origin of the data:**

The flight plan data will be generated by the user directly in the GCS. This
data can be fully manually generated or assisted by a piece of software that
helps in the generation of the different waypoints that could be repetitive
and easy to program.

The data related to the satellite and terrain public maps is downloaded from
public servers with this type of data such as Google Maps.

The 3D maps of the bridge/tunnel are provided by a third-party system and not
generated in the GCS.

The origin of the logged telemetry is the on-board computers of the aerial
robot.

**The expected size of the data:**

  * **Flight plan** : This data is expected to have a total size of tens or a few hundreds of Kb. 

  

  * **Satellite and terrain public maps** : The collection of images is expected to have a total size of tens of Gigabytes. 

  

  * **3D map and telemetry data** : These 2 types of data are expected to have a total size of tens or a few hundreds of Mb. 

  

**The data utility:**

This data collection will help in the fast and reliable validation of the RPAS
functionalities with a GPS-free localization and the onsite inspection-related
functionalities.

##  Cyber Security Mechanism Infrastructure Level and Endpoint Level

The mechanisms will focus on the security of the transport infrastructure’s
critical IT assets, as well as the RESIST platform itself and its emergency
communications. Emphasis will be given in guaranteeing the security of the
RPAS’ communication subsystems, in order to satisfactorily address security
concerns (such as jamming and control takeover attacks), which have,
typically, been overlooked before introducing drone technologies in the
various applications domains. Moreover,

In terms of the monitoring elements that will offer the real-time view of the
security posture, this involves collecting data from two levels of sources:
network infrastructure level and endpoint level. Network infrastructure level
datasets allow to observe threats in a wider scope, whereas endpoint datasets
are mostly application specific, allowing us to analyze in depth threats
specific to a certain application type. Moreover, new security mechanisms will
be developed to characterize different types of data flows using anomaly
detection techniques based on different theoretical backgrounds, learning
methods (e.g., clustering) or spatial and temporal signal processing. This
includes activities such as network traffic data analysis from the
infrastructure and end-point layers.

Automated rating and classification mechanisms based on both internal and
external knowledge will be developed. The results of the refinement process
will be used to update access control policies, while a survey of the existing
policy enforcement points, as well as identification of new ones will be
performed.

_**Table 10: Cyber Security Mechanism Infrastructure Level and Endpoint Level
data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Data gathered/generated at the network level

</td>  
<td>

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

Network flow events

</td>  
<td>

Events triggered by examining the packet traffic.

</td>  
<td>

LOG/RICH TEXT

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

Network management events

</td>  
<td>

Events triggered by examining network related operations.

</td>  
<td>

LOG/RICH TEXT

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

Firewall event and logs

</td>  
<td>

Events and auditing information for inbound/outbound traffic of the firewall.

</td>  
<td>

LOG/RICH TEXT

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

Intrusion Detection

System (IDS)

events and logs

</td>  
<td>

Events and auditing information acquired by the IDS when inspecting the
traffic with a set of rules or when an anomaly occurs.

</td>  
<td>

LOG/RICH TEXT

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

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Deep Packet inspection (DPI) results.

</td>  
<td>

Detailed examination results of packet thorough analysis.

</td>  
<td>

LOG/RICH TEXT

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

Security Testing

results

</td>  
<td>

Results generated through the security assessment of RESIST assets.

</td>  
<td>

XML

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

Monitoring events

</td>  
<td>

Events captured by the event captors.

</td>  
<td>

XML

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

**Data gathered/generated in the application level**

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

Operating System

calls/forensics

</td>  
<td>

Auditing information on operating system’s operations, like process control,
file manipulation, information maintenance and communication. Also, forensic
data, such as registry files for windows systems or /etc, /var/log files for
Linux distributions.

</td>  
<td>

LOG/RICH TEXT

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

Full packet

capture/network forensics

</td>  
<td>

Contain features such as Source IP, Destination IP, timestamps, protocol,
Payload and more.

</td>  
<td>

PCAP

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

Authentication events (at network & application levels)

</td>  
<td>

Authentication actions that take place when a component authenticates at the
network or application level.

</td>  
<td>

LOG/ RICH TEXT

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

Authorization events (at network & application levels)

</td>  
<td>

Authorization actions that take place when a component asks/gets authorization
to access a network or a specific application.

</td>  
<td>

LOG/RICH TEX

</td>  
<td>

T

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

Event/System logs

</td>  
<td>

Contain events that are logged by the operating system components. They may
contain information about changes done on devices, device drivers, system
changes, and more.

</td>  
<td>

LOG

</td>  
<td>

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

Security Testing

results

</td>  
<td>

Results generated through the security assessment of RESIST asset’s

</td>  
<td>

XML

</td>  
<td>

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

Monitoring events

</td>  
<td>

Events captured by the event captors. (e.g., for example a captor may monitor
the availability of a web server, and report if the availability changes below
a minimum value)

</td>  
<td>

XML

</td>  
<td>

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

**Data managed in regard to resilient communication service may include**

</td>  
<td>

**the following**

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

Sensor Data (Time stamped values)

</td>  
<td>

Data acquired by the sensor by measuring changes in their respective
environment (e.g. temperature sensor)

</td>  
<td>

ARRAY FLOAT]

</td>  
<td>

[TIMESTAMP,

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

Weather

information/forecast data

</td>  
<td>

Time stamped weather-related values.

</td>  
<td>

ARRAY FLOAT]

</td>  
<td>

[TIMESTAMP,

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

Video Streams

</td>  
<td>

Involve surveillance of the physical infrastructure and critical security
points.

</td>  
<td>

VIDEO FORMAT (e.g. mp4, avi etc)

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

**Data Category**

</td>  
<td>

**Description**

</td>  
<td>

**Type**

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

RPAS telemetry

data

</td>  
<td>

Data gathered remotely regarding the RPAS drones.

</td>  
<td>

LIST [FLOAT1,…,FLOATn] n

= quantity of values

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

Civilians communication data

</td>  
<td>

Alert messages-voice and text messages.

</td>  
<td>

AUDIO FORMAT & TEXT

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

Cyber Security Mechanisms in RESIST will be employed in both Network and
application layer and they will generate and collect information; in the table
below we display this data alongside a short description and its expected
type.

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

In the context of WP5 Cyber Security mechanisms will be developed/deployed
within the

RESIST framework. This is directly related to the RESIST objective 3, Cyber
Security Management Solutions (see RESIST Grant Agreement Annex A, Part B)
which aims to address 3 key aspects:

  1. Provide enhanced data collection and analysis capabilities of cyber security related incidents 

  

  2. Provide awareness, trust, transparency and information sharing pertaining to such incidents and 

  

  3. Provide more efficient reaction to the detected incidents. In the context of RESIST Cyber Security management, data related to cybersecurity monitoring will be collected and analyzed (e.g. for anomaly detection) in order to enhance the efficiency and effectiveness in the detection and reaction to related incidents. Monitor mechanism may exist in both network and application level. 

  

  

  * **Cyber Security Management Solutions**

  

Regarding Cyber Security management, data related to cybersecurity monitoring
may be collected and analyzed (e.g. for anomaly detection) in order to enhance
the efficiency and effectiveness in the detection and reaction to related
incidents.

  * **Alternative, Secure and Continuous Communications for Normal and Emergency Operations**

  

In the context of RESIST, a resilient communication node is planned that will
provide secure and continuous communication for critical elements of the
RESIST platform. This node will gather various types of data flows (from
sensor data to video streams) in order to route them accordingly.

**The re-usability of any existing data:**

No re-use of existing data is anticipated.

**The origin of the data:**

As mentioned above RESIST Cyber security mechanisms will be employed both in
the network and the application layers.

Origin of data at the Network layer

  * Firewall events 

  

  * IDS alerts 

  

  * DPI events/results 

  

  * Honeypots alerts 

  

  * Network monitoring event 

  

  * Packet captures  Flows 

  

Origin of data at the Application layer

  * Application logs 

  

  * System logs 

  

  * Security Application Testing results 

  

  * Application Monitoring events 

  

  * Authentication Events  Authorization Events 

  

**The expected size of the data:**

Regarding the logs of various security components, it’s hard to specify but
moderate to big high volume of data is expected. As for network traffic,
packets detected by the network monitors, its likely to grow considerable in
size. Moreover, authentication & authorization events produce low volume of
data. Monitoring events have low volume, usually a few KBs. In addition,
alerts generated from various security controls (ids, firewall, honeypots
etc.) produce low volume of data. Finally, security testing results also have
low volume of data, usually starting from 200KB size up to a few MBs.

**The data utility:**

Security related data: can be utilized in the cyber-intelligence domain, for
example a (e.g. full packet capture can be utilized in anomaly detection
related research to train anomaly detection models. Monitoring events and
security testing results will be used to assess the security posture of
RESIST.) Monitoring and security testing are utilizing other security related
data to conduct the security assessment, such as authentication and
authorization events, system and application logs etc.

##  Mobility Continuity Module

The module for mitigating highways’ disruptions by providing personalized re-
routing options to users is under development and currently on its Alpha
version. It is a Multimodal Collaborative Decision Making (M-CDM) tool
providing re-routing advice to the same or different transport modes to the
users (in an individual/personalized manner). This tool makes use of available
maps of the transport network, potentially of high resolution, either provided
by the road operator or commercially available or from other sources like OSM
(Open Street Maps). This way a layer map architecture (similar to the Local
Dynamic Map used in automotive applications) can be deployed, including static
information in the lower layers (lanes, barriers, green areas, etc.), while
adding dynamic information on upper layers (traffic density, fog area, traffic
light phases, vehicle trajectories etc.). At the same time, interfaces to the
system will include various internal and external (to RESIST) data. An
integrated traffic simulation software (such as the SUMO), as part of Advanced
Transport Information Systems, appropriately configured, will be used to
combine the above information to actual highway routings, while combine other
modes’ availabilities and result in the actual outputs to the enduser that
will include individual suggestions of re-routing (via all available mode
routings). The traffic simulator is able to provide modelling of intermodal
traffic systems including road vehicles, public transport and pedestrians.
Appropriate interfacing to other modes’ portals/websites will ensure
availability of other modes’ routing options that will be finally combined
into one personalized solution adapted to individual highway operators.

_**Table 11: Mobility Continuity Module data description** _  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

TripInformation

</td>  
<td>

This is a class including aggregated information about each vehicle's journey

</td>  
<td>

Complex object (DATEX II)

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

UserInformation

</td>  
<td>

This is a class including aggregated information about each user’s journey
preferences

</td>  
<td>

Compex object (DATEX II)

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

TrafficInformation

</td>  
<td>

This is a class including aggregated information regarding the traffic of a
given lane.

</td>  
<td>

Complex object (DATEX II)

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

RoadNetworkMap

</td>  
<td>

This is a map including the road network

</td>  
<td>

OpenStreetMaps (OSM)

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

RouteModeInformation

</td>  
<td>

This is a definition of available modes of transport for public transportation
schedules and associated geographic information

</td>  
<td>

General Transit Feed

Specifications (GTFS)

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

TripSuggestion

</td>  
<td>

This is a class including the proposed alternatives of a trip to a given end
user

</td>  
<td>

Complex object

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The data collected by end users and sensors will be used in order to analyze
traffic within the region of interest and to subsequently optimize travel
proposals made to end users. Therefore, through the collection and generation
of data itinerary alternatives, end user mobility continuity will be
addressed.

**The types and formats of data that the project will generate/collect:**

Traffic and data related data will follow interoperable and open standards
such as the Datex2.0 standard. RESIST formatted data will be used in order to
enable client-server based communications between the various components of
the platform.

**The re-usability of any existing data:**

Data collected by the mobility continuity platform could be re-used in order
to analyze traffic patterns within the region of interest. Such data will be
anonymized and will only consist a statistical analysis basis for any
subsequent use.

**The origin of the data:**

Data sources include personal mobile device and possibly on-road deployed
sensors.

**The expected size of the data:**

Data size will depend on the usage of the mobility continuity platform from
end users. The expected size should be within the GB range.

**The data utility:**

Data will be utilized in order to perform operations related to the mobility
continuity platform. Future use of anonymized data could include statistical
analysis of traffic data.

##  Mobile Application

Suitable software for interfacing to mobile devices of highway users will be
developed to first collect personalized information from them and then provide
them with the re-routing options from the mobility continuity module. The
application will be executed by smartphones, handheld devices or other
desktop/web applications. Development of the mobile device application will
include design of a user friendly User Interface (front-end), as well as other
characteristics, such as data routing, security, authentication,
authorisation, working off-line, and service orchestration, whenever needed.

####  Table 12: Mobile Application data description  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

TripInformation

</td>  
<td>

This is a class including aggregated

information about each vehicle's journey

</td>  
<td>

Complex object (DATEX II)

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

UserInformation

</td>  
<td>

This is a class including aggregated information about each user’s journey
preferences

</td>  
<td>

Complex object (DATEX II)

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

CurrentLocation

</td>  
<td>

This is a class including geo-

coordinates of the current location of the user

</td>  
<td>

Complex object

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

TripSuggestion

</td>  
<td>

This is a class including the proposed alternatives of a trip to a given end
user

</td>  
<td>

Complex object

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The mobile application will enable the collection of data from end users in
order to enable mobility continuity, highway driver behavior and others. Such
data is essential in providing personalized suggestions back to end users and
additionally enables the overall, social optimization of such recommendations.

**The types and formats of data that the project will generate/collect:**

Transport related data will follow standardized data models such as DATEX2.0.
Moreover data communications will be formatted according to the REST standard.

**The re-usability of any existing data:**

Data uploaded to remote RESIST modules such as the mobility continuity module,
could be re-used as per corresponding descriptions.

**The origin of the data:**

Data collected by the mobile applications will source from direct end user
data input, or on device sensors such as GPS, accelerometers etc.

**The expected size of the data:**

Data sourced by sensors or direct data depends on actual mobile application
usage. Due to potential heavy use of GPS, accelerometer sensors it could range
from MB’s to GB’s.

**The data utility:**

Data collected and generated by the mobile application will be used as input
to modules such as the mobility continuity module.

##  Module for highway users’ behaviour

The model of highway users' behavior under stress will be developed that will
provide recommendations to the control center regarding speed limits and
recommendations to the control center and the Mobility Continuity Model
regarding communication type (advisory messages, cautions, warnings and
alerts, including samples of such communication) and presentation modality
(i.e., visual-symbolic, textual, auditory etc.) with the drivers.

It will be validated in by testing selected structured scenarios, and by
implementing usability methods (e.g. expert heuristic evaluation, use cases
and personas, etc.) to evaluate its effectiveness - how do users under stress
respond to the recommendations / messages.

####  Table 13: Module for highway users’ behaviour data description  
  
<table>  
<tr>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

Data Category

</td>  
<td>

</td>  
<td>

Description

</td>  
<td>

Type

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

</td>  
<td>

**Users’ demographic parameters**

</td>  
<td>

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

Age

</td>  
<td>

</td>  
<td>

Range

</td>  
<td>

Numeric

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

Gender

</td>  
<td>

</td>  
<td>

Male/Female/not willing to specify

</td>  
<td>

Text

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

Education

</td>  
<td>

</td>  
<td>

No education, Primary education, Secondary education, Further education

</td>  
<td>

Text

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

Preferred language

</td>  
<td>

</td>  
<td>

English or local language

</td>  
<td>

Text

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

</td>  
<td>

</td>  
<td>

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

Preferred notification voice

</td>  
<td>

Male/Female

</td>  
<td>

Text

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

Country/region of origin

</td>  
<td>

From a list

</td>  
<td>

Text

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

Country/region of residence

</td>  
<td>

From a list

</td>  
<td>

Text

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

Living area characteristics

</td>  
<td>

Rural/village, small town, suburban /city outskirts, urban/city/large town

</td>  
<td>

Text

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

Socioeconomic status

</td>  
<td>

</td>  
<td>

Low, Average, High

</td>  
<td>

Text

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

Occupation

</td>  
<td>

</td>  
<td>

Employed, Self-employed, Not employed, Unemployed

</td>  
<td>

Text

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

Marital status

</td>  
<td>

</td>  
<td>

Single, Living as married, Married, Separated or Divorced, Widowed, not
willing to specify, its complicated

</td>  
<td>

Text

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

Number of children

</td>  
<td>

</td>  
<td>

Family size, Number of Kin relations

</td>  
<td>

Numeric

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

Driving license

</td>  
<td>

</td>  
<td>

in years

</td>  
<td>

Numeric

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

Driving exposure

</td>  
<td>

</td>  
<td>

Less than 10,000Km annually More than 10,000Km annually

</td>  
<td>

Text

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

Driving frequency

</td>  
<td>

</td>  
<td>

Nearly daily, 1-4 times a week, 1-3 times a month, less than once a month

</td>  
<td>

Text

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

Frequency of public usage

</td>  
<td>

transport

</td>  
<td>

Nearly daily, 1-4 times a week, 1-3 times a month, less than once a month

</td>  
<td>

Text

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

Risk proneness:

1\. “How do you see yourself - how willing are you in general to take risks?

</td>  
<td>

A 5 tick scale ranging from

(1)Never (2) rarely (3) sometimes (4) often (5) always

</td>  
<td>

Numeric

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

2\. “On a typical journey, how likely is it that you will be checked for
speeding?”

</td>  
<td>

(1) Never (2) rarely (3) sometimes (4) often (5) always

</td>  
<td>

Numeric

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

3\. If you have experienced an extreme event on the road, how would you rate
your coping in such an event?

</td>  
<td>

Extremely calm, calm, anxious, very anxious, panic

</td>  
<td>

Text

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

**Infrastructure and environmental parameters**

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

Type of extreme events

</td>  
<td>

bridge/tunnel, Man-made (e.g., severe traffic accident, terror attack…) /
Natural (e.g., extreme weather …), lighting conditions

</td>  
<td>

Text

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The module for highway users’ behavior will explore the impact of stressful
conditions on drivers’ effective operational capacity. The collected data will
include demographic parameters such as; age, gender, education, driving
experience, region (culture, percent of locals vs tourists or non-native
drivers). Furthermore, it will investigate the effect of the type of threat,
type of structure (bridge/tunnel), weather & lighting conditions, level and
type of traffic (e.g., public transportation modes, types of vehicles).

**The types and formats of data that the project will generate/collect:**

Publicly available numeric data and text will be the input of this module. The
output will be a properly formatted informative recommendations.

**The re-usability of any existing data:**

Publicly available data related to similar situations that have already been
investigated in previous EU research projects, will be used to identify the
relevant environmental and behavioral parameters and conceptually model the
users' behavior under stress. Additionally, data available from the end users
systems (TMS in the control center, demographic data from the tolls etc) will
be integrated to the module.

**The origin of the data:**

Data sources are Stakeholders, control center, end users, and the social media
interface tool. **The expected size of the data:**

Data size will depend on the number of road users and the real-time-related
information. The expected size should be within the Mb to GB range.

**The data utility:**

Data collected and generated by the module for highway users’ behavior will
provide recommendations to the control center regarding speed limits for the
threats under study, in case of drivers operating under high stress (e.g., due
to damaged bridges/tunnels) and recommendations to the control center and the
mobility continuity module regarding communication type (advisory messages,
cautions, warnings and alerts) and presentation modality (i.e., visual-
symbolic, textual, auditory etc.), to the road users, via messages to their
smart phones and/or electronic traffic signs.

##  Social Media Interface Tool

This tool will be the interface for collecting real-time and on-scene
information about the disaster event from users that are close/at the event
site, as well as pushing/publishing eventrelated information to the users of
the media (in the vicinity or not). This will be an interface tool that will
be running at the RESIST platform and connect to social media tools such as
Tweeter, Facebook, Google+ and/or other accounts of users to collect site
specific information extracted from text messages from the users. For this,
the appropriate interfacing to social networking sites will be developed based
on social media monitoring tools. Social media monitoring includes measuring
opinions and sentiment of groups and influencers. The outputs of this task
(including awareness of people/users in the vicinity (or at risk) will be
towards the risk assessment as well as the mobility continuity modules
(internal to RESIST) but also towards public (close or not to the event)
through dissemination of messages from the RESIST platform.

####  Table 14: Social Media Interface Tool data description  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Timestamp

</td>  
<td>

This is the time that the social media post was uploaded

</td>  
<td>

Text ”Datetime:2018-1220T09:13:55+00:00”

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

Location_gps

</td>  
<td>

This is the GPS coordinates of the mobile device that uploaded the post

</td>  
<td>

Point:(37.997013, 23.796357)

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

Location_position

</td>  
<td>

This is the location as identified in the submission of the post

</td>  
<td>

String: “Athens, Greece”

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

Message

</td>  
<td>

This is the content of the social media post

</td>  
<td>

String: ”This is a message”

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

Emoji

</td>  
<td>

This is the list of the emoji contained in the message

</td>  
<td>

Array: [“emoji_1”,….]

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The data collected by social media posts will be used in order to analyze the
public reactions towards the event. The collected text will be analyzed to
measure opinions and sentiment of the individuals close or not to the event
site. The tool will provide the measured characteristics internally and
externally to the RESIST platform.

**The types and formats of data that the project will generate/collect:**

Publicly available social media posts, text, ideograms and special characters,
will be the input of this tool. The output will be properly formatted
informative messages.

**The re-usability of any existing data:**

Publicly available social media posts related to similar events that have
already taken place, will be used to model the tool, identify patterns,
emotions and user behaviors.

**The origin of the data:**

Data sources are social media APIs.

**The expected size of the data:**

Data size will depend on the number of social media users and the event-
related messages. The expected size should be within the GB range.

**The data utility:**

The data will be utilized to measure opinions and sentiment of people affected
directly or indirectly by the event.

##  Software for Safety, Security Risk Assessment and Management System

Risk Assessment and Management of Critical Highway Structures under Extreme
Events, It includes the identification of major hazards and hazard scenarios,
assessment of the criticality of structures at risk for each scenario and the
identification and assessment of preventive and response measures.

####  Table 15: Structural Vulnerability Assessment and Strengthening
Intervention Planning Tool data description  
  
<table>  
<tr>  
<th>

**Data Category**

</th>  
<th>

**Description**

</th>  
<th>

**Type**

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

Scenario

</td>  
<td>

List of the use cases identified by the requirements outputs

</td>  
<td>

String

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

Probability

</td>  
<td>

Probability of accurance for the scenario

</td>  
<td>

double

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

**The purpose of the data collection/generation and its relation to the
objectives of the project:**

The data collected will be used for identification and monetization of the
impact of successful threat scenarios that heave been modelled and to assess
the probability of occurrence of the above scenarios.

**The types and formats of data that the project will generate/collect:** All
the data are double in 32 bit format and Strings.

**The re-usability of any existing data:**

No re-use of existing data is anticipated.

**The origin of the data:**

Most of the data will be part of the output from WP3, WP4, WP5 and WP6.
Moreover, data from the Literature are going to be used.

**The expected size of the data:**

Data size will depend on the number of scenarios that are going to be defined.
The expected size should be within the MB range.

**The data utility:**

The data collected and generated by the module will enable the Infrastructure
manager all to identify vulnerabilities of the specific transport structures
under study to the specific threat scenarios.

#  Making RESIST data FAIR

In 2016, the ‘  FAIR Guiding Principles for scientific data management and
stewardship’  [6] were published in _Scientific Data_ . The authors intended
to provide guidelines to improve the findability, accessibility,
interoperability, and reuse of digital assets. The principles emphasize
machine-actionability (i.e., the capacity of computational systems to find,
access, interoperate, and reuse data with none or minimal human intervention)
because humans increasingly rely on computational support to deal with data as
a result of the increase in volume, complexity, and creation speed of data.

The data that will be generated during and after the project must follow the
“FAIR” principles. Such requirement does not affect implementation choices and
does not necessarily suggest any specific technology, standard, or
implementation solution.

The FAIR principles were generated to improve the practices for data
management and datacuration, and FAIR aims to describe the principles in order
to be applied to a wide range of data management purposes, whether it is data
collection or data management of larger research projects regardless of
scientific disciplines.

With the endorsement of the FAIR principles by H2020 and their implementation
in the guidelines for H2020, the FAIR principles serve as a template for
lifecycle data management and ensure that the most important components for
lifecycle are covered.

This is intended as an implementation of the FAIR concept rather than a strict
technical implementation of the FAIR principles.

##  Guidelines on FAIR data management in H2020

RESIST aims to follow the requirements stemming by the H2020 Guidelines on
FAIR Data Management [2]. Key aspects from said guidelines are presented
below.

Each project should provide information on:

  * the handling of research data during and after the end of the project 

  

  * which data will be collected, processed and/or generated 

  

  * which methodology and standards will be applied 

  

  * whether data will be shared/made open access and 

  

  * How data will be curated and preserved after the project end. For this, a Data Summary must be given, presenting: 

  

  * the purpose of the data collection/generation and its relation to the objectives of the project 

  

  * the types and formats of data that the project will generate/collect 

  

  * the re-use of existing data, if any, and how they will be re-used  the origin of the data 

  

Then, the mechanisms to make data findable must be described. This entails the
possible use of metadata, Digital Object Identifiers, naming conventions and
search keywords.

The project must then specify which data will be made openly available or will
be licensed for re-use and how they will be made accessible, detailing the
repository, the access methods and any relevant documentation.

Data should be interoperable as far as possible. This may include using
standard formats, open software applications or standard data and metadata
vocabularies.

Provisions should be put in place for data security and recovery, if needed.

Informed consent needs to be discussed too.

Some of the above guidelines are overlapping with the GDPR requirements, for
example the informed consent procedure, the data description and the security
provisions.

##  RESIST Naming conventions regarding deliverables and documents

During m6 consortium produced a unique project document (D1.1 Quality and risk
management) coding system for all documents and deliverables, as indicated in
the table below. As regards project deliverables naming and since they are
already coded in the Description of Work, their naming will be as follows:  
  
<table>  
<tr>  
<th>

Project name

</th>  
<th>

“RESIST”

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

Underscore

</td>  
<td>

“_”

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

Next 3-4 digits following a pattern

</td>  
<td>

“DX.X” + with X.X representing deliverable number according to Description of
Action (DoA).

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

Underscore

</td>  
<td>

“_”

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

Deliverable title as in DoA (with blank spaces replaced by underscores)

</td>  
<td>

E.g. “Data_Management_Plan”

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

Underscore

</td>  
<td>

“_”

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

Deliverable version following a pattern (if needed)

</td>  
<td>

"VX.X" with X.X representing the number of revision of the deliverable.

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

Example:

“RESIST_D5.1_Architecture_of_the_networking_platform_supporting_secure_communicatio
ns_V3”, means the version 3 of D5.1 deliverable, titled _Architecture of the
networking platform supporting secure communications_ . Deliverables that have
been defined in the DoA as Public (they are provided in Appendix A) will be
provided in an open space of the project website (www.resistproject.eu) after
their being reviewed and approved by the EC, so that anyone may access them.
Apart from the title and their short description, they will include search
keywords in their title page. Regarding the deliverables that are confidential
and their content is restricted, an executive summary of the deliverable will
be replaced in the project website after the EC acceptance.

##  Making data findable, including provisions for metadata

The RESIST consortium has a strong focus on making sure that the generated
data will be identifiable and easily discoverable thus rendering them
findable, including provisions for metadata.

An overview of the data types that will be available within the context of
RESIST is briefly described in the present deliverable and will be refined on
project’s progress according to the needs. The persistence layer of RESIST as
well as the REST API to store and retrieve the data from the persistence
layer, will be described in more details in the deliverables of WP8 regarding
the integration of the project. All the data (images and sensor data) will be
uniquely identified per operator ID, asset ID, inspection ID, and by the time
of acquisition. The following table, describes a preliminary plan regarding
the unique identification of the RESIST data in the RESIST persistence layer:  
  
<table>  
<tr>  
<th>

**Type of Data**

</th>  
<th>

**Identification Criteria**

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

**Fixed sensor data**

</td>  
<td>

Operator unique ID,

Asset ID,

Coordinates of the sensor,

Date&Time of the data acquisition

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

**Collected images**

</td>  
<td>

Operator unique ID,

Asset ID,

Inspection ID with Timestamp,

Image unique ID per inspection

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

**Defects**

</td>  
<td>

Operator unique ID,

Asset ID,

Inspection ID with Timestamp,

Unique ID per image,

Coordinates of the defect

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

**Sensor data collected with RPAS (deflection, inclination, elasticity
modulus, rebars)**

</td>  
<td>

Operator unique ID,

Asset ID,

Inspection ID with Timestamp,

Coordinates of the measurement.

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

All the collected data in RESIST that will be stored in RESIST persistence
layer will have a solid reference for future use and will be stored in a
standardised format.

Data collected by the mobile application will also be stored in the
corresponding persistence layer of the associated remote RESIST modules of the
system. Only a minimal set of data associated to user profiling will be stored
in the persistence layer of the mobile device and definitely no names.

Regarding RESIST documents/deliverables, clear and harmonized naming
conventions presented previously will be used. All of the RESIST project
deliverables will be named following the nomenclature of section 4.1 of the
present deliverable and as described in deliverable D1.1 quality and risk
management plan.

##  Making data openly accessible

The pseudonymous personal data of RESIST will be stored in dedicated
databases, hosted by relevant partners and accessible only to authorised
users. Any data that will be shared externally to the consortium will be
registered in the Registry of Research Data Repositories [3]. Such data will
be offered under Creative Commons License Attribution-Non-Commercial CC BY-NC.
Specific scripts will be offered for accessing these data and offering basic
statistics on the data. The source code of these access applications will be
offered under Apache v.2 license [4] and will be made available on a public
repository along with detailed documentation of usage.

Open datasets will be uploaded to an open access repository (e.g. Zenod  o
_https://zenodo.org_ )  . Links to the open shared datasets will be available
in the RESIST Web site.

Access to data will be enabled through the use of Open APIs and interoperable
formats.

All project deliverables will be available to authorized consortium members
the project through the internal project management tool and document
repository, Redmine and all final submitted versions will also be available
through the partner area of the website.

The public project deliverables and the executive summaries of non-public
deliverables will be available in the RESIST website and will also be made
available through ResearchGate. In more detail, the deliverables that have
been defined in the Description of Action as Public will be provided with an
open space on the project website (www.resistproject.eu) after their review
and approval by the EC, so that anyone may access them. Regarding the
deliverables which are confidential and their content is restricted, an
executive summary of the deliverable will be available in the project website
after the EC approval. Moreover, RESIST will follow the Open Access practice
[5] of providing online access to its scientific research articles. This will
be presented in section 4.2.

##  Making data interoperable

All data that will be externally offered within the project’s scope will be
available using dedicated scripts, as already mentioned. These scripts will
make use of the RESIST ICT platform API. The platform API will be open and
thoroughly documented in order to enable and encourage its usage from every
third-party application without forcing any dependencies on the provided
scripts. It will also use established standards as much as possible.

The project tools will be based on open source software to facilitate their
adoption and possible modifications. Interoperability of data will be enabled
with standardized data. Data regarding mobility and continuity will be
modelled according to industry practices and standards such as the DATEX2.0
standard.

The data in the databases will be exposed in a text format following well-
known and established standards (e.g., CSV, JSON or XML).

Currently there is not a standard for exchanging social media data. This will
be closely monitored and the tool will adapt to any standard accepted by the
scientific community when available.

All RESIST security mechanisms will rely on information security industry
standard format and representations (e.g. for malicious traffic signatures or
incident reporting), to allow for interoperability with associated mechanisms
and tools widely available in the field. For example for cybersecurity related
data, such formats will include the MISP open standards (Open Source Threat
Intelligence Platform & Open Standards For Threat Information Sharing;
_https://www.misp-project.org/_ )  , as well as the Snort rules format  (
_https://www.snort.org/rules_explanation_ )  which is used in the tools itself
and its numerous derivatives.

Increase data re-use (through clarifying licenses)

As mentioned, the data that will be generated by RESIST will be licensed for
scientific purposes under Creative Commons License Attribution-Non-Commercial
CC BY-NC after the completion of the project. Other than the ones imposed by
this license, no other restrictions for re-usage by third parties are
envisaged.

Any new filters and signatures that will be generated in the context of the
project, e.g. for traffic classification or malware identification, will be
represented in industry standard formats and will be shared with the licensing
terms pertaining to each of the corresponding tools (e.g. Snort rules;
_https://www.snort.org/rules_explanation_ )  . The same process will be
followed for threat intelligence insights gathered through the use of the
RESIST platform in the project’s critical domain, via the MISP open standards,
as mentioned above.

Data obtained by RESIST modules will be either re-used in order to further
enhance the functionality of the existing system or will be used in order to
perform statistical analysis of associated collected data types. Data re-used
will be enabled though data anonymisation and use of harmonised data
standards.

Data collected by the mobile application will be uploaded to associated remote
modules of the RESIST platform. Therefore any potential re-use of data will
follow the data re-use strategy of the corresponding RESIST module.

Data collected by the social media tool will be only used to further improve
the quality of the produced output. Data related to social media posts will
not be made available to anyone and will be used exclusively by the tool. The
outputs of the tool analyses will be available to the RESIST platform to be
reused as appropriate.

In principle the data that will be collected are expected to be available for
five years after the project’s end.

#  Allocation of resources

At this stage of the project, there are no resources specifically allocated
for making RESIST data FAIR. In general terms, it is highly probable that no
extra-costs will be incurred. Regarding equipment and maintenance costs, these
will be, for the lifetime of the project, covered by the consortium.

Regarding personnel costs, we expect that making data FAIR shall not demand
any extra calculable time of effort. The personnel hours dedicated to this
will be counted within the Person Month dedications to the respective tasks.

In order to proactively mitigate the risk of partners overspending due to the
efforts of making any RESIST data FAIR, WP leaders should be subjected to
continuous monitoring by the Data Manager and of course the Project
Coordinator through the periodic management reports, the physical meetings,
etc.

The Consortium will take advantage of the fact that costs associated with open
access to research data can be claimed as eligible costs of any Horizon 2020
grant, and if necessary, reallocation of resources between partners will take
place.

Moreover, it should be noted that 3 person months that have been allocated to
Task 1.4: “Data Management and Internal Project Server” which concerns mostly
data related matters.

More information regarding the resources for internal data and for data to be
shared with external entities are provided in the next sections 5.1 and 5.2
respectively.

##  Resources for internal data

The internal data to be exchanged among RESIST partners are related to
deliverables, internal reports, minutes of meetings and teleconferences,
agendas, templates, presentations, administrative documents and files of any
kind in general. RESIST will make use of Redmine, a free and open source, web-
based project management and issue tracking collaborative tool in order to
facilitate information exchange, storage, ordering and retrieval as needed in
the project. Redmine will be used as the common document repository of the
project and is already configured by the website administrator. Redmine is set
and runs under the responsibility of ICCS, the project coordinator. All
consortium members are actively using this interactive knowledge-sharing
platform for information exchange, discussions, news and calendar. This
collaborative tool and relevant storage structure is consortium confidential
with restricted access.

The key features supported by Redmine are the following:

  * The platform increases the efficiency of Redmine partners by providing a digest of upcoming, ongoing and overdue work. 

  

  * Project plans can be created and project work stream items can be connected to activities and milestones by using integrated Kanban boards and Gantt charts. 

  

  * Work Package leaders and Project Managers may view, manage and execute on a high-level roadmap plan, covering their long-team work strategy. 

  

  * The platform can provide Team Leads and Managers (Project Coordinator, Work Package leaders, Technical and Quality Assurance Manager, Data Manager, Ethics Manager) with a complete picture of task assignments and commitments across the RESIST project. 

  

  * RESIST partners can share files and collaborate on project documents. 

  

  * RESIST progress, goals and plans can be visualised in order to be able to track how close each team is to meeting deadlines and identify where bottlenecks may be occurring. 

  

  * RESIST partners can easily and instantly share feedback, ideas and questions. 

  

Redmine is free of cost, so, the only resources declared concern only the
setting and deployment of the collaborative platform. In addition, resources
relevant to administrative and maintenance issues with respect to Redmine are
covered by the project coordinator, ICCS, who also has the rights for managing
users, groups and also of assigning roles and permissions. To this end, ICCS
has already provided RESIST partners with credentials, after their request for
an account, in order for them to be able to login and use it. Further to this,
for the needs of continuously upgrading the collaborative tool and back-up its
database in order to address unforeseen events (hard disks failures, web
attacks, etc.) resources have already been allocated by the consortium.

##  Resources for data to be shared with external entities

As previously stated, RESIST participates in the Horizon 2020 Open Research
Data Pilot. The project aims to make the research data to be generated
findable, accessible, interoperable, reusable and secured.

Technical validation, and evaluation as well as benchmarking and system
assessment will be produced following the outcomes and key performance
indications of the two pilot activities in Greece and Italy.

D2.4 “KPIs; Evaluation methodology; Techno-Economic, Env., Social analyses”,
defines success criteria and the KPIs to be used. It also defines a framework
for technoeconomic/environmental/social analyses and for the assessment of the
effects of the proposed solutions on regional economy and the environment.
D8.1 “Integration Plan” provides information about the integration cycles,
establish the tasks at each step and act as the specification of the whole
integration, ensuring there are no conflicting requirements of the individual
components both in hardware and in software / middleware. D8.4 “Technical
validation and evaluation report –User’s guide” will include the outcomes of
the technical testing of the integrated platform such as: description of the
hardware, modules and their versions, integrated devices, communication
channels and protocols; description of the integration test cases with
reference to their source code; log of execution of the integration test
cases; register of raised issues with their status; to be used during the
field tests. D9.1

“Validation, demonstration and benchmarking preparatory report” will include
all preparatory steps for each pilot, clarification of access, equipment and
other steps for the smooth execution of the pilots. This will also include the
final validation, demonstration and benchmarking scenarios and metrics.
Finally, D9.2 “Final system assessment and benchmarking” will include the
results of all activities in both sites and the set of recommendations and
benchmarking results. The assessment will include as Annexes the technical
performance and usability of all individual solutions and the Integrated
Platform. In addition, techno-economic analyses, the environmental and social
assessment will also be presented.

However, certain resources are needed in order for the data to be shared with
external entities.

Any need of personnel hours’ allocation for data stewardship is already part
of the allocated person months per Work Package, as Work Package leaders are
the main responsible for such activities, with the support of all other
partners involved in the certain Work Package and in particular with the
overall guidance and support of the project’s consortium that has budgeted for
dissemination costs. The RESIST project will follow the Open Access practice
[5] of providing online access to scientific information that is free of
charge to the end-user and reusable.

This covers both peer-reviewed scientific research articles (published in
scholarly journals) and research data (data underlying publications, curated
data and/or raw data).

In the cases where publication in a scientific journal shall be selected as a
means of dissemination of the project activities, one of the two channels of
open access shall be chosen (evaluated per case), i.e. either:

  * Self-archiving / 'green' open access – the author, or a representative, archives (deposits) the published article or the final peer-reviewed manuscript in an online (either institutional, or centralized such as Zenodo) repository before, at the same time as, or after publication. 

  

  * Open access publishing / 'gold' open access - an article is immediately published in open access mode. In this model, the payment of publication costs is shifted away from subscribing readers. The most common business model is based on one-off payments by authors/partners. 

  

RESIST partners will also consider the possibility to make use of free of
charge, open data repository services, such as Zenodo. Through such
repositories, metadata and digital object identifiers could be assigned to
RESIST datasets in order for them to be located via search after the end of
the project. The datasets in Zenodo will be preserved in line with the
European Commission Data Deposit Policy. The data will be maintained
indefinitely (minimum 5 years) ensuring no costs for archiving. It should be
noted that any unforeseen costs related to open access to research data in
Horizon 2020 are eligible for reimbursement for the duration of the project.

It is also worth mentioning that the costs for making data FAIR highly depends
on the yet to be specified details of the amount data that will be collected
and their processing effort. In any case, all costs related to FAIR data
management that will occur during project implementation will be covered by
the project’s budget. However, any other cost that may relate to long term
data preservation will be discussed among consortium members, but as stated
before the services of free of charge research data repositories will be
pursued.

#  Data security

The goal of the data security is to maintain the confidentiality, integrity,
and availability of information resources in order to enable successful
research and business operations. All RESIST data will be collected, stored,
protected, shared, retained and destroyed, upholding state-of-the-art security
measures and in full compliance relevant EU legislation (see also Section 8).
As a general rule, these data will be stored on paper and/or computer files
protected by state-of-the-art physical and logical security measures: the
archives containing the paper folders will be locked in a non-reachable and
hard to access place.

On the infrastructure level, the following considerations will be met:

  1. The data repository will allow physical access to the premises only to authorized staff 

  

  2. The servers should be complying with appropriate security standards (e.g. prohibiting remote access to unauthorised users) and be accessible only by authorised personnel with the proper use of credentials. 

  

  3. State-of-the-art security mechanisms should be deployed in the servers (i.e. host intrusion detection system) or in an important network vantage point (i.e. network based intrusion detection system) to monitor the systems and the traffic flow for known threats 

  

  4. Access to the data repository should be accomplished over HTTPS and any data transfer can be done via SFTPs. Of great importance is also the security of the data stored, meaning that strong cryptographic mechanisms should be employed to make the data incomprehensible for an attacker. As well as the availability of data, that could be handled by keeping regular backups, which in turn are stored in the similar secure manner. 

  

  

From an endpoint perspective, input validation and X-Scripting protection
techniques should be present; alongside mechanisms to protect session
hijacking by a malicious third party.

This chapter focuses on the technical guidelines specific to mitigating the
occurrence of common data vulnerabilities.

##  Data Acquisition

RESIST receives data primarily through various types of sensors, UAVs, Social
Media and users’ mobile phones, as detailed in Section 3\.

Data are acquired in conformity of security best practices through protected
connections and dedicated state-of-the-art IT infrastructures (LANs, protected
servers, firewall).

To guarantee security and reliability of the communication, the most advanced
web standards are implemented:

  * HTTPS transport level security is applied. 

  

  * Authentication and authorization are required both for user interactions with the system and for machine-to-machine transactions. 

  

  * Access and interactions are controlled and audited. 

  

Mobility data will be mostly retrieved by the mobility continuity module over
a client-server architecture, secured according to industry standard
techniques. Data will be encrypted through the use of the HTTPS protocol.
Moreover authentication of users to the system will be implemented through the
use of OAuth2.0 and open-id connect protocols.

Mobile data will be collected through local sensors and user input. Mobile
device sensor data access is restricted to the respective api’s which are used
only upon user consent. Moreover such data will only be tunnelled to the
associated remote RESIST modules are described in previous paragraphs. User
input will be collected through the use of mobile data input api’s and will be
directly tunnelled to remote RESIST modules as described in previous
paragraphs.

Publicly available social media posts will be collected by the social media
interface tool through the APIs available from the social media platforms.

Data acquisition will also be performed by respective cybersecurity monitor
and functions. Details on such components will be decided/defined within WP5,
Task 5.3: Cyber Security Mechanisms.

Further elaboration of aggregated data will be performed in the scope of WP6
for extracting global statistics for project impacts evaluation and overall
business and mobility-related indicators.

##  Data Processing

In the context of the project, data are mainly processed on the Mobility
Continuity Module and the Cognitive Computer Vision System.

Further elaboration of aggregated data will be performed in the scope of WP6
for extracting global statistics for project impacts evaluation and overall
business and mobility-related indicators.

In all situations that include data processing, usually, the computations take
place in regularly updated software environments in terms of operating
systems, runtime environments and software libraries.

Corporate-level security standards are guaranteed across every stage of data
elaboration, while restrictions and data protection techniques ensure security
and reliability. Secure computation techniques will be adopted to perform the
required tasks, identifying and loading the least amount of data to be
processed. Intermediate results of elaborations are cleaned as soon as they
are no more subject of further activity. Data processing may include
anonymization or pseudonymization techniques if required in order to be in
compliance with GDPR principles. Moreover, any data formatting and/or data
format transformation may be incorporated as well as metadata information
which will be added to the dataset so as to make them findable.

Processing of data will be performed as well within the cloud platform of
ICCS. The platform, ensures both digital and physical access to the server.
Moreover exposed data interfaces will follow the data security methodology
presented in the previous paragraph. Minimal processing related to data
transmission and data visualisation will be executed within the mobile
application. The processing will ensure data integrity and will not expose
data through any non-authorised interfaces.

##  Data Sharing

In RESIST data sharing occurs at different levels and mostly among project
partners:

Regarding the project activities, in principle, information is flowing among
partners for internal consortium consumption in the tasks or can be subject to
targeted dissemination activities with the condition that they are classified
as public.

During the pilots’ execution, data are not expected to be released to any
external parties. If needed though, shared data detail level will be the
minimum required.

With reference to the project’s internal data and documents, sharing security
is built on the tools and the platforms the consortium adopts:

The Redmine collaborative tool, is selected as the repository for internal
collaborative documents, working drafts, minutes of meetings and phone calls
targeted to private access for the consortium members. Datasets that will be
shared within the consortium are also expected to be stored in the Redmine
project repository. Regular backup strategy and data recovery procedures will
be followed.

Any project data that will be needed to be publicly accessible, will be,
through public open data and open access platforms such as Zenodo side by side
with the project’s website.

Redmine as previously described is a free and open source, web-based project
management and issue tracking tool. It is also featured as a centralized
password-protected repository and workspace, built over secure network
connection. It allows users to manage multiple projects and associated
subprojects. It features per project wikis and forums, time tracking, and
flexible, role-based access control. It includes a calendar and Gantt charts
to aid visual representation of projects and their deadlines. Redmine
integrates with various version control systems and includes a repository
browser and diff viewer.

Zenodo is an open source open data platform, which can be used to serve our
needs, that provides a repository for European Commission funded research
built on the OpenAIRE project and CERN developed tools. Clear data access,
sharing and reuse policies are enforced.

Any data applicable for sharing, will be shared

  * according to state of the art and industry security practices 

  

  * authorized network and UI interfaces following industry standard practices for security 

  

##  Data Storage and Preservation

In this section we will present the storage and preservation aspects of data
management.

Project working documents are stored in the Redmine collaborative tool.

The platform is set under the responsibility of the project coordinator (ICCS)
deployed on the organization’s data center who guarantees environmental
protection. Project data are persisted in a modern and reliable database
system. Access to the database is restricted to authenticated users and
different authorization profiles are defined according to business-related
data access restrictions. Connections for system and data administration are
protected and audited.

A backup and recovery strategy for the system has been planned according to
common best practices such as daily full backups and more frequent incremental
backups.

After the end of the project, open data will be archived and preserved in
partners’ repositories as well as in Redmine platform and the project’s
website for five years. Regarding confidential data that will be deposited to
the Redmine repository, the decisions about long-term preservation and
curation have not been taken yet. RESIST will also ensure the preservation of
the necessary data anonymity. Proper anonymization techniques will be applied
to guarantee the preservation of anonymity of the user personal, sensitive
data (e.g. emails and contact info of the users of the platform). Any user
personal data obtained within the project will be transmitted to partners
within the consortium only after anonymization or pseudonymization techniques
will be applied.

Zenodo offers data storage in CERN Data Centers, primarily in Geneva, with
replicas in Budapest. Data files and metadata are replicated in a distributed
file system and backed up nightly. Data will be retained for the lifetime of
the repository, which nowadays is defined for the next 20 years at least.

A secure persistence layer will be hosted within the cloud interface of ICCS.
Minimal data collections will be stored within the mobile device, within the
mobile device’s secure persistence layer. The majority of data collected will
be transmitted to associated remote RESIST modules and will be stored
according to the practices described in the related sections of the document.

#  Ethical aspects

In RESIST, there are three dedicated separate deliverables D12.1 H requirement
No.1, D12.2 POPD Requirement No. 2 and D12.3 EPQ Requirement No.3 which cover
ethical aspects regarding the project and the corresponding actions with
regards to its tasks.

Those deliverables address on the procedures and criteria that will be used to
identify/recruit research participants. In depth description of the informed
consent procedures that will be implemented for the participation of humans
has been provided and the relevant templates of the informed consent/assent
forms and information sheets have been produced.

The project information sheet accompanied by the informed consent/assent forms
are included in deliverable D12.1 H - Requirement No. 1 and in deliverable
D12.2 POPD - Requirement No. 2. The informed consent forms are intended to be
signed by participating prior to being engaged in any participatory to the
project method after having read and fully understand the information provided
to the project’s information sheet and, of course, any additional information
provided on the informed consent form. These forms will also be offered to all
volunteers prior to their participation in the large scale demonstration
pilots that will be held.

The aforementioned deliverables also cover matters on procedures for data
collection, storage, protection, retention, and destruction, and confirmation
that they comply with national and EU legislation and detailed information on
the informed consent procedures in regard to the collection, storage, and
protection of personal in compliance with the Data Protection Directive EC
Directive 95/46, the national legislation and the EU General Data Protection
Regulation (GDPR). Extensive investigation has taken place on whether or not
any certain compliance and/or authorization is required under national laws of
Italy and Greece for the collection and processing of personal data.

Finally, other ethical aspects investigated had to do with possible harm to
the environment caused by the research and the proposed measures that will be
taken to mitigate the risks and on relevant authorizations needed for the
proposed use of unmanned aerial vehicles in the project.

#  Data Protection

In this chapter we will try to address all the relevant data protection
aspects from different perspectives. This chapter has a supplementary role to
Deliverable “D12.2 POPD Requirement No. 2” which is dedicated on protection of
personal data. First of all, we will outline the European framework on privacy
and security and provide the general principles. Following comes a brief
description of the data subject’s rights and the consent that must be provided
for the processing of data. The controller’s and processor’s obligations are
also listed in accordance with the new regulations. On the latter come the
cybersecurity certification, privacy related matters, measures that RESIST
will take to mitigate any possible risks and finally matters regarding the
user recruitment will be discussed.

##  GDPR Requirements

###  General principles

The Regulation (EU) 2016/679 of the European Parliament and of the Council of
27 April 2016 on the protection of natural persons with regard to the
processing of personal data and on the free movement of such data (General
Data Protection Regulation - GDPR) [1] comes into force on 25 May 2018. the
new regulation has been heralded as the most innovative and important change
in data privacy regulation in 20 years and as an essential step to strengthen
citizen’s fundamental rights in the digital age and facilitate business by
simplifying rules for companies in the Digital Single Market.

The aim of the GDPR is to protect all EU citizens from privacy and data
breaches in an increasingly data-driven world that is vastly different from
the time in which the former 1995 directive (Data Protection Directive
95/46/EC) was established. An overview of the main changes is provided below:

**Increased territorial scope (extra territorial applicability)**

The GDPR’s section on territorial scope can be found in Article 3 of the
regulation. Here it’s made clear that the regulation applies wherever
processing of data takes place, be it within or outside the European Union.
The Article applies:

  * "to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, whether or not the processing takes place in the Union; 

  

  * to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union where the processing relates to the offering of goods or services (whether free or paid for) or the monitoring of behavior which takes place within the EU; and 

  

  * to the processing of any personal data by a controller outside the EU but in a jurisdiction where Member State law applies by virtue of international law (e.g. a diplomatic mission or consular post)." 

  

It is not envisaged that there will be any need to transfer data for the
RESIST project outside the EU. Nevertheless, in the case of dissemination and
exploitation activities involving nonEU states this may become relevant.

**Penalties**

Organizations found to be in breach of GDPR can be fined up to 4% of annual
global turnover or €20 Million (whichever is greater). This is the maximum
fine that can be imposed for the most serious infringements, e.g. not having
sufficient customer consent to process data or violating the core of Privacy
by Design concepts.

**Consent**

All the relevant conditions regarding consent have been strengthened, and
companies will no longer be able to use long illegible terms and conditions
full of legalese. Key principles are as follows:

  * The request for consent must be given in an intelligible and easily accessible form. 

  

  * This should clearly declare the purpose of data processing attached to that consent.  And importantly, it must be as easy to withdraw consent as it is to give it. 

  

Below are some useful definitions from the GDPR:

**Personal data** means any information relating to an identified or
identifiable natural person (‘data subject’); an identifiable natural person
is one who can be identified, directly or indirectly, in particular by
reference to an identifier such as a name, an identification number, location
data, an online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identity of that
natural person

**Processing** means any operation or set of operations which is performed on
personal data or on sets of personal data, whether or not by automated means,
such as collection, recording, organisation, structuring, storage, adaptation
or alteration, retrieval, consultation, use, disclosure by transmission,
dissemination or otherwise making available, alignment or combination,
restriction, erasure or destruction

**Controller** means the natural or legal person, public authority, agency or
other body which, alone or jointly with others, determines the purposes and
means of the processing of personal data

**Processor** means a natural or legal person, public authority, agency or
other body which processes personal data on behalf of the controller;

The general principles pursued by the GDPR requirements are that personal data
shall be

  * processed **lawfully** , fairly and in a **transparent** manner in relation to individuals, 

  

  * collected for specified, explicit and legitimate purposes and further processed for scientific purposes, 

  

  * adequate, **relevant and limited** to what is necessary for the purposes for which they are processed, 

  

  * kept in a form which permits **identification of data subjects for no longer than is necessary** for the purposes for which the personal data are processed, 

  

  * processed in a manner that ensures appropriate **security** of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage. 

  

The GDPR sets specific requirements for processing of special categories of
personal data (for example revealing race, health, politics, religion), but
such data will not be collected or processed in RESIST.

###  Data subject’s rights

**Data subject (citizen) rights** brought in to affect by the GDPR are as
follows:

**Right to be informed**

Fair processing information should be provided to the subjects. The
information should be concise, transparent, intelligible and easily
accessible. It should be written in clear and plain language and it should be
given free of charge.

**Breach notification**

Under the GDPR, breach notification will become mandatory where a data breach
is likely to “result in a risk for the rights and freedoms of individuals”.
This must be done within 72 hours of first having become aware of the breach.

**Right to Access**

Part of the expanded rights to data subjects outlined by the GDPR is the right
for data subjects to obtain from the data controller confirmation as to
whether personal data concerning them is being processed, where and for what
purpose. Further, the controller shall provide a copy of the personal data,
free of charge, in an electronic format. This is a dramatic change to data
transparency and empowerment of citizens/subjects.

**Right to rectification**

Individuals are entitled to have their personal data rectified if it is
inaccurate or incomplete. If requested, a response should be given within one
month from the request.

**Right to be forgotten**

Also known as **Data Erasure** , the right to be forgotten entitles the data
subject to have the controller erase his/her personal data, cease further
dissemination of the data, and potentially have third parties halt processing
of the data. The conditions for erasure, as outlined in article 17, include
the data no longer being relevant to original purposes for processing, or a
data subjects withdrawing consent. It should also be noted that this right
requires controllers to compare the subject’s rights to “the public interest
in the availability of the data” when considering such requests.

**Right to restrict processing**

Individuals have the right to block processing of personal data under certain
conditions, in which case data can be stored but not processed.

**Right to data portability**

This right allows individuals to obtain and reuse their personal data for
their own purposes across different services. Therefore, personal data should
be easily copied, moved, transferred from one IT environment to another in a
safe and secure way and free of charge. This means that, if requested by the
subject, personal data should be provided in a structured, commonly used and
machine-readable form (for example as a csv file).

**Right to object**

Individuals have the right to object to processing. Processing must stop as
soon as an objection is received. Individuals must be informed of their right
to object “at the point of first communication”. This right should be
presented clearly and separately from other information.

**Rights related to automated decision making including profiling**

Profiling includes algorithms to analyse or predict behaviour, location or
movements. In such cases:

  * meaningful information about the logic involved in profiling should be provided together with the significance and consequences 

  

  * appropriate mathematical or statistical procedures should be involved for the profiling 

  

  * measures to enable the correction of inaccuracies and to minimise risk of errors should be implemented 

  

Automated decision making must not concern children and must not be based on
processing special categories of data.

##  Cybersecurity certification

On 13 September 2017 the Commission issued a proposal for a regulation on
ENISA, the "EU Cybersecurity Agency", and on Information and Communication
Technology cybersecurity certification (''Cybersecurity Act'').

Certification plays a critical role in increasing trust and security in
products and services that are crucial for the digital single market. At the
moment, a number of different security certification schemes for ICT products
exist in the EU. Without a common framework for EUwide valid cybersecurity
certificates, there is an increasing risk of fragmentation and barriers in the
single market.

The proposed certification framework will provide EU-wide certification
schemes as a comprehensive set of rules, technical requirements, standards and
procedures. This will be based on agreement at EU level for the evaluation of
the security properties of a specific ICTbased product or service e.g. smart
cards.

The certification will attest that ICT products and services that have been
certified in accordance with such a scheme comply with specified cybersecurity
requirements. The resulting certificate will be recognized in all Member
States, making it easier for businesses to trade across borders and for
purchasers to understand the security features of the product or service.

The schemes proposed in the future European framework will rely as much as
possible on international standards as a way to avoid creating trade barriers
and ensuring coherence with international initiatives.

In the context of RESIST, there is a dedicated work package on cyber security
and messaging/communications which among others will implement certain
mechanisms to ensure it, and the proposed EU certification framework must be
taken into consideration. Detalis on the RESIST cyber security mechanisms can
be found in deliverable D 5.2 Resist cybersecurity mechanisms.

##  Privacy information

The RESIST project will make use of users’ data and information for research
purposes only. When applicable, aspects of the project relating to the
handling of end user data will have to take the following ethical and privacy
factors into consideration:

  * Protection of right to honor, personal and family privacy and image. 

  

  * Personal data protection. 

  

  * Secrecy of private communications.  Protection of consumers and users. 

  

The key aspects that can be summarized from EU rules on data protection as
depicted previously with regard to the European framework on privacy and
security are:

  * Establishing the principle of data quality, so that personal data must be adequate, relevant and not excessive, according to the purpose for which it will be processed. 

  

  * The existence of prior consent with respect to the collection of data. Establishing basic principles of citizens' rights to access, rectification, cancellation and opposition in relation to their personal data. 

  

  * Establishing a basic principle of ensuring confidentiality and the obligation to implement appropriate security measures to ensure that access to information is limited and controlled. 

  

  * Establishing the basic principles of Data Protection that National Authorities should follow. 

  

  * Laying down the foundations of international transfers of personal data. 

  

##  Measures to be taken

To be compliant with the regulations set by the EC, personal data will be
collected on a strictly need-to-know basis, solely for the purposes of the
RESIST project and will be destroyed when no longer needed for that purpose.
Technical and operational measures will be implemented to ensure that users
will be able to access, rectify, cancel and oppose the processing and storage
of their personal data.

Anonymized data with personal identifiers completely removed will be used. For
limited specific purposes, where multiple data samples need to be linked to
the same individual, pseudonymization by irreversible cryptographic pseudonyms
will be employed. The linkage information required for re-identification will
be stored in a separate database utilizing serverside encryption and tightly
controlled access. De-identification of data must be performed the soonest
possible to the time at which the data are collected. Specifically, in the
case of data gathered from the personal mobile apps, data de-identification
should occur directly at the mobile phone use level. Based on an in-depth risk
assessment performed at the initial stage of the project, additional
horizontal and/or vertical data partitioning may be used to further decompose
data into smaller, independently controlled parts.

Encrypted communication based on SSL/TLS/SSH will be used whenever any data or
information, especially personal is transferred between systems. As a general
rule, collected sensitive data will be stored as close to the point of origin
as possible. The data will be released for further processing by other
components of the RESIST architecture on a strict need-toknow basis – only
required information will be released and with the minimum amount of detail
and specificity required for a given processing task. Whenever aggregated data
are sufficient, individual records, even made anonymous, will not be used.
Secure computation techniques will be used to derive required processing
results without having to collate all information in a single location.
Collected personal data are not expected to be transferred outside the EU.

Access to all data will be restricted using appropriate authentication and
authorization techniques (passwords, private keys etc.). Only minimum access
privileges required to fulfil their roles will be granted to individuals and
systems. Access to personal information will be monitored and logged. It will
be ensured that all individuals working with personal data within the project
will be aware of their responsibilities and obligations with respect to data
protection.

The data collected in the context of the RESIST project and used beyond the
scope of the project, if any, will have to be declared to the National
Authorities/Agencies responsible for Data Protection. Every entity involved in
handling data in some way has to do this at national level, not only the
entities collecting data, but also the ones in charge of storing or processing
them. Following, the appropriate Data Protection Certificates and Approvals
(DPCs) must be provided.

Informed consent procedures must be in position to ensure that participants
are informed about what personal data is tracked and what observations are
made, why this personal data is requested/obtained, what the personal data
will be used for, how their personal data will be handled, what will be
involved in taking part, and any potential risk they incur by participating in
the user studies, trials or using the application. Additionally, participants
must be informed that their participation is completely voluntary and that
they will be able to withdraw from the studies at any time without penalty and
for any reason. Regarding data coming directly from mobile devices, explicit
user’s consent will be obtained before the related application is launched.

#  Protection of personal data in RESIST

Among the deliverables that have been foreseen in the DoA of the RESIST
project there are also D12.1 H - Requirement No. 1 and D12.2 POPD \-
Requirement No. 2. These deliverables are part of work package 12, a dedicated
to Ethics work package, and cover the following contractual issues:

**D12.1:**

  * The procedures and criteria that will be used to identify/recruit research participants. 

  

  * The informed consent procedures that will be implemented for the participation of humans. 

  

  * Templates of the informed consent/assent forms and information sheets (in language and terms intelligible to the participants). 

  

**D12.2:**

  * The applicant must check if a declaration on compliance and/or authorisation is required under national law for collecting and processing personal data as described in the proposal. If yes, the declaration on compliance and/or authorisation must be kept on file. 

  

  * If no declaration on compliance or authorisation is required under the applicable national law, a statement from the designated Data Protection Officer that all personal data collection and processing will be carried out according to EU and national legislation must be submitted. 

  

  * Detailed information on the procedures for data collection, storage, protection, retention, and destruction, and confirmation that they comply with national and EU legislation must be included in the Data Management Plan. 

  

  * Detailed information on the informed consent procedures in regard to the collection, storage, and protection of personal data must be submitted. 

  

On the current deliverable, the data management plan, we will offer a summary
of D12.2 ethical matters and we well address briefly on the protection of
personal data in the scope of the project to avoid replicating information.

##  General principles

Within RESIST, the purposes and means of the processing of the personal data
that will be collected and stored in databases that are jointly determined by
certain partners, who will process the personal data for the purposes of
scientific analysis. Special category data are not foreseen to be collected or
processed.

For all personal data reported in the project, the names of the participants
will be replaced with ID codes to maintain anonymity. The identity of all
participants will be fully masked in any printed materials, project reports or
dissemination materials unless specific permission is provided. The RESIST
Project Coordinator (ICCS) will maintain all records and study documents.
These will be retained for at least 5 years or for longer if required by
individual institutions. If the responsible investigator is no longer able to
maintain the study records, a second person will be nominated to take over
this responsibility. The study documents shall be archived in the secure
facilities of ICCS (the project coordinating partner).

In cases that audio and/or video recording devices used within our studies,
these will be the responsibility of individual members of the research team;
no one outside of the research team will have access to any of these data.

Personal media and other content will not be used in wider dissemination of
the research project unless consent is specifically provided. Once
transcribed, audio files and other media will be deleted from digital
recorders and stored digitally within a password-protected folder on the
network drives of the participating institutions. Other content will also be
stored in password- protected databases encrypted and protected, within
institutions according to internal procedures, available only to members of
the research team.

Each partner who provides or otherwise make available to any other partner
data, will represent that:

  1. it has the authority to disclose such data which it provides to the partners; 

  

  2. where legally required and relevant, it has obtained appropriate informed consents from all the individuals involved, or from any other applicable institution, all in compliance with applicable regulations; and 

  

  3. there is no restriction in place that would prevent any such other partner from using such data for the purpose of the project. 

  

  

##  Getting data subject’s consent

As described on D12.1 and D12.2 any relevant participant to the project will
be asked to consent to the processing of their personal data prior to their
participation and after they are given an appropriate timeframe, to be
informed about the project’s information.

The potentially involved individuals will be offered a printed on paper
Consent Form and they will be asked to complete it, indicating their consent
or not. A template for the Consent Form is provided in Appendix B but it will
be modified according to the actual project developments.

They will also be offered the relevant project’s Information sheet, also
provided in Appendix A, where subjects will be able to get general information
about project, their involvement, matters regarding the processing of their
personal data, and will be determined to withdraw consent at any time or
exercise their rights if they feel some kind of violation.

The signed consent forms will be maintained locally by each partner and a copy
will be given to the data subject.

The RESIST Data Protection Officer (DPO) will review the consent forms on a
monthly basis and will consult with the RESIST partners, to check that the
processing and purposes have not changed from what has been communicated to
subjects.

##  Safeguarding data subject’s rights

RESIST respects the subjects’ right to be informed via its information sheet
and consent form, which will be given to them prior to any involvement, and
which will be available at a dedicated area in its website as well.

On the dedicated area in the web site, there will be an explanatory text,
allowing the subjects to contact the Data Protection Officer (DPO), request
access to their personal data or request rectification or erasure or
restriction of processing of their personal data or object to the processing
of their personal data. If such a request is received, the DPO will inform the
project Steering Committee, so that appropriate actions are taken. It will be
possible for a subject to request a copy of his/her personal data. If such a
request is received, the DPO will inform the project Steering Committee and
the project will provide the personal data in a structured, commonly used and
machine-readable csv file for free.

##  Ensuring data security

All data, including personal data in RESIST will be securely processed.

Hard copies of consent forms and possible identity data needed by local
regulations (including names, telephones, emails, addresses, ID, driving
licence, etc) will be kept in locked drawers. Any electronic copies will be
stored locally, encrypted and protected according to internal procedures by
the responsible partner. Only authorised employees will have access to such
data. Such data will be handled according to internal procedures of each
partner and will not be transferred to other RESIST partners.

RESIST project deliverables will be available in the project Redmine
_https://redmine.iccs.gr/projects/resist_ .  The server hosting the Redmine
installation is located in the ICCS premises in Athens, Greece, in a secured
rack in the ICCS’s servers’ room. The server databases are backed up on a
daily basis, while its files are backed up every second day. The server is
built with multiple redundancies, network- and disk-wise, in order to ensure
its constant operation and network access. The web access to
https://redmine.iccs.gr/ is secured using a digital certificate from TERENA
(https://www.terena.org). Only users authorised by the administrator, ICCS,
have access to the material available in the Redmine. The data in the
dedicated RESIST databases will be maintained for 5 years after the end of the
project. More details on the data retention and the hosting platform are
included on deliverable “D1.2 Internal Project Server”.

##  Accountability and governance

The present document describes the measures to be implemented, so that RESIST
complies with the GDPR requirements. This deliverable will be reviewed, and
updated as needed, by the Data Protection Officer.

RESIST implements principles of data protection by design and data protection
by default. A data minimisation policy is foreseen to be adopted by RESIST,
which means that only data strictly necessary for the scientific analyses will
be stored in the long term. The subject’s identity will not be stored in it
(pseudonymization) and the processing will be transparent to subjects since
they will be informed in a clear and easy understandable language.

#  Conclusions

This deliverable is the first updated version of the Data Management Plan of
the RESIST project given that the project consortium has opted in for the Open
Research Data Pilot principles. It replicates the initial deliverable and
complements it with the changes required following the project’s progress. In
general, it aims to provide a general overview of the kind of data that
produced, reused, collected and processed within the project’s context. It
tackles also topics related to challenges and constraints that need to be
taken into consideration. It also addresses on the data types with regard to
their purpose and relation to the project objectives, as well as how the
consortium will make sure that it will comply with FAIR data principles.

Almost all project partners within the consortium are owners or/and producers
of data while some will just process data that others generate. This implies
specific responsibilities, which are extensively described in this report.

The RESIST Data Management Plan emphasises strongly on the appropriate
collection – and publication if the data will be published – of metadata,
storing all the necessary information for the optimal use and reuse of those
datasets in compliance with all regulations.

This deliverable is still considered a living document and it will continue to
be updated for the duration of the project in order to remain as current as
possible. .