**1\. INTRODUCTION**

**1.1 Purpose of ATTRACkTIVE DMP**

The Data Management Plan (DMP) is a live document that describes the data
management life cycle for the data to be collected, processed and/or generated
by a Horizon 2020 project. As part of making research data findable,
accessible, interoperable and re-usable (FAIR), a DMP should include
information on:

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

  

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

  

  * Which methodology and standards will be applied 

  

  * Whether data will be shared/made open access 

  

  * How data will be curated and preserved (including after the end of the project) 

  

This data can be produced either by the partners of the project or they may be
collected by third parties. The latter case can apply if e.g. the data of
travel service providers will be needed to prove the outcome of the project
along use cases.

The DMP also provides an analysis of the main elements of the data management
policy that are going to be used by the Consortium. The policy can concern
the:

  * Dissemination policies of data 

  

  * Collect, process and review restrictions on data 

  

  * Interaction with the IT2Rail Lighthouse project to perform an efficient synchronisation - Intellectual property protection of data produced and used by partners. 

  

This document should be considered in combination with:

  * Section 9 of the Consortium Agreement: “Access Rights” 

  

  * Chapter 4/ Section 3 of the Grant Agreement No. 730822: “Rights and Obligations related to Background and Results” 

  

In this final version of the document the focus will be on data security in
chapter 2 and travel companion together with GDPR issues in chapter 3 as part
of each subsection.

**1.2 Background of ATTRACkTIVE Project**

In order to better understand the data used or generated by the project, a
brief overview of the project structure and objectives of each work package
(WP) is given below:

**Figure 1 – ATTRACkTIVE Project Structure**

• **WP1: Trip Tracking**

The Trip Tracking (TT) work package deals with the specification, design and
implementation of the system in charge of collecting travel information from
multiple sources, to detect and handle transport events, to analyse the impact
of disruptions for all modes and to provide alternatives if necessary and
possible. In this sense, so called partial Trip Trackers (pTT) will be treated
by a Tracking Orchestrator (TO) to inform and propose the user’s individual
solution for their current situation.

  * The Tracking Orchestrator is responsible for tracking a whole journey and to inform travellers about any occurrences that may happen during a travel. It takes a beforehand selected journey, looks for appropriate partial Trip Trackers and instructs them to track this journey. Thereafter it waits for any information that the pTT may provide. It checks and combines this information to relevant information and forwards this to the traveller. 

  

  * Several partial Trip Trackers may coexist, processing events and providing the Orchestrator with impacts that will affect the tracked journey, accounting traveller preferences. 

  

• **WP2: Travel Companion**

The Travel Companion work package aims to specify, design, and implement the
required techniques and tools to design novel forms of travel experiences.
This includes an advanced Personal Application running on Android devices as
well as allocated cloud based services to store private user specific
information. The system will be able to handle points of interests (POI),
provide navigation assistance and hide complex operations to deal with
different modes of transport.

  * The Personal Application is the client which a traveller can use to access the whole ecosystem. This way, users are able to access all services through a homogenized user interface, allowing them to leverage all the capabilities of the system. Furthermore, Location Based Experiences are integrated to present entertainment, provide point of interests or any other information that might enrich the journey. In addition, Indoor/Outdoor Navigation will be presented to guide the traveller throughout their journey. 

  

  * The online counterpart Cloud Wallet serves as the secured repository for the users’ personal information. Storing this information in the Cloud allows the user to not only access information multiple times but enables them to use different devices. Cloud Wallet also acts as a bridge between the Personal Application and all external services, allowing travellers to receive information affecting their journey and providing them with ubiquitous access to travel rights in electronic wallets. 

    * **WP3: Technical Coordination**

  

  

The Technical Coordination work package will assure coordination amongst the
activities of the partners within ATTRACkTIVE and as well coordinate with the
other Technology Demonstrators inside the IP4 program in particular, IT2Rail,
Co-Active (CO-Modal Journey Re-Accommodation on Associated Travel Services),
ST4RT (Semantic Transformations for Rail Transportation) and GoF4R (Governance
of the Interoperability Framework for Rail and Intermodal Mobility). It will
also be in charge of integrating and testing WP1 and WP2 technical results and
organising evaluation sessions with end-users to collect feedback and new
requirements for the next releases.

  * **WP4: Dissemination and Communication**

  

The Dissemination and Communication work package will put in place
communication tools and channels to guarantee seamless exchange between
partners and ensure that the outcomes of the project will be produced on time
and to high quality standards. Moreover, public events will also be organized
and conducted to share the acquired experience.

  * **WP5: Project Management**

  

The Project Management work package will guarantee the efficient coordination
of the project work package and tasks, ensuring not only effective consortium
management, but overall administrative and financial management of the
project. Considering its nature, there will be no data produced by this WP
suitable for inclusion within this DMP.

**1.4 Reference Documents**  
  
<table>  
<tr>  
<th>

[R1]

</th>  
<th>

ATTRACkTIVE Grant Agreement – N° 730822

</th>  
<th>

05/08/2016

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

[R2]

</td>  
<td>

ATTRACkTIVE Consortium Agreement

</td>  
<td>

14/07/2016

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

[R3]

</td>  
<td>

Quality Plan (updated version)

</td>  
<td>

07/07/2017

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

[R4]

</td>  
<td>

Guidelines on FAIR Data Management in Horizon 2020 (v3.0)
_http://ec.europa.eu/research/participants/data/ref/h2020/grants_ma
nual/hi/oa_pilot/h2020-hi-oa-data-mgt_en.pdf_

</td>  
<td>

26/07/2016

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

[R5]

</td>  
<td>

ATTRACkTIVE Public Website

_http://projects.shift2rail.org/s2r_ip4_n.aspx?p=ATTRACKTIVE_

</td>  
<td>

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

#  Table 2: Reference Documents

  2. **DATA MANAGEMENT AT PROJECT LEVEL**

  

  

This section describes general data management that applies to the whole
project and all data generated by the project.

**2.1 Typologies of Data**

The following categories of outputs will be provided by ATTRACkTIVE
Consortium, in order to fulfil the H2020 requirements of making it possible
for third parties to access, mine, exploit, reproduce and disseminate the
results contained therein:

  * (Public) Deliverables, 

  

  * Conference/Workshop presentations (which may, or may not, be accompanied by papers, see below), 

  

  * Conference/Workshop papers and articles for specialist magazines, \- Research Data and Meta Data. 

    2. **Data Collection & Definition **

  
  

  

The responsibility to define and describe all non-generic data sets specific
to an individual work package shall belong to the WP leader. The WP leaders
shall formally review and update the data sets related to their WP.

All modifications/additions to the data sets shall be provided to the
ATTRACkTIVE Coordinator (HaCon) for inclusion in the DMP.

  3. **Dataset Naming**

  

  

All dataset materials generated or used within the project will be named and
referred to in this DMP with the following codification, in order to have
unambiguous identification and ease of access:  
  
<table>  
<tr>  
<th>

**WP (3 characters)**

</th>  
<th>

**Number (3 digits)**

</th>  
<th>

**Version**

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

WP1

</td>  
<td>

001

</td>  
<td>

1

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

WP2

</td>  
<td>

001

</td>  
<td>

1

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

WP3

</td>  
<td>

001

</td>  
<td>

1

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

WP4

</td>  
<td>

001

</td>  
<td>

1

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

#  Table 3: Dataset Codification

**2.4 Archiving and Preservation**

Open access to public deliverables/reports, publication or presentation will
be achieved in ATTRACkTIVE by depositing the data into the Cooperation Tool
(CT), and activating their publication to the project Website [R5].

These documents will be available for at least 3 years following the project
completion.

**2.5 Data Security**

ATTRACkTIVE does not intend to use or produce any confidential or sensitive
data that would require setting up specific measures for secure storage or
transfer because it develops a technical demonstrator. It is not planned to
run this system productively in the market.

The current status of the project does not reconsider this position, but these
aspects will be monitored over time and taken into account during development
of the system. This ensures that once the system will be going live the data
is handled according to Data Security principles.

  * **Travel Companion Personal Application**

  

Personal data will be stored in the Personal Application (PA) for caching
purposes in case of network connectivity losses. It will be a mirror of the
data stored in the Cloud Wallet and does not need any backup as this cache can
be retrieved at will. The storing of the data on the device will comply with
the operating systems rules, namely iOS and Android, which are secured through
encryption.

The PA will send (indirectly through the Cloud Wallet and the Tracking
Orchestrator) sensitive data to an identified partial Trip Tracker. All
sensitive data transfer will take place using secured encrypted channels (e.g.
HTTPS connections) and authorization mechanism based on temporal token
generation.

Once a traveller with a valid journey stored in their secured personal data
set intents to be tracked several actions take place:

  * the Cloud Wallet is enabled to send push notifications to the travellers PA to inform users about any kind of obstacles 

  

  * the Tracking Orchestrator will subscribe this journey by using the User ID and the Offer ID representing the journey 

  

  * the journey is sent with a subscription ID anonymously to all partial Trip Trackers 

  

  * whenever an Event results in a relevant notification for the traveller the Tracking Orchestrator sends this notification to the Cloud Wallet which sends a push notification to the traveller. 

  

The generated subscription IDs and tokens are valid until the journey has
finished or until the traveller terminates the tracking mode.

  * **Partial Trip Tracker Repository**

  

Partial Trip Trackers do not store any personal data into their repositories.
The Partial Trip Trackers are not master of the data they manage. The stored
data come from sources that control data and the associated life cycles. The
storing is for caching purposes. In case of system crash, the data will be re-
acquired.

  * **Cloud Wallet Repository**

  

Cloud Wallet data will be stored on a relational database (PostgreSQL)
protected by a user and password. The access to this data will only be allowed
to administration users. Currently, the access to the data has two ways:

  * Through VPN connecting directly to the servers: in this way, a user and a password is needed in addition to the mandatory certificate VPN connection. Then, I will have access to the databases directly. 

  

  * Through services using a special admin account: this requires an administrator account registered in the Identity module and login with this account in the system to use a temporary token. Expiration time in temporary tokens is configurable. 

  

The database will be located on the Microsoft Azure Cloud, one of the safest
cloud environments.

Microsoft Azure recently completed a new set of independent third-party ISO
and Cloud Security Alliance (CSA) audits to expand its certification
portfolio. Azure leads the industry with the most comprehensive compliance
coverage, enabling customers to meet a wide range of regulatory obligations.
The following table summarizes the Azure certifications:  
  
<table>  
<tr>  
<th>

**Certification**

</th>  
<th>

**Azure**

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

CSA STAR Certification

</td>  
<td>

√

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

ISO 27001:2013

</td>  
<td>

√

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

ISO 27017:2015

</td>  
<td>

√

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

ISO 27018:2014

</td>  
<td>

√

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

ISO 20000-1:2011

</td>  
<td>

√

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

ISO 22301:2012

</td>  
<td>

√

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

ISO 9001:2015

</td>  
<td>

√

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

The access to this server will only be allowed using a Virtual Private Network
(VPN) protected by username and password that will only be available to
administration users. Only the owner of the cloud environment is able to add
new admin users if this is necessary.

This server will only be accessible using specific ports, blocking the access
using the most common ports used in hacking attacks, such as HTTP.

A database backup will be executed daily to generate a snapshot of the data
stored in the repository, and the backup will be stored on Azure
infrastructure to avoid data loss in case of a

server crash. This backup execution will be the responsibility of Indra as
well as the recovery in case of data loss.

A server backup will be configured in Azure daily for being able to restore
the full server in case of disaster.

All passwords stored physically in the database or in files will be stored
cyphered using a state of the art algorithm. The algorithm used is **bcrypt**
, a password hashing function based on the Blowfish cipher. This algorithm
incorporates a salt to protect against rainbow table attacks and it is also an
adaptive function: over time, the iteration count can be increased to make it
slower, so it remains resistant to brute-force search attacks even with
increasing computation power.

**2.6 Ethical Aspects**

The developed procedures and findings generated in ATTRACkTIVE are centred on
embedded systems topics and do not foresee any research on areas of ethical
relevance such as research on humans, animals, medical applications, genetics
or bio/nano-electronics.

During the project all possibly needed data will be simulated (replica data)
and thus constitute no personal data. In cases where personal data can or will
be used after the end of the project, this data will be secured and protected
by design.

None of the ethical issues that have been named in section 4 “Ethics issues
table” of the proposal submission forms are relevant for the ATTRACkTIVE
proposal.

**3\. DATA MANAGEMENT PLAN OF ATTRACKTIVE PROJECT**

• **FAIR Principles**

In order to have a well-organized data management, the FAIR Principles should
be applied, which mean to make the research data:

  * **F** indable, 

  

  * **A** ccessible, 

  

  * **I** nteroperable, 

  

  * **R** eusable 

  

for internal and external stakeholders of the project. The data architecture
of ATTRACkTIVE takes these rules into account for their specific parts having
in mind that this project is one of several ones in the course of Shift2Rail
IP4. The Open Call project My-TRAC deals with regulations according to GDPR
and parts of their outcomes will be reflected within this document.

Furthermore, produced data of the two work packages 1 and 2 are partly
targeted at one specific person and produce personal sensitive data, which is
not intended to be openly accessible so there is no need to enable an exchange
of data or to make them findable for an external usage. This applies
especially for the Travel Companion. It is guaranteed that data generated
within the project will only be reused with respect to corresponding projects
of IP4. For this usage data security especially for private sensitive data is
ensured due to anonymizing them so that data of this type would be reused in
an aggregated form. Data generated during the project is only used for the
development of new features to reach the mentioned objectives and will be
deleted after finalizing the project.

**3.1 DMP of WP1: Trip Tracking**

**3.1.1 _Data Summary_ **

The WP1 of ATTRACkTIVE project deals with the TD4.4 – Trip Tracker. The Trip
Tracker is designed to detect any kind of disruptions or obstacles of a
traveller’s itinerary and to provide users with alternative routes in case of
them.

The Trip Tracker deals with a wide range of multi-source and multi-format
information through direct links with various transport providers and data
providers. Therefore interfaces to support emerging and established standard
protocols such as VDV TRIAS, NeTEx, SIRI, GTFS static and real time will be
developed. Additionally information from urban OAS (Operational Assistance
Systems), ITS, suburban rail management systems, signalling infrastructure and
road traffic data will be taken into consideration. On top of that, data from
social networks related to the ongoing travels will be collected. The aim is
to analyse how social network information could feed the trip tracker and help
to enrich the trip tracking functions. This information can be complemented by
other information sources such as weather information that could affect common
operation. Finally the Travel Companion will be used as a data source for real
time information. Therefore this task also aims to interface it to the TC to
collect traveller information. The Trip Tracker will be fed with data from the
semantic web of transportation through the interoperability framework once the
S2R ecosystem is fully stablished.

The aim to collect data for the Trip Tracker is to retrieve all necessary
information required to enable tracking activation on journeys to be tracked.
This is in relation with the objective of collection of planned and real time
data for all modes including personal transport which is essential for all
following up calculations and assistance.

The collected data from Public Transport includes mixed reference data
(network data, time tables, planned journeys) as well as mixed dynamic data
(passing times, vehicle location, operating information,
situational/contextual information).

On the one hand, reference data is “real data” provided by Transport Services
Providers (e.g. STIB in Brussels). On the other hand, dynamic data is
“simulated data” from the simulator implemented within the ATTRACkTIVE project
to generate real time events in relation with the corridor/scenario that will
be defined in the final demonstrator. Real time events generated will be
linked with existing reference data in order to be as close as possible to
reality and respond to all situations that can happen within a network.

The consideration of relevant standards within the project as well as the
existence of Shift2Rail interoperability framework, will contribute to tear
down barriers and obstacles that stakeholders may find when joining Shift2Rail
ecosystem. Preventing those competitors in the transportation marketplace
might isolate themselves instead of participating in Shift2Rail in the
assumption that their market share would be higher.

The collected data from personal application components is extracted from
traveller’s mobile device sensors and traveller’s reported events. This data
will provide the ability to identify events based on user inputs and behaviour
without identifying that user.  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Data Set**

</th>  
<th>

**Description**

</th>  
<th>

**Origin**

</th>  
<th>

**Type**

</th>  
<th>

**Size**

</th>  
<th>

**Personal**

**Data**

</th>  
<th>

**Access/**

**License**

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

WP1-

001-1

</td>  
<td>

Weather

</td>  
<td>

Yahoo Weather API allows you to get current weather information for your
location. It makes use of YQL (Query

Language) Query, a SQL-like language that allows you to obtain meteorological
information. The API is exposed like a service REST and returns the
information in a data structure JSON. The data are updated every 2 seconds.

</td>  
<td>

Yahoo

Weather

API

</td>  
<td>

</td>  
<td>

</td>  
<td>

No

</td>  
<td>

open access; terms of use could be checked at _https://policie_

_s.yahoo.com/ us/en/yahoo/t erms/product_

_-_

_atos/apiforyd n/index.htm_

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

WP1-

002-1

</td>  
<td>

Planning data for Madrid

</td>  
<td>

Feeds for Indra’s Urban TSP with the planning data of the urban transit in
Madrid (CRTM)

</td>  
<td>

CRTM

</td>  
<td>

GTFS

</td>  
<td>

</td>  
<td>

No

</td>  
<td>

CRTM

(Consorcio

Regional de Transportes de Madrid)

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

WP1-

002-2

</td>  
<td>

Planning data for Barcelon a

</td>  
<td>

Feeds for Indra’s Urban TSP with the planning data of the urban transit in
Barcelona (TMB)

</td>  
<td>

TMB

</td>  
<td>

GTFS

/RES

T API

</td>  
<td>

</td>  
<td>

No

</td>  
<td>

_https://develo per.tmb.cat/d ocs/termsconditions_

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

**Code**

</th>  
<th>

**Data Set**

</th>  
<th>

**Description**

</th>  
<th>

**Origin**

</th>  
<th>

**Type**

</th>  
<th>

**Size**

</th>  
<th>

**Personal**

**Data**

</th>  
<th>

**Access/**

**License**

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

WP1-

003-1

</td>  
<td>

STIB

GTFS

</td>  
<td>

Open data from STIBMIVB, The Brussels Intercommunal

Transport Company. The Files API contains one operation returning the GTFS
Files. The GTFS files are updated every two weeks.

We will retrieve:

  * Stops with their geolocation 

  

  * Lines and their routes 

  

  * Details of every stop on a line 

  

  * Theoretical timetables at every 

  

stop

</td>  
<td>

STIB

</td>  
<td>

GTFS

</td>  
<td>

~25

MB

</td>  
<td>

No

</td>  
<td>

https://opend ata.stibmivb.be/store

/license

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

WP1-

004-1

</td>  
<td>

STIB Opera-

tion

Monitoring API

</td>  
<td>

Open data from STIBMIVB, The Brussels

Intercommunal

Transport Company.

The Operation

Monitoring API provides real-time information including:

  * Waiting times at stops 

  

  * Vehicles 

  

positions This API will not be used for demonstration purposes where SIRI SX
simulated data is better suited.

</td>  
<td>

STIB

</td>  
<td>

REST

API

</td>  
<td>

N/A

</td>  
<td>

No

</td>  
<td>

https://opend ata.stibmivb.be/store

/license

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

**Code**

</td>  
<td>

**Data Set**

</td>  
<td>

**Description**

</td>  
<td>

**Origin**

</td>  
<td>

**Type**

</td>  
<td>

**Size**

</td>  
<td>

**Personal**

**Data**

</td>  
<td>

**Access/**

**License**

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

WP1-

005-1

</td>  
<td>

RT Data

VDV

Based

Data for

VBB

</td>  
<td>

Non-Open Data provided by VBB (BerlinBrandenburg public transport association.
Data inherits plan data and real time data; the latter one is used in
ATTRACkTIVE Trip

Tracker

</td>  
<td>

VBB

</td>  
<td>

VDV 454

V2.1 Progr am-

status Real

</td>  
<td>

N/A

</td>  
<td>

No

</td>  
<td>

Individual bilateral

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

WP1-

006-1

</td>  
<td>

Planned

and RT

Data from public Transport in Netherland

</td>  
<td>

Data Source to be evaluated for prognosis events; based on Feeds created from
open data files published by the transitagencies under open license in
Netherlands

</td>  
<td>

OVapi

</td>  
<td>

GTFS

/GTF

S-RT

</td>  
<td>

</td>  
<td>

No

</td>  
<td>

_http://gtfs.ova pi.nl/nl/_ _http://gtfs.ova pi.nl/READM_

_E_

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

#  Table 4: WP1 - Data summary

**3.1.2 _FAIR Principles_ **

In this chapter the data used and created in the Trip Tracker is listed
according to each of the FAIR categories.

• **Findable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Meta Data, Comments**

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

WP1-001-1

</td>  
<td>

Data can be accessed according to open access terms;

Comment: It was decided within the course of the project not to implement
weather forecast conditions

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

WP1-002-1

</td>  
<td>

Data has been obtained from the open data portal of the CRTM (
_http://datacrtm.opendata.arcgis.com/_ ) containing the GTFS files for Metro,
Buses, Coach, Tram and Train and this information is imported in the Indra’s
Urban TSP.

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

WP1-002-2

</td>  
<td>

According to its non-open status access is granted according to license. From
a developer portal you can access to GTFS and real-time data.

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

WP1-003-1

</td>  
<td>

Data has been obtained from the open data portal of the STIB :
https://opendata.stib-mivb.be

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

WP1-004-1

</td>  
<td>

Data could be obtained from the open data portal of the STIB :
https://opendata.stib-mivb.be

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

WP1-005-1

</td>  
<td>

According to its non-open status access is granted according to license

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

WP1-006-1

</td>  
<td>

Data has been obtained from the RESTful API publicly available. It contains

GTFS and GTFS-RT feed related to some Netherlands public transport agencies

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

#  Table 5: WP1 - Findable aspects

• **Accessible aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Public/Private**

</th>  
<th>

**Specific Restrictions**

</th>  
<th>

**Access**

</th>  
<th>

**Comments**

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

WP1-

001-1

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

Not applicable

</td>  
<td>

</td>  
<td>

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

WP1-

002-1

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

Not applicable

</td>  
<td>

Stored in the Indra’s Urban TSP repository

</td>  
<td>

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

WP1-

002-2

</td>  
<td>

According license regulations

</td>  
<td>

to

</td>  
<td>

Specific regulations for

Real Time Data

</td>  
<td>

Accessible through INDRA account.

</td>  
<td>

Accessible for Shift2Rail Projects

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

WP1-

003-1

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

Specific open data license

</td>  
<td>

Accessible through free account

</td>  
<td>

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

WP1-

004-1

</td>  
<td>

Public

</td>  
<td>

</td>  
<td>

Specific open data license

</td>  
<td>

Accessible through free account

</td>  
<td>

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

WP1-

005-1

</td>  
<td>

According license regulations

</td>  
<td>

to

</td>  
<td>

Specific regulations for

Real Time Data

</td>  
<td>

</td>  
<td>

Accessible for Shift2Rail Projects

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

WP1-

005-1

</td>  
<td>

Non open data

</td>  
<td>

Individual regularities

</td>  
<td>

Access according to the individual regularities

</td>  
<td>

Accessible for

Shift2Rail

Proects

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

#  Table 6: WP1 - Accessible aspects

• **Interoperable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Comments**

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

WP1-001-1

</td>  
<td>

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

WP1-002-1

</td>  
<td>

The GTFS data can be combined with GTFS data from other providers to have a
complete multimodal environment covering multiple regions.

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

WP1-002-2

</td>  
<td>

The GTFS data can be combined with API/REST data to have a complete multimodal
environment.

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

WP1-003-1

</td>  
<td>

Based on GTFS standard

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

WP1-004-1

</td>  
<td>

Specific API

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

WP1-005-1

</td>  
<td>

VDV454 is a German standard used in public transport for data exchange

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

WP1-006-1

</td>  
<td>

Based on GTFS/GTFS-RT standard

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

#  Table 7: WP1 - Interoperable aspects

• **Reusable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Comments**

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

WP1-001-1

</td>  
<td>

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

WP1-002-1

</td>  
<td>

The GTFS data can be used to feed the Travel Expert Repository and build the
Meta Network through the Meta Network Builder.

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

WP1-002-2

</td>  
<td>

The GTFS data can be used to feed the Travel Expert Repository and build the
Meta Network through the Meta Network Builder.

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

WP1-003-1

</td>  
<td>

The GTFS data are used to feed the pTT. They are available for other potential
purposes.

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

WP1-004-1

</td>  
<td>

Not applicable

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

WP1-005-1

</td>  
<td>

Real Time Data is according to its nature is not reusable as it is invalid
after it expires when the specific travel segment lies in the past.

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

WP1-006-1

</td>  
<td>

Not applicable

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

#  Table 8: WP1 - Reusable aspects

**3.1.3 _GDPR Issues_ **

Within chapter 2.5 – Data Security it is explained that anonymous tokens
(subscription IDs) are generated to enable partial Trip Trackers to forward
collected Events to a specific traveller. These tokens are invalid after the
journey is past or tracking is terminated manually by the traveller. Insofar
the system works according all needs described in the GDPR regulations.

The Real Time Datasets as described in WP1-002-1 till WP1-006-1 used to
receive Events if any are completely independent of human beings. They reflect
only technical situations along the operation time independent of any specific
journey. GDPR issues therefore are not tackled at all.

**3.1.4 _Specific Consideration_ **

No specific considerations regarding data within this WP.

**3.2 DMP of WP2: Travel Companion**

**3.2.1 _Data Summary_ **

The WP2 of ATTRACkTIVE Project deals with the TD4.5 – Travel Companion. The
Travel Companion aims to act as the “face to the customer”. It’s an
application running on the traveller’s smart device. This application needs a
counterpart with server application as well as storage in the cloud.

In order to offer some meaningful capabilities to the traveller, the Travel
Companion has to store a profile per user, containing their preferences as
well as historical data. This private data will be stored in the cloud
component of the Travel Companion, in a cloud database to be accessible from
all of the Shift2Rail components. Of course, access to this data will be
controlled through state of the art authentication mechanisms.

Moreover, one component of the personal application will collect user data,
another one will collect the information generated by the mobile device
sensors. The data generated will be anonymously sent to a dedicated partial
Trip Tracker. The pTT will analyse the data and use it to detect disruptions
if any. This will allow the Trip Tracker to better analyse traffic, temporary
accessibility issues, finally providing other users with more complete and
more up to date information.

All the other data will be handled in the Travel Companion either in the
Personal Application or in the corresponding Cloud Wallet.

For the time being there is no data to be listed in the Travel Companion.  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Data**

**Set**

</th>  
<th>

**Description**

</th>  
<th>

**Origin**

</th>  
<th>

**Types/ Format**

</th>  
<th>

**Size**

</th>  
<th>

**Personal**

**Data**

</th>  
<th>

**Access/**

**License**

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

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

#  Table 9: WP2 - Data summary

**3.2.2 _FAIR Principles_ **

In this chapter the data used and created in the Travel Companion is to be
listed according to each of the FAIR categories.

As no data are listed, the FAIR categories need not to be detailed.

**3.2.3 _GDPR Issues_ **

Collected data as well as cloud wallet data are not intended to be openly
accessible.

They are generated within the project and could be only reused in IP4 projects
if needed. For this usage data security especially for private sensitive data
is ensured due to anonymizing them so that data of this type would be reused
in an aggregated form. At least data generated during the project are only
used for the development of new features to reach the mentioned objectives and
will be deleted after finalizing the project.

**3.2.4 _Specific Consideration_ **

No specific considerations regarding data within this WP.

**3.3 DMP of WP3: Technical Coordination**

**3.3.1 _Data Summary_ **

WP3 handles all activities regarding technical coordination within the
Consortium and manages interaction with other Shift2Rail complementarity
projects.

In particular WP3 will carry out integration and testing activities of the TDs
developed within WP1 and WP2 and will mostly rely on data generated amongst
them.

It will produce deliverables in the form of integration and synchronization
reports that will be disseminated at public level.  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Data Set**

</th>  
<th>

**Description**

</th>  
<th>

**Origin**

</th>  
<th>

**Types/ Format**

</th>  
<th>

**Size**

</th>  
<th>

**Perso nal**

**Data**

</th>  
<th>

**Access/**

**License**

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

WP3-

001-1

</td>  
<td>

OSM

tiles

</td>  
<td>

This is the Open Street Map's standard tile layer that can be used to display
maps in testing environments. Distributed experiences should use other
services to comply with the Tile Usage Policy.

</td>  
<td>

OSM

</td>  
<td>

TMS

</td>  
<td>

N/A

</td>  
<td>

No

</td>  
<td>

https://operati ons.osmfoun dation.org/pol icies/tiles/

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

WP3-

002-1

</td>  
<td>

Mapbox

Maps

API

</td>  
<td>

The experience engine also offers to use MapBox APIs to display maps in
testing or production environments.

</td>  
<td>

Mapbo

x

</td>  
<td>

WMTS

</td>  
<td>

N/A

</td>  
<td>

No

</td>  
<td>

Commercial agreements

https://www. mapbox.com/

pricing/

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

#  Table 10: WP3 - Data summary

**3.3.2 _FAIR Principles_ **

In this chapter the data used and created in Technical Coordination is to be
listed according to each of the FAIR categories. For the time being there is
no data according to FAIR principles listed.

• **Findable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Meta Data, Comments**

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

WP3-001-1

</td>  
<td>

Testing data can be obtained from the open street map website (
_https://www.openstreetmap.org_ ). Editors are available to create custom
maps.

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

WP3-002-1

</td>  
<td>

Testing data has been obtained from the mapbox website

( _https://www.mapbox.com_ ). It provides map design tools to customized maps
that suit the experience authors want to provide.

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

#  Table 11: WP3 - Findable aspects

• **Accessible aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Public/Private**

</th>  
<th>

**Specific Restrictions**

</th>  
<th>

**Access**

</th>  
<th>

**Comments**

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

WP3-

001-1

</td>  
<td>

Public

</td>  
<td>

Licensed under the Open

Data Commons Open

Database License (ODbL)

</td>  
<td>

</td>  
<td>

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

WP3-

002-1

</td>  
<td>

Public

</td>  
<td>

According to commercial agreements _https://www.mapbox.com/pricing/_

</td>  
<td>

Accessible through registered account.

</td>  
<td>

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

#  Table 12: WP3 - Accessible aspects

• **Interoperable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

</th>  
<th>

**Comments**

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

WP3-001-1

</td>  
<td>

Not Applicable

</td>  
<td>

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

WP3-002-1

</td>  
<td>

Not Applicable

</td>  
<td>

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

#  Table 13: WP3 - Interoperable aspects

• **Reusable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Comments**

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

WP3-001-1

</td>  
<td>

Maps from open street map can be used for any kind of experiences.

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

WP3-002-1

</td>  
<td>

The map used to create the testing and demonstration experiences are reusable
only for a testing and demonstration purpose.

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

#  Table 14: WP3 - Reusable aspects

**3.3.3 _Specific Consideration_ **

No specific considerations regarding data within this WP.

**3.4 DMP of WP4: Dissemination and Communication**

**3.4.1 _Data Summary_ **

This work package communicates the projects vision and results and ensures
that the partners of the related projects within IP4 will interact in a
seamless way by exchanging all relevant information. An essential part is to
organize expert and user groups to not only to inform relevant stakeholders,
but to collect their advice to take this into account during the development
of the system.  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Data**

**Set**

</th>  
<th>

**Description**

</th>  
<th>

**Origin**

</th>  
<th>

**Types/ Format**

</th>  
<th>

**Size**

</th>  
<th>

**Personal**

**Data**

</th>  
<th>

**Access/**

**License**

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

WP4-

001-1

</td>  
<td>

News-

letter

</td>  
<td>

ATTRACkTIVE

Project

Newsletter

</td>  
<td>

Produced by the consortium

</td>  
<td>

PDF

</td>  
<td>

<1M

</td>  
<td>

No

</td>  
<td>

Public

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

WP4-

002-1

</td>  
<td>

Project Identity and website

</td>  
<td>

ATTRACkTIVE

Project Identity and website

</td>  
<td>

Produced by the consortium

</td>  
<td>

PDF

</td>  
<td>

<1M

</td>  
<td>

No

</td>  
<td>

Public

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

#  Table 15: WP4 - Data summary

**3.4.2 _FAIR Principles_ **

In this chapter the data used and created in dissemination and communication
is listed according to each of the FAIR categories.

• **Findable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Meta Data, Comments**

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

WP4-001-1

</td>  
<td>

This document is a deliverable of the project, disseminated at public level.
Under the form of a newsletter, it details the project progress and status.

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

WP4-002-1

</td>  
<td>

This document is a deliverable of the project, disseminated at public level.
Its purpose is to describe the setup of the project website.

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

#  Table 16: WP4 - Findable aspects

• **Accessible aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Public/Private**

</th>  
<th>

**Specific Restrictions**

</th>  
<th>

**Access**

</th>  
<th>

**Comments**

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

WP4-001-

1

</td>  
<td>

Public

</td>  
<td>

read only

</td>  
<td>

This document has been published over the project website and is accessible in
the deliverable section.

</td>  
<td>

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

WP4-002-

1

</td>  
<td>

Public

</td>  
<td>

read only

</td>  
<td>

This document has been published over the project website and is accessible in
the deliverable section.

</td>  
<td>

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

#  Table 17: WP4 - Accessible aspects

• **Interoperable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

</th>  
<th>

**Comments**

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

WP4-001-

1

</td>  
<td>

Not applicable

</td>  
<td>

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

WP4-002-

1

</td>  
<td>

Not applicable

</td>  
<td>

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

#  Table 18: WP4 - Interoperable aspects

• **Reusable aspects**  
  
<table>  
<tr>  
<th>

**Code**

</th>  
<th>

**Comments**

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

WP4-001-1

</td>  
<td>

This document can be reused as a dissemination/communication tool to share
information regarding the ATTRACkTIVE project.

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

WP4-002-1

</td>  
<td>

No reusability is expected for this kind of document

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

#  Table 19: WP4 - Reusable aspects

**3.4.3 _Specific Consideration_ **

No specific considerations regarding data within this WP.

**4\. CONCLUSION**

The Data Management Plan has the following characteristics:

  * It is a document outlining how all the research data generated will be handled during the project life, and even after it is completed, describing, whether and how these datasets will be shared or allowed data re-use and also allow validation of results presented in scientific publications generated by the project. 

  

  * It is a document outlining how all the research data and non-scientific documents generated during the lifetime of the project will be handled in terms of sharing policies, archiving and storage and preserving time.