#  Executive Summary

The current document constitutes AVENUE first version of Data Management Plan,
D1.4: “Initial Privacy protection & Data Management Plan” and is the 1st
version of the project’s guide as to how the Consortium will manage the data
throughout all its phases (collection, storing, sharing, processing etc.),
what decisions the Consortium will make regarding making data Findable,
Accessible, Interoperable and Re-usable (FAIR) and the mechanisms to enable
the data management decisions.

AVENUE aims at providing citizens with door-to-door public transport services
to facilitate their mobility through autonomous mini buses. The project aims
to include all potential types of users coming from diverse background and
travel habits and preferences in order to offer tailor-made solutions that
meet their needs.

To provide the above-mentioned solution, the project will collect user-related
data. The Consortium must fully comply with any laws and regulations in any
relevant jurisdiction relating to privacy or the use or processing of data
relating to natural persons. These include:

  1. EU Directives 95/46/EC and 2002/58/EC (as amended by 2009/139/EC) and any legislation implementing or made pursuant to such directives and the Privacy and Electronic Communications (EC Directive) Regulations 2003; 

  

  2. from 25 May 2018, the EU General Data Protection Regulation 2016/679 ("GDPR"); and 

  

  3. any laws or regulations ratifying, implementing, adopting, supplementing or replacing GDPR; in each case, to the extent in force, and as such are updated, amended or replaced from time to time. In specific, following the EC guidelines for the Data Management Plans [1], **Chapter 1** introduces the purpose and intended audience of the current document as well as the interrelations to other project work items. 

  

  

**Chapter 2** presents the nature of the data to be handled in AVENUE, its
categorisation, sources, the privacy policy as well as the template to be used
for describing the datasets and the objectives of the project that will be met
through these data collection and processing.

**Chapter 3** describes the data collection and storage processes, data
protection, retention policy, access, sharing, ownership as well as any
measures to be taken for preventing malevolent abuse of the research findings.

**Chapter 4** describes the processes and the mechanisms that will be applied
for making the data FAIR. **Chapter 5** refers to the necessary GDPR compliant
roles that will be allocated for the smooth operation of the project. It also
presents the project’s ethical policy, ethics helpdesk and all relevant
ethical aspects, which will/is further defined in Deliverables D11.1, D11.2,
D11.3 and D11.4.

Finally **, Chapter 6** concludes the document.

The current document is a living document and thus it will be updated during
the project lifetime as needed, including more detailed information regarding
collected data. The next official updated version will be publicly released as
part of D1.5 “Final Privacy protection & Data Management Plan”, in Month 48,
providing final information about the descriptions of different data sets, the
AVENUE repository, final DPIA report (the template form can be found in Annex
1.2, as well as any data embargos and data destruction periods).

IV

#  Introduction

Public transport consists of a key element in the economic development of a
region and the quality of life of its citizens. Throughout the years,
municipalities and public transport operators aim to improve services through
an optimal balance between increased and improved service (more vehicles, more
km, comfortable, convenient, reliable, etc.), usage incentives (lower fares,
Parkingand-Rail etc.) and costs. At the same time, the most common criticisms
of public transport concern the low speed and flexibility compared to private
cars, the high transport fees and the reliability and availability of the
service.

“ **A** utonomous **V** ehicles to **E** volve to a **N** ew **U** rban **E**
xperience” (AVENUE) project will especially focus on introducing disruptive
public transportation paradigms led by SMEs on the basis of door2door services
and the nascent concept of the ‘Mobility Cloud’ aiming in setting up a new
model of public transportation.

##  Project objectives

AVENUE aims to deploy and validate autonomous vehicles that are integrated in
the existing public transport services for several European cities and to
validate the safety of autonomous vehicles being used in complex urban
environments. Additionally, the project aims to develop and test new,
innovative and disruptive urban public transport services based on the use of
autonomous vehicles, so as to raise user awareness and increase user
acceptance. At the same time, AVENUE will ensure that the use of autonomous
vehicles within the context of urban public transport services is a new
experience for the passengers. Recommendations will be made for public
transport operators and authorities concerning the development and integration
of autonomous vehicles in the urban and sub-urban transport environments to
encourage the promotion of the advantages of public transport autonomous
vehicles to the public. Finally, AVENUE will evaluate the socio-economic
impact and the benefits of the deployment of autonomous vehicles for urban
public transport.

##  Conceptual architecture

The figure below depicts AVENUE’s conceptual architecture, including all
different elements and roles needed to provide the personalized point-to-point
services:

  1. Transport operators and bus manufacturers that will collaborate to improve fleet management, service optimisation and access bus performance analytics; 

  

  2. The AVENUE core service platform; 

  

  3. Transport infrastructure and the automobile and pedestrian traffic that provide the AVENUE core service platform with itineraries/status and city/traffic information respectively; 

  

  4. Autonomous minibus that includes the autonomous vehicle control; 

  

  5. Human assistant inside the vehicle that caters to special services addressing users with special needs; 

  

  6. The vehicle passengers that request the in-vehicle services; 

  

  7. The user interfacing (smartphones, call centre, cell phones) that handles in and out vehicles responses; 

  

  8. Out of vehicle users that interact with the AVENUE platform through transport requests and request of information/validation. 

  

  

**Figure 1. AVENUE conceptual architecture**

##  Purpose of the document

This document is the first version of the project’s Data Management Plan
(DMP). The purpose of this document is to provide an overview of the data set
types and categories collected during the lifetime of the project and to
define the project’s data management policy that will be further adopted by
the Consortium.

The data management plan defines how data in general and research data will be
handled during the research project and will make suggestions for the after-
project time. It describes what data will be collected, processed or generated
by the AVENUE core service platform and by all the AVENUE ecosystem, what
methodologies and standards shall be followed during the collection process,
whether and how these data shall be shared and/or made open not only for the
evaluation needs but also to comply with the General Data Protection
Regulation (GDPR) requirements. In addition, this document will define how
they shall be curated and preserved. The AVENUE Data Management Plan will be
updated by the evolution of the project.

The overarching project-related GDPR mechanisms are the following:

  * **completing** the GDPR compliance template by all project partners that will collect, store and analyse data (template can be found in Annex 1.1); 

  

  * **preparing** the Data Protection Impact Assessment in two stages (template can be found in Annex 1.2); 

  

  * **determining** and assigning the roles of DPO (Data Protection Officer) at each pilot site;  **defining** the data protection policy of the project. 

  

This initial version of D1.4, which is submitted in Month 6, identifies a
first set of data sources, data categories, datasets, data types and metadata
that will be involved in the project and describes the data management process
that will be followed in the next steps of the project. This version also
includes how the data owners will contribute to further versions of the
deliverable to complete their dataset descriptions.

The Data Management Plan is a living document that will be updated with new
information as they arise throughout the duration of the project. The
Deliverable will be updated in M48 through deliverable D1.5 and will include
the final services offered to users by the AVENUE platform, final data from
all partners, finalised decisions on embargo policy as well as finalised
decisions and processes for any pending issues that are not specified early on
the project.

##  Intended audience

The intended audience for AVENUE consists of project partners who are involved
in data handling in any manner during the project’s lifecycle. These are the
project Consortium and the partners that are involved in the pilot tests who
collect, store and process information throughout the project, the developers
that develop the platform and are expected to ensure data protection, the
partners that will publish their work as well as all members that participate
in the dissemination process of the project.

##  Interrelations

Data Management aspects are closely related to:

  1. **Ethics Issues** in AVENUE, especially in the context of collecting, managing and processing 

  

  

(sensitive) personal data from real-life users;

  2. **Security aspects** , e.g., data privacy and protection, data ownership, etc.; 

  

  3. **Design and development activities** in terms of defining the data that need to be collected or reused to offer tailored services to each specific user group (i.e., older people, people with disabilities, commuters, business travellers, tourists, etc.); and 

  

  4. **Legal issues** related to personal data (including sensitive personal data), security and privacy. 

  

  

Therefore, this document will be updated as the work evolves and in close
synergy with the following tasks:

  * WP1: T.1.4. IPR & Data Management Plan 

  

  * WP2: T.2.2. Passenger needs (including PRM) and requirements specification 

  

  * WP2: T2.3 Stakeholders identification, expectations and barriers imposed 

  

  * WP5: T5.2 Data and fleet coordination and management 

  

  * WP6: T6.3 Security and privacy control 

  

  * WP7: Autonomous vehicles for public transport demonstrators 

  

  * WP8: Socio-economic and environmental evaluation 

  

  * WP11 - Ethics requirements 

  

The work packages interrelations are presented in the figure below (Figure 2).

**Figure 2 Interrelations of AVENUE's work packages (WPs)**

#  AVENUE data

##  Data summary

This section provides an explanation of the different types of data sets to be
produced or collected in AVENUE project, which have been identified at this
stage of the project. As the nature and extent of these data sets can evolve
during the project, more detailed descriptions will be provided in the updated
versions of the DMP. The descriptions of the different data sets, including
their reference, file format, standards, methodologies and metadata and
repository to be used are given below.

The aim of this chapter is to:

  * provide a first categorization of the data; 

  

  * identify a list of the data types that will generated; 

  

  * provide a list of metadata that will be used to describe generated data and enable data re-use; 

  

  * provide recommendation on data collection and sharing process during the project and beyond 

  

As the nature and extent of these data sets can evolve during the project,
more detailed descriptions will be provided in the updated versions of the
DMP. The descriptions of the different data sets, including their reference,
file format, standards, methodologies and metadata and repository to be used
are given below.

##  Data presentation

###  Data identification

The AVENUE project will produce different categories of data sets. Based on
the information collected from the above-mentioned template, data is
categorised appropriately, as follows:

  * **Data types** : this category refers to the type of data in terms of its source and relevance (i.e. vehicle related data, user data etc.); 

  

  * **Data sets** : refers to the nature of a complete set of data, that may contain information about different topics (i.e. an excel file containing information about user preferences); 

  

  * **Dataset category** : refers to the categories of data based on the level of process (i.e. raw, pre-processed, aggregated, consolidated, metadata, etc.). 

  

In order to identify and define the data types and data management procedures,
a template was circulated to the partners to be completed with information and
descriptions about the data and metadata that will be collected with their
service/tools. The description includes some technical information (such as
format, size, privacy level, etc.) but will be further clarified and updated,
if necessary, in following versions.

In detail, the template collected information about the following:

  * The name of the data 

  

  * Whether the data was collected or created 

  

  * Data description 

  

  * Data category 

  

  * Data type 

  

  * Data format 

  

  * Data size 

  

  * Data Ownership 

  

  * Privacy level 

  

  * Data repository during the project (for private/public access) 

  

  * Data sharing 

  

  * Back-up frequency 

  

  * Status of data at the end of the project (destroyed or not) 

  

  * The duration of the data preservation (in years) 

  

  * Data repository after the project is complete 

  

The information gathered was analysed so as to identify the types of data and
determine how to manage it within the Data Management Plan and as instructed
by the GDPR principles.

###  Data sources

This section describes the data sources and data flows as determined by
**Figure 3** , which depicts a generic AVENUE diagram and demonstrates the
main data flows in three data flow stages. In AVENUE the following **user
groups** are determined as **data sources** : Autonomous Minibus, Data
providers, Customers, the AVENUE core services and the Operators. The
following figure (Figure 3) depicts the main data sources that will contribute
to the AVENUE core services and the main data flows, in three stages that are
transferred from one to another.

More specifically, during the first flow stage, initial data comes from the
following three user groups:

  * **Autonomous Minibus** : This group provides information about the vehicles that participate in the project as well as information related to emergency control needs. 

  

  * **Data Providers** : data providers provide information about the public transportation, city conditions, traffic state and any other form of data concerning the urban environment where the pilots are taking place. 

  

  * **Users/Customers** : participating users/customers provide information from inside and outside the vehicles about their preferences, needs and wants. 

  

Then, for the second flow stage, the above collected information flows towards
the **AVENUE core services** group, so as to cover the following activities:

  * Handle passenger requests; 

  

  * Provide solutions according to transport policies and provide feedback to help them improve as necessary; 

  

  * Build and provide Vehicle-to-Platform interfaces and data transfer protocols; 

  

  * Achieve dynamic route planning and fleet optimisation; 

  

  * Improve decision making and dispatching of resources and vehicles as necessary;  Ensure GDPR compliant data management. 

  

Finally, information ends up at the **operators’** end to inform surveyors,
administrators and policy makers so that they can proceed with the appropriate
decision making and policy making that will bring about the expected results.

AVENUE project will collect a large amount of raw data to measure and identify
the needs of passengers to provide integrated point-to-point services, as well
as handle information from vehicles, transport providers and bus
manufacturers.

From raw data, a large amount of derived data will be produced to address
multiple research needs. Derived data will follow a set of transformation:
cleaning, verification, conversion, aggregation, summarization or reduction.
In any case, data must be well documented in order to facilitate and foster
sharing, to enable validity assessments and to enable its efficient use and
re-use. Thus, each data must be described using additional information called
**metadata** . The latter must provide information about the data source, the
data transformation and the conditions in which the data has been produced.

The following list further summarises and describes **the data types** and
**data** **sources** that will be collected:

**Autonomous Minibus** : The Autonomous Minibus information is the data
collected from the vehicles that take part in the pilots.

The data that describes the condition and the mobility of the vehicle. Such
data can be, for example, longitudinal speed, longitudinal and lateral

Vehicle info acceleration etc. The vehicle information is shared between the
Autonomous Vehicle Control (AVC) and the closed circuit that is used by the
operators for communication and control.

####  Picture 1 Sensors and equipment to collect data on the AVENUE mini buses

**Data providers:** The information from data providers refers to traffic
data, smart city/open data and public transportation information. More
specifically:  
  
<table>  
<tr>  
<th>

T _raffic data_

</th>  
<th>

Provides information about how travel speeds on specific road segments change
over time.

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

Smart city/open data

</td>  
<td>

Information that is freely available to users

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

Public This data consists of information about public transportation services
and transportation schedules.

**Customers** : information from final users, which are out-of-vehicle people,
in-vehicle people and operators.

Out-of-vehicle Information from/about people waiting for AVENUE services.

In-vehicle Information from/about people enjoying the AVENUE services
(passengers).

Operators Information from/about professionals who work either as distant
surveyors or system administrators.

**AVENUE core services** : describes information from all previous user groups
that is necessary for the smooth and uninterruptible operation of AVENUE
services.  
  
<table>  
<tr>  
<th>

Data management

</th>  
<th>

Describes the way information is exchanged and managed.

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

Decision making and dispatching

</td>  
<td>

Refers to information necessary for the decision-making process and for the
dispatch of an autonomous vehicle towards a customer.

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

Fleet optimisation

</td>  
<td>

Information that allows for optimum use of fleet.

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

Dynamic route

planning

</td>  
<td>

Data concerning optimum route planning and taking.

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

Vehicle-to-Platform interfaces and data transfer protocols

</td>  
<td>

Information exchanged between the vehicle and the platform.

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

Passenger requests

</td>  
<td>

Information regarding the needs and preferences of passengers.

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

Transport policies Information concerning the existing policies in the
transport sector.

###  Data collection

Within the project’s framework, a socio-economic and environmental impact
assessment will be conducted. To this end, several methods will be applied to
collect the necessary information. The data that will be collected refer to
user experience, accessibility for persons with restricted mobility (PRM),
socio-economic and environmental acceptance. The following table (Table 1)
summarises the research methods and tools that will be used for the collection
of this data.

####  Table 1 Objectives, methods and tools used in user related data
collection  
  
<table>  
<tr>  
<th>

Objective

</th>  
<th>

</th>  
<th>

Method

</th>  
<th>

Tools

</th>  
<th>

</th>  
<th>

</th>  
<th>

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

User experience

</td>  
<td>

</td>  
<td>

Qualitative

</td>  
<td>







</td>  
<td>

Longitudinal studies

Accompanied observation

Focus groups

</td>  
<td>

</td>  
<td>

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

Quantitative

</td>  
<td>



</td>  
<td>

Shadowing/observation questionnaire

</td>  
<td>

</td>  
<td>

plus

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

Socio-economic

</td>  
<td>

and

</td>  
<td>

Quantitative

</td>  
<td>



</td>  
<td>

Shadowing/observation

</td>  
<td>

</td>  
<td>

plus

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

environmental acceptance

</td>  
<td>

</td>  
<td>



</td>  
<td>

questionnaire

Large scale survey: zero measurement, intermediate measurement, final control
measurement

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

</td>  
<td>

</td>  
<td>



</td>  
<td>

Big Data analysis (videos recorded in the busses could be analysed)

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

Accessibility for PRM

</td>  
<td>

Qualitative

</td>  
<td>





</td>  
<td>

Focus groups

Accompanied observation

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

Data collection regarding user needs, traffic, preferences, etc. throughout
the pilots will be made using paper-and-pencil and online questionnaires. The
gross random sample will range from five to eight thousand residents, elected
randomly and living in a thirty to fifty-kilometre radius via post code areas.
Invitations will be sent by email (if personalised e-mail addresses are
available) with the link to the online questionnaire or by post with a paper-
and-pencil version of the questionnaire and a return envelope. The net sample
will depend on the return flow, although a minimum of 10% is expected. The
paper pencil version of the questionnaire will be scanned via _evasys_ (
_https://en.evasys.de/_ _)_ , the online questionnaire will automatically be
registered via _Unipark_ ( _https://www.unipark.com/en/_ )  and the
statistical analyses will be made via SPSS. Respondents will consent to be
contacted via email prior any project-related communication takes place in
order to comply with GDPR requirements. The process will be described in the
PIA report submitted in the final version of this Deliverable in Month 48.
However, the methodology applied will be reported in an intermediate stage by
involved partners, when pilot plans are set and before any testing is
conducted. As this Deliverable is treated as a living document, when the
processes are put in motion and are reported, then they will be added in the
Deliverable.

Vehicle operation related data will be collected through sensors, pavement
tapes, proximity sensors, seat sensors, surveillance cameras, etc. will be
managed in accordance with local policies of the operators.

###  Data types, datasets and dataset categories

This section presents a short description of the data that will be collected,
generated and managed in AVENUE. More specifically, data is clustered into
three different sections: **data types** , **datasets** and **datasets**
**categories** . Data types are related to the source of the data, i.e.
vehicle data, traffic data, etc., datasets refer to the file extension of the
data and, finally, dataset categories refer to the level of process that the
data has undergone.

The **types** of data generated, collected and managed within AVENUE fall into
the following categories:

  * Subjective data (user profile and user request related data) 

  

  * Vehicle related data 

  

  * Urban environment related data (traffic and city related data) 

  

  * Infrastructure related data 

  

As far as **datasets** are concerned, the following will be handled by AVENUE:

  * Reports (in the form of word or pdf documents) 

  

  * Excel files with raw data, as received by sensors, surveys etc. 

  

  * Video signals 

  

  * Database 

  

The following table is a template that will be used to describe the datasets.
**Table 2 – Dataset Description template**  
  
<table>  
<tr>  
<th>

**Dataset Reference**

</th>  
<th>

AVENUE_WPX_TX.X_XX

Each data set will have a reference that will be generated by the combination
of the name of the project, the Work Package (WP) and Task (T) in which it is
generated and (for example: AVENUE

_WP3_T3.4_01)

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

**Dataset Name**

</td>  
<td>

Name of the data set

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

**Dataset Description**

</td>  
<td>

Each data set will have a full data description explaining the data
provenance, origin and usefulness. Reference may be made to existing data that
could be reused.

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

**Standards and metadata**

</td>  
<td>

The metadata attributes list

The used methodologies

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

**File format**

</td>  
<td>

All the format that defines data

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

**Data Sharing**

</td>  
<td>

Explanation of the sharing policies related to the data set between the next
options:

**Open** : Open for public disposal

**Embargo** : It will become public when the embargo period applied by the
publisher is over. In case it is categorized as embargo the end date of the
embargo period must be written in DD/MM/YYYY format.

**Restricted** : Only for project internal use.

Each data set must have its distribution license.

Provide information about personal data and mention if the data is anonymized
or not. Tell if the dataset entails personal data and how this issue is taken
into account.

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

**Archiving and**

**Preservation**

</td>  
<td>

The preservation guarantee and the data storage during and after the project
(for example: databases, institutional repositories, public repositories …)

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

The AVENUE project will produce different dataset categories. More
specifically:

  * **Context data** : data that describes the context of a pilot. 

  

  * **Acquired and derived data** : data that contains all the collected information related to a pilot. 

  

  * **Subjective data** : questionnaires, surveys, personal and group interviews. 

  

  * **Raw/unprocessed data** : data collected directly from the source (either objective or subjective). 

  

  * **Metadata** : descriptions of data that will facilitate the data analysis and data pre-processing. 

  

  * **Aggregated data** : data summary obtained by reduction of acquired data and generally used for data analysis. 

  

  * **Consolidated data** : data collected across sites and per data type. 

  

###  Subjective data types

This type of data is collected during all types of qualitative surveys,
questionnaires, personal and group interviews (WP2) that take place in the
project. This data is **collected** , **managed** and **processed** by AVENUE
partners. The data may be collected from users/customers, data providers and
operators as well as other types of stakeholders. In all cases, the data
is/will be anonymised to ensure privacy and protection of the participants’
identity. In the case of the users/customers, subjective data will mostly deal
with travel preferences and needs.

###  Data privacy policy

Participants’ personal data will be used in strictly confidential terms and
will be published only as statistics (anonymously). In addition to the ethical
aspects analysed, the following safety provision will be considered during the
project:

Only one person per site (relevant Ethical issues responsible) will have
access to the relation between test participants’ code and identity, in order
to administer the tests. This means that data will be pseudonymised, making
the compliance with GDPR essential. The GDPR compliance form will be filled in
by all project partners throughout the duration of the project. The GDPR
compliance form is found in Annex 1.1. Further to that, all partners will fill
the Data Protection Impact Assessment form (Annex 1.2), again throughout the
duration of the project. The filled in forms will be presented in D1.5 (due
for Month 48). One month after the pilots end, this reference will be deleted,
thus safeguarding full anonymisation of results. The data will be gathered at
each pilot site with consideration for the following aspects and compliance to
GDPR:

  * **Confidentiality and data protection** : Participants, and the data retrieved from them (performance or subjective responses) must be kept anonymous unless they give their full consent to do otherwise. 

    * Identifiable personal information should be encrypted (i.e. pseudonymisation and coding). Otherwise ethical approval is necessary specifically for this; 

  

    * Pseudonymisation is preserved by consistently coding participants with unique identification codes. Only one person at each pilot site will have access to personal identifiers (if any). 

  

    * Each individual entrusted with personal information is personally responsible for their decisions about disclosing it; 

  

    * Pilot site managers must take personal responsibility for ensuring that training procedures, supervision, and data security arrangements are sufficient to prevent unauthorised breaches of confidentiality. 

  

  

  * **Encrypted and pseudonymised data** : To mitigate the risks involved with processing data subject information, any data collected will be encrypted or pseudonymised to the extent reasonably possible, so that individuals cannot be identified, as recommended by Article 32 of the GDPR. Pseudonymised data is data that can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person [2]. 

  

Any data that will be stored will not consist of personal information that can
lead to the person giving the information. Nevertheless, stored date relate
only to users’ preferences in daily activities or health problems, not to a
person’s beliefs or political or sexual preferences.

The following data will **_not_ ** be stored:

  * Medical info. 

  

  * Name, address, telephone, fax, e-mail, photo, etc. of the user (any direct or indirect link to user ID). 

  

  * User location (retrieved every time dynamically by the system, but not stored). 

  

  * Any other preferences/actions by the users, except the ones motioned explicitly above. 

  

  * Destination of the users (will be used to provide the service but will not be stored). 

  

In addition, aggregated data and conclusions related to impact estimations
will be shared with researchers outside the Consortium upon agreement to do
so, as the project participate in the Open Research Pilot. This will be
decided and finalised in the updated version of the Data Management Plan in
D1.5.

For statistical analysis, the decisions made by the participants may be
associated with their type, their travelling preferences, age, gender,
nationality, familiarity and use of services and transport modes, etc. This
will be decided and finalised in the updated version of the Data Management
Plan in D1.5.

AVENUE core services platform aims to provide users with high quality door to
door services. However, it will perform this taking into consideration the
following:

  * All required user profile data will be stored at his/her mobile device and be securely protected (by password or highly advanced security mechanisms; this depends upon how much the user is willing to invest on it). 

  

  * Relevant preferences relate to his/her mobility, favourite locations, frequent routes will be stored in their mobile device and be securely protected (by password or highly advanced security mechanisms; this depends upon how much the user is willing to invest on it). 

  

  * The user’s location, route and destination will be only temporarily stored (i.e. during a trip), in order to assist the user and will be automatically deleted afterwards. Any location information will be stored on the user’s mobile device, discharging the consortium from any responsibility of handling sensitive data. 

  

  * The user will have the capacity to view, change or delete, as he/she wishes, all stored data by the system (including his/her profile data), with the help of a very simple and multimodal interaction (touch, buttons and voice input supported). 

  

  * All AVENUE applications are using unobtrusive sensors, i.e. embedded on a seat or wearable, avoiding the use of cameras and other visual detection sensors that may be misused by an intruder. 

  

The above data privacy policy applies also on any communication dissemination
activities held within the project to promote its results and communicate new
knowledge.

##  GDPR compliant system architecture

The following figure depicts the detailed architecture of the AVENUE system.
At the bottom of the detailed AVENUE architecture lies the Multisensor Data
Collection System (MDCS). This is the sensing layer that consists of several
sensors, whose purpose is to detect changes and events in their environment
(either the autonomous mini bus, the interior or the exterior). This layer
consists of three groups of sensors. As depicted in the graph (Figure 4), the
sensors can be road pavement tapes, proximity sensors, privilege passenger
presence, seat sensors, surveillance cameras, route cameras, geographic
positioning systems (GPS), global system for mobile (GSM), Light Detection And
Ranging (LIDAR) or accelerometers.

The information collected by the sensors is sent to other complex electronics
through the **Data Transfer** layer, entailing all processes for the transfer
of information from the collection devices and equipment towards the command-
control-communication level. The **Command-ControlCommunication (C3)** is the
main services layer for the AVENUE project. Within this layer, software
components will receive information from the sensors’ layer, process it and
allocate it to the respective sub-components to support activities such as
decision making, route planning, management of passenger requests, incident
management. At the same time, there will be an Automatic Threat Detection
component to further raise passengers’ acceptance, evaluating the behaviour of
passengers. A sensor’s data processing and modeling component will do all the
processing and update the Sensor’s Database. A Decision Support System (DSS)
will assist with the decision-making activities and will help administrators
and surveyors to make decisions about possible issues.

Within the C3 level, the data collected and captured undergoes encoding before
being preprocessed. The data that is encoded includes data from infrastructure
sensors, data regarding passengers’ registration and presence as well as user
location. Data encoding implies that it cannot be retrieved from the database
by unauthorized users, complying with GDPR regulations about data security.

##  Data documentation

Data documentation will mostly be metadata and will be used in order to
recognize each data type and source. The initial documentation details that
will be included for each service are shown below.

##  File naming

File naming depends largely on service and the datasets to be derived by this
service and/or connected with this service. They have to be **consistent** and
**descriptive** .

The creation of the unified database will be based on a common file naming and
organizing among partners in order to help partners organize effectively and
efficiently their work and, of course, ease collaboration with other partners.
Additionally, partners using this file naming system will find it easier to
work (and share) the correct version of data and accompanying metadata files.
The following file naming offers a consistent naming of the files in order to
make it easier to identify, locate and retrieve the data files.

This file and folding naming system will be used for all data and metadata
files.

  1. **Project acronym:** AVENUE 

  

  2. **Service related:** Service acronym (initials based on the name given in DoA) 

  

  3. **Location (where it resides):** e.g. DFA_DB (Daily Functions Assistance Database) 

  

  4. **Researcher name/initials:** Ian Smith (i.e. IS; alternatively, could use database user credentials) 

  

  5. **Pilot identifier:** e.g. GP for Geneva Pilot site 

  

  6. **Date or range of pilot:** 011216 

  

  7. **Type of data:** CE for calendar entries 

  

  8. **Conditions:** condition_user group (e.g. baseline_PT) 

  

  9. **Version number of file:** Only singular number are acceptable (1, 2, 3) 

  

  10. Three letter file extension for application specific files (e.g. csv) 

  

  

Any spatial characters are avoided because they might not work well with
certain programmes and avoid spaces (i.e. use underscores instead). Each data
folder will include a regularly updated README.txt in the directory to explain
the codes, abbreviations used and, in general, the coding practices and naming
conventions used. Based on the example used above, an efficient naming
convention within the AVENUE project looks like that:

**AVENUE_DFA_ DB_IS_GP_011216_CE_baseline_PT_v1.csv**

#  Data Collection and Storage Methodology

As previously stated, data will be stored in secure server systems. Only the
PC and selected personnel from demonstrators will possess the key to re-
identification, making the data pseudonymised. No data related to personal
information of the involved participants will be collected and stored.
Instead, all participants will be granted with an identification number based
on each participant’s role in each of the city (role ID), allowing mapping of
participants’ actions during the execution and pilot realisation phase. The
relationship between the role ID and the participant will be recorded at the
repository and will be stored separately and securely. This file will be
accessible only to the corresponding site manager. The key to link the
participant’s name to the code which identifies the data file will not be
provided to anyone and the privacy of the data will be protected. Furthermore,
data will be kept for the least a period of time necessary to accomplish the
goals of the project and the population of the AVENUE Repository. This period
of time will be defined when the pilot data collection process will be
established and after Consortium consensus.

In any case, all data that will be considered confidential from the pilots
will be discarded by the project completion, whereas only the public models
and respective datasets that will be described in detail in the Data
Management Plan will be kept open. Partners will define the data embargo
period (if any) and those who are data owners will decide which datasets (or
parts of) will be openly shared. Such decisions will be made after AVENUE
datasets have been collected.

##  Data protection

In order to protect the collected data and control unauthorised access to the
AVENUE data repositories, only authenticated personnel will have access to
pilot-specific data collected. During the proposed system lifecycle, a
holistic security approach will be followed, in order to protect the pillars
of information security (confidentiality, integrity availability) from a
misuse perspective. The security approach will be identified by a methodical
assessment of security risks followed by their impact analysis. This analysis
will be performed on the personal information and data processed by the
proposed system, their flows and any risk associated to their processing. The
details on measures to prevent misuse of data and research findings as well as
the performance of security audit and data privacy assessment will be reported
in the related Ethics deliverables.

Towards the protection of personal data of volunteer pilot participants, the
following issues will be taken into account:

  * All data associated with a recognizable person will be held private. 

  

  * Individual data on participants will be used in strictly confidential terms and will only be published as statistics (anonymously). 

  

  * Any data or information about a person will be held private, regardless of how this data was acquired. Therefore, data obtained incidentally within AVENUE project will be handled with confidentiality. This accidental obtainment does not substitute the compulsory procedure, in which researchers need each participant’s explicit consent to obtain, store and use information about them. 

  

  * Data collection will be anonymous but data are defined as pseudonymized because their personal details will be securely stored. Only one person will have access to these details and no access to pilot data. Contact details are kept in case we wish to contact participants for participation in another pilot phase. However, as pilot plans are not still in place, we state that data are pseudonymised. If pilot data collection will not entail keeping contact details, then data will be fully anonymized. 

  

  * The acquired data will under no circumstances be used for commercial purposes. 

  

During the AVENUE project, responsibilities will be clearly assigned for the
overall management and control of research findings and the controlling of
access rights. The person who will be responsible on issues for data security
will directly inform to the quality board, the ethics helpdesk and the project
coordinator.

##  Data storage, backup and repository

Data collected by the AVENUE services and the pilots must be securely stored
and regularly backedup. In some cases, multiple copies should be made,
especially for large datasets that need to be stored in large capacity
external drives. To this end, the data management plan has to ensure the
following checklist is ticked:

How will the raw data be stored and backed-up during the research project?

How will the processed data be stored and backed-up during the research
project?

What storage medium will be used for the storage and backup strategy?

Is the backup frequency sufficient to ensure data restoration in the event of
data loss? Is the data backed up at different locations?

A **Data Repository** will be created for the purposes of storage during the
project and potentially for a period of time after the projects is complete.
The project’s repository will be hosted at the University of Geneva (UniGe).
It is physically located in the premises of the university, where there will
be regular back-ups and continues intrusion controls with the use of advanced
security detection systems. Further to that, the repository will be strongly
protected in conformation with current security practices.

Access to the data repository will be given to project participants through an
identification number based on each participant’s role in each of the city
(role ID), that will allow the mapping of participants’ actions during the
execution and pilot realisation phase. This file will be accessible only to
the corresponding site manager. The key to link the participant’s name to the
code which identifies the data file will not be provided to anyone and the
privacy of the data will be protected. The relationship between the role ID
and the participant will be recorded at the repository and will be stored
separately and securely. Data will be kept for the least period of time
necessary to accomplish the goals of the project and the population of the
AVENUE Repository. In any case, all data that will be considered confidential
from the pilots will be discarded by the project completion, whereas only the
public models and respective datasets that will be described in details in the
Data Management Plan will be kept open.

However, not all partners have yet decided which strategy to follow and how to
proceed with their data storage policy and backup frequency. This will be
finalised in the next version of the Data Management Plan D1.5.

It is common practice to store the data for a time period of 2 to 3 years
after the project is complete. The data produced in the project as Public
Deliverables have, in principle, no expiration data and can be kept for at
least ten years in the project’s repository. Data that is collected from
interviews, vehicle operations, pilots etc. will be handled differently; the
anonymised part of data will be retained (and possibly made available to
researchers) while vehicle operation data will be handled according to the
policies of the operators as the data may be requested for legal purposes by
the authorities. This data will not be public and will be erased from the data
repository only to remain stored at the operators’ systems.

Partners may choose to keep the data for some time, indefinitely or even
delete as soon as the project is complete. NAVYA and CEESAR have decided that
information that is collected by sensors regarding incidents/accidents,
nominal behaviour, reports and incident/accident database will be stored in a
private cloud for a duration of four (4) years and will be destroyed at the
end of the project. Other partners will decide about the duration of storage
within the following months. This is an issue to be determined as the project
continues and will be finalised in the updated version of the Data Management
Plan, D1.5 due for M48.

##  Data retention and destruction policy

Within the AVENUE Data Management Plan, the open research data retention and
destruction strategy will be also reported along with the limits on their
secondary use and their disclosure to third parties. A number of critical
factors that are relevant for data retention will be taken into account,
namely:

i) Purpose of retaining data, ii) Type of open data collected, iii) Policy
access to the open data, iv) Data storage, security and protection measures
and v) Confidentiality and anonymity of data.

According to the project’s data retention policy, the data stored for the
purposes of the project will be deleted after 4 years after the completion of
the project. This will take place from authorized partners to ensure data
deletion is conducted in a correct and legal manner and it is also subject to
changes and modifications during the project, if considered necessary.

Regarding **data destruction** , as computerized data (hard disk drives) will
be used for data storage, existing methods for permanent and irreversible
destruction of the data will be utilized (i.e. full disk overwriting and re-
formatting tools). In all cases the data protection and privacy of personal
information will be governed by the following principles, which consist of
part of an overall information security policy:

  * Protective measures against infiltration will be provided; 

  

  * Physical protection of core parts of the systems and access control measures will be provided; 

  

  * Logging of AVENUE system and appropriate auditing of the peripheral components will be available. 

  

##  Data access, sharing and reuse

At each pilot site, a nominated person will be responsible for overseeing that
data are safe and secure. Overall, data will be stored in secure server
systems and will be anonymised. Only the PC and selected personnel from
demonstrators will possess the key to re-identification. No data, related to
personal information of the involved participants will be collected and
stored.

One person will be allowed to have **access** to full datasets (i.e. higher
authorisation level) and the rest of the data team will have medium or lower
level of authorisation. Data will be stored in secure areas (physical,
network, private cloud-based). Higher level of authorisation is granted only
for sensitive and personal data. According to the system architecture,
sensitive information received by sensors and users is encoded, making access
to the data from unauthorised users impossible. Data to be shared for analysis
or transferred to the AVENUE database will not include any personal or
identification data.

Data collection, storing, accessing, and sharing abides to the international
legislation (Data Protection Directive 95/46/EC “on the protection of
individuals with regard to the processing of personal data and on the free
movement of such data”) and guidelines.

Different levels of authorisation will exist also for remotely accessing data.
High level access to data will not be possible outside the work premises, as
they are defined at each pilot site.

Use of cloud store data will be available for medium and lower level of
access. Not all individuals will have the same access privileges in order to
avoid data corruption, loss and damage. Dataset owners will have full access
(read, write, update, delete), however, individuals who want to use/reuse the
dataset will be able to read and download but not make any changes or
modifications to the specific dataset. Of course, all datasets will be
password-protected. In some cases, encryption will be necessary.

The main restrictions with regards to confidentiality are the following:

− Name

− GPS coordinates (only metadata or surrogates)

− Raw video and audio recordings

The above data is identified based on the initial data pools set by partners
responsible for services/tools. Other data restrictions might arise during the
course of the project. If so, they will be finalised in the next version of
the deliverable, D1.5.

Concerning **data sharing** , under Horizon 2020, publications resulting by
work performed within a project have to be in open-access journals [3].
Participating in an open scholar community can help make the work of partners,
and the project, more visible to researchers who work in similar disciplines
and research areas. Specifically, for AVENUE, publishing in open-access
journals is sought. Relevant dissemination activities target, organize and
manage publishing efforts (WP10).

**Data re-use** by external researchers and other stakeholder groups will be
feasible for selected datasets. The embargo period will be at least the
duration of the project, as partners would like to easily manage the data
whilst collection, analysis and reporting is ongoing. Sharing and-reuse will
be applied in the central database according to data depositor’s wishes and
suggestions.

##  Data ownership

Any data gathered during the lifetime of the project are the ownership of the
beneficiary or the beneficiaries (joint ownership) that produce them according
to **subsection 3, Art. 26 of the signed Grant Agreement (769033** ). The
beneficiaries have the intellectual property rights of the data they collect
and re-use of data is defined by the limitation they might set in how they
will make data available. This means partners decide if they make data open-
access (no additional restrictions on access to data or publications) or there
is an embargo period, whereby permission for accessing the data is given after
a certain period of time. As datasets have not been formed yet and services
are to be enhanced and connected to the AVENUE app centre, therefore this
information will be available in an updated version of this deliverable.

##  Measures for preventing malevolent/ criminal/terrorist abuse of research
findings

During the AVENUE project, responsibilities will be clearly assigned for the
overall management and control of research findings and the controlling of
access rights. The person who will be responsible on issues for data security
will directly inform to the quality board and the project coordinator. The
research findings will be protected from malevolent/criminal/terrorist abuse
by following strictly procedures, as they will be defined by the Ethical
Advisory Board.

#  FAIR Data

To further promote knowledge transfer and to contribute towards new research
content and results, AVENUE participates in the Open Research Data Pilot
(ORDP). However, any data that is identified and labelled as “restricted” or
under an “embargo” period will be excluded from the ORDP. To accommodate this,
the data that will be included in the ORDP should be handled according to the
FAIR principles, meaning that the data that will be generated during and after
the project will be made **findable** , **accessible** , **interoperable** and
**reusable** .

The FAIR principles are applied in AVENUE due to the fact that they serve as a
template for lifecycle data management and they ensure that the most critical
components are covered. Further to that, H2020 endorses the FAIR principles
and encourages their implementation amongst its projects regardless of
scientific and research disciplines.

To make data **findable** , including provisions for metadata the following
need to be taken into consideration:

  * The datasets will have very rich metadata to facilitate the findability. 

  

  * All the datasets will have a Digital Object Identifier provided by the AVENUE public repository. 

  

  * The reference used for the dataset will follow this format: AVENUE_WPX_AX.X_XX, including clear indication of the related WP, activity and version of the dataset. 

  

  * The standards for metadata will be defined in the “Standards and metadata” section of the dataset description table (see Table 3 for the current version of the template). To make data **accessible:**

  

  * Datasets openly available are marked as “Open” in the “Data Sharing” section of the dataset description table (see Table 3, Annex 2). 

  

  * The repository that each dataset is stored, including Open access datasets, are mentioned in the “Archiving and Preservation” section of the dataset description table (Table 3, Annex 2). The repository that will be used is still under consideration. 

  

  * “Data sharing” section of the dataset description table (Table 3, Annex 2) will also include information with respect to the methods or software used to access the data of each dataset. 

  

  * Data and their associated metadata will be deposed either in a public repository or in an institutional repository. 

  

  * “Data sharing” section of the dataset description table (Table 3, Annex 2) will outline the rules to access the data if restrictions exist. To make data **interoperable:**

  

  * Metadata vocabularies, standards and methodologies will depend on the repository to be hosted (incl. public, institutional, etc.) and will be provided in the “Standards and metadata” section of the dataset description table (Table 3, Annex 2). To make data **re-usable** (through clarifying licenses): 

  

  * All the data producers will license their data to allow the widest reuse possible. More details about license types and rules will be provided in the next version of the deliverable. 

  

  * “Data Sharing” section of the dataset description table (Table 3, Annex 2) is the field where the data sharing policy of each dataset is defined. By default, the data will be made available for reuse. 

  

  * The data producers will make their data available for third-parties within public repositories only for scientific publications validation purposes. 

  

#  AVENUE Ethical Policy

AVENUE project involves data collection from users in the context of
demonstration activities. All national legal and ethical requirements of the
Member States where the research is performed will be fulfilled. Any data
collection involving humans will be strictly held confidential at any time of
the research. This means in detail that:

  * all test participants will be informed and given the opportunity to provide their consent to any monitoring and data acquisition process; the subjects will be volunteers and all test volunteers will receive detailed oral information. 

  

  * no personal or sensitive data will be centrally stored. In addition, data will be scrambled where possible and abstracted in a way that will not affect the final project outcome. 

  

Furthermore, participants will receive in their own language:

  * a commonly understandable written description of the project and its goals;  the planned project progress and the related testing and evaluation procedures; 

  

  * advice on unrestricted disclaimer rights on their agreement. 

  

##  AVENUE Ethics Helpdesk

To properly address all ethics issues that have come up and/or will come up
during the project, an Ethics Helpdesk will be set up. The **Ethics Helpdesk**
will oversee the research in order to guarantee that no undue risk for the
user, neither technically nor related to the breach of privacy, is possible.
This allows the Consortium to implement the research project in full respect
of the legal and ethical national requirements and code of practice. Whenever
authorizations have to be obtained from national bodies, those authorizations
will be treated as documents relevant to the project. Copies of all relevant
authorizations will be submitted to the Commission prior to commencement of
the relevant part of the research project.

The procedures and the criteria that will be used to identify/recruit research
participants will be kept on file and submitted upon request. As far as the
informed consent procedures implemented are concerned, they will also be kept
on file and submitted upon request (see paragraph 5.4 below). All used
assessment tools and protocols within AVENUE demonstrators will be verified
beforehand by its Ethics helpdesk regarding their impact to business actors
and end users prior to their application at the sites. The helpdesk takes
responsibility for implementing and managing the ethical and legal issues of
all procedures in the project, ensuring that each of the partners provides the
necessary participation in AVENUE and its code of conduct towards the
participants. Each city will have its own Ethics Committee and one person will
be nominated per site as responsible for following the project’s
recommendations and the National and European legislations.

##  EU General Data Protection Regulation (GDPR) compliance

The EU General Data Protection Regulation (GDPR), entered into force on
24/05/2016 and its provisions will be applicable in all EU member states on
May 25th, 2018. The AVENUE project will be developed in full awareness of the
GDPR requirements.

According to the Information Commissioner’s Office (ICO), there are seven key
principles set by GDPR

[4]:

  * Lawfulness, fairness and transparency; 

  

  * Purpose limitation; 

  

  * Data minimisation; 

  

  * Accuracy; 

  

  * Storage limitation; 

  

  * Integrity and confidentiality (security);  Accountability. 

  

The above principles consist of the core of the methodology, according to
which all necessary steps are taken to become GDPR compliant. AVENUE, as a
European funded project with a Consortium of industry and research members,
needs to demonstrate compliance by maintain a record of all data processing
activities. The personal data that will be collected during the research
should be kept secure through appropriate technical and organisational
measures. The types of privacy data that GDPR protects are:

  * Basic identity information such as name, address and ID numbers; 

  

  * Web data such as location, IP address, cookie data and RFID tags; 

  

  * Health and genetic data; 

  

  * Biometric data; 

  

  * Racial or ethnic data;  Political opinions; 

  

  * Sexual orientation. 

  

The above are considered **personal data** .

According to the European Commission (EC) [5], when collecting participants’
data, people must be clearly informed about the following minimum:

  * What is project AVENUE; 

  

  * Who the Consortium consists of; 

  

  * Why the project will be using their data; 

  

  * The categories of the concerned; 

  

  * The legal justification for processing their data; 

  

  * How long will the data be stored for; 

  

  * Who else might have access to the data; 

  

  * Whether the data will be transferred outside the EU; 

  

  * Participants have a right to have a copy of the data, the right to file a complaint with the Data Protection Authority (DPA) and the right to withdraw their consent. 

  

For all the above, information will be provided in a written format, in a
transparent, concise, accessible and clear manner, free of charge.

##  GDPR roles

In order to face the data management challenges in an efficient manner, all
AVENUE partners have to respect the policies set out in this DMP. Within the
framework of GDPR, the roles that are identified for AVENUE are those of the:

  * Data Protection Officer (DPO), 

  

  * Data controller, 

  

  * Data processor and 

  

  * Data producer 

  

Each partner will allocate the persons responsible for each role. The role
allocation will be finalised in the next version of this deliverable, D1.5 due
for M48. Further to that, the Data controller and Data Processor will fill in
the GDPR Data Processing record template for the DPO to validate it. The Data
Controller’s record template and the Data Processor’s record template are
found in Annex 3.

##  Ethical and legal issues related to data sharing

AVENUE proposed solutions does not **expose** , **use** or **analyse**
personal sensitive data for any **purpose** . In this respect, no ethical
issues related to **personal sensitive data** are raised by the technologies
to be employed in large scale demonstrators foreseen in Switzerland, France,
Denmark and Luxembourg. However, AVENUE Consortium is fully aware of the
privacy-related implications of the proposed solutions and respects the
ethical rules and standards of H2020, and those reflected in the Charter of
Fundamental Rights of the European Union. Generally speaking, ethical, social
and data protection considerations are crucial and will be given all due
attention.

All relevant principles and the main procedures regarding privacy, data
protection, security, legal issues and ethical challenges are defined in the
Project’s Ethics Manual and will be updated in their upcoming versions.
Further to that, the general principles for handling knowledge and IPR within
AVENUE will be settled in a Consortium agreement (CA), signed by the AVENUE
Consortium at the project start. These principles are in line with H2020 IPR
recommendations.

The described procedures have been drafted and will be updated in consultation
with the project’s Ethics Management Panel (composed of one external member,
the Coordinator, the Technical & Innovation Manager and the Quality Manager)
that will act as supervisors of the ethical activities of the project and the
local ethics committees at each pilot site, in order to take into account both
European and national ethical and legal requirements.

##  Informed Consent

AVENUE scenarios will target participants with competence to understand the
informed consent information. Pilot sites, i.e., AVENUE partners participating
in the pilots, will receive only anonymised and coded or pseudonymised
information. Any recorded data will be available to pilot sites only in
anonymised format.

The consent procedures will be carefully determined and managed in WP11 and
used in WP7 that will manage the demonstration activities which will be
performed in the selected cities. The informed consent form, which each
participant will be asked to complete prior to their participation in the
pilots, aims at ensuring that the user accepts participation and is informed
about all relevant aspects of the research project; it will be collected in
written form after the users have been provided with clear and understandable
information about their role (including rights and duties), the objectives of
the research, the methodology used, the duration of the research, the
possibility to withdraw at any time, confidentiality and safety issues, risks
and benefits. The templates of the informed consent/assent forms and
information sheets will be included in the deliverables D2.10-D2.12. The basic
elements of the AVENUE informed consent include:

  1. The objectives of the study, its duration and procedure 

  

  2. The purpose of the pilots 

  

  3. Description of the type of information to be collected 

  

  4. Privacy and data protection procedures 

  

  5. Appointed data collectors and processors 

  

  6. Data ownership, storage location and storage duration 

  

  7. The possibility to decline the offer and to withdraw at any point of the process (and without consequences) 

  

  8. Contact person 

  

  

Further details on the informed consent can be found in the Description of
Action, Part B.

#  Conclusions

This deliverable provides an overview of the data that AVENUE project will
collect, manage, handle and produce along with related data processes and
requirements that need to be taken into consideration. The document outlines
an overview of the data types, sources, categories and collection methods and
describes the processes that will be followed within the core of the AVENUE
project regarding their processes.

The Data Management Plan is a living document and will be enriched along the
project’s lifetime as new information and decisions arise. The next version
will include all final decisions regarding data storage, data ownership, data
access, data sharing and repository issues.

To prepare for the next version that is due in Month 48 of the project, the
partner handling the data management plan will circulate the necessary
guidelines to the Consortium as the project progresses, so as to receive
updated, valid and precise information before finalising the next deliverable.