**EXECUTIVE SUMMARY**

This deliverable is the first version of U-TURN's Data Management Plan (DMP).
It includes the main elements foreseen in the European Guidelines for H2020
and the data management policy that will be used for all the datasets
generated by the project. U-TURN's DMP is driven by the project's pilots.
Specifically, this document describes the minimum datasets related to the
three U-TURN pilots: 1) Distribution of packaged goods from food manufacturers
to retail outlets located in urban areas (Greece), 2) Distribution of fresh
food from local producers in urban areas (Italy), 3) Food delivery from online
retailers to consumers in urban areas (UK). For each of these datasets, the
document presents a unified approach of the name and the description to be
used. Furthermore, the standards and metadata are presented as well as data
sharing options along with archiving and preservation details.  
  
<table>  
<tr>  
<th>

**1**

</th>  
<th>

**Introduction**

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

**1.1 Introduction**

The purpose of the Data Management Plan (DMP) is to provide a single point of
reference on the policy that governs the data received and managed by U-TURN
project as well as any data sources to be generated and made available to the
public. This document will evolve during the lifespan of the project. The
first version is delivered on M6 of the project, while it will be revised at
least by the mid-term and final review to be fine-tuned to the data generated.
Following the specified template (EU, 2015), the document analyses the
identifiers of the data and their description on how they are generated,
collected and reused. Also, a reference to relevant standards and the metadata
that will be created is provided. Archiving, preservation and data sharing
mechanisms are identified.

**1.2 Document Composition**

This document is comprised of the following chapters:

**Chapter 2** – Initial naming of the datasets

**Chapter 3** – Description of the minimum datasets to be collected for each
pilot

**Chapter 4** – Standards and metadata

**Chapter 5** – Data sharing mechanisms to be followed by internal and
external entities  **Chapter 6** – Archiving and preservation of the data  
  
<table>  
<tr>  
<th>

**2**

</th>  
<th>

**Data set reference and name**

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

U-TURN is driven by three different pilots, i.e., 1) Distribution of packaged
goods from food manufacturers to retail outlets located in urban areas
(Greece), 2) Distribution of fresh food from local producers in urban areas
(Italy), 3) Food delivery from online retailers to consumers in urban areas
(UK). The teams working under these pilots have already initiated a series of
interviews with several industry partners to identify the minimum set of data
that is useful for enabling the simulation mechanism, the matching algorithm
and the economic assessment of the project. After this set of data is agreed,
the industry partners and possible end users of the platform will provide
their historical data to the project pilots.

The data sets required by each pilot differ to each other, since the pilots
cover alternative urban freight distribution channels. However, similar naming
methodology will be followed. The partners will receive one or more files
(excel or csv) containing industrial data. The name of the file should follow
a specific structure, such as: TG_DS_PL_CM_FT_ND_D

TG: Target Group, the target group for which the data are contained in the
document (food producers, retailers etc.)

DS: DataSet, the set of data that is included for this target group
(transport, delivery, vehicle). It can also take the value “ALL” if the file
contains all the sets of data

PL: PiLot, the name of the pilot (GR, IT, UK)

CM: CoMpany, the name of the company from which we have taken the data

FT: FormaT, the format of the file of the data

ND: The name of the original document

D: The date of receiving the document or the date of creating this document

The folders used may follow similar structure: PL_CM_FT_DT_DT

PL: PiLot, the name of the pilot (GR, IT, UK)

CM: CoMpany, the name of the company from which we have taken the data

FT: FormaT, the format of the file of the data

DT: The name of the original document  D: The date of receiving the document  
  
<table>  
<tr>  
<th>

**3**

</th>  
<th>

**Dataset Description**

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

All three pilots have already reviewed a number of end users in their specific
areas. The target groups identified include: Pilot 1:

super markets  3PL companies  suppliers

Pilot 2:

food producers/farmers

local markets, retailers, consumers, consumer aggregations  transport and
logistics operators

Pilot 3:

retailers offering home deliveries of groceries

The specific target group is reflected also on the name of the file that
contains the data set.

For each of these target groups, several parameters have been identified by
each pilot. The data to be received by external sources will fill in these
parameters. The pilots have identified some identical parameters, however some
differ. For pilot 1 and Pilot 2 the three basic parameters are:

Transport: Data concerning the transportation of the goods

Delivery: Data concerning the delivery points

Vehicle: Data concerning the vehicles making the transportation

These parameters of course include several variables. An example is presented
below:

**Table 1 Variables for the three parameters of the datasets**  
  
<table>  
<tr>  
<th>

Parameter

</th>  
<th>

Type

</th>  
<th>

</th>  
<th>

Mandatory

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

TRANSPORTS

</td>  
<td>

</td>  
<td>

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

Transport ID: The ID of the specific transportation, as it exists in the
system

</td>  
<td>

String

</td>  
<td>

YES

</td>  
<td>

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

Date of transport: The date that the transportation was held (DDMMYY)

</td>  
<td>

Date

</td>  
<td>

YES

</td>  
<td>

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

Transport start point: The Postal Code of the transportation start point
(Postal Code of the 3PL’s warehouse, etc.)

</td>  
<td>

String

</td>  
<td>

YES

</td>  
<td>

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

Vehicle Code: Vehicle’s ID (e.g. license plate)

</td>  
<td>

String

</td>  
<td>

YES

</td>  
<td>

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

Distance travelled (in km): The distance from the

</td>  
<td>

Numeric

</td>  
<td>

YES

</td>  
<td>

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

start point to the last point of delivery (no return data computed)

</td>  
<td>

</td>  
<td>

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

DELIVERIES

</td>  
<td>

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

Transport ID: The ID of the specific transportation, as it exists in the
system

</td>  
<td>

String

</td>  
<td>

YES

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

Delivery point: The Postal Code of the delivery points (if more than one
delivery points exist, they are depicted as distinct records)

</td>  
<td>

Numeric

</td>  
<td>

YES

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

Carried load per delivery point (in Kg): carried load from the start point to
the specific delivery point

</td>  
<td>

Numeric

</td>  
<td>

NO

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

Carried load per delivery point (as volume): carried load from start point to
the specific delivery point in cubic meters (m3)

</td>  
<td>

Numeric

</td>  
<td>

NO

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

Carried load per delivery point (in pallets): carried load from start point to
specific delivery point in pallets

Load type: e.g. dry, refrigerate, etc.

</td>  
<td>

Numeric

</td>  
<td>

YES

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

VEHICLES

</td>  
<td>

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

Vehicle ID: e.g. License plate

</td>  
<td>

String

</td>  
<td>

YES

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

Vehicle type: Owned or Public Deliveries

</td>  
<td>

String

</td>  
<td>

YES

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

Vehicle Engine Technology: e.g. Euro IV, Euro V

</td>  
<td>

String

</td>  
<td>

YES

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

Fuel type: e.g. diesel, bio-fuel etc.

</td>  
<td>

String

</td>  
<td>

YES

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

Vehicle gross weight: Maximum vehicle weight

(loaded) in kg

</td>  
<td>

Numeric

</td>  
<td>

NO

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

Vehicle payload: maximum load a vehicle can transfer (in kg)

</td>  
<td>

Numeric

</td>  
<td>

NO

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

Vehicles capacity in pallets

</td>  
<td>

Numeric

</td>  
<td>

YES

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

Pilot 3 has also identified “Deliveries” as the basic parameter and several
variables.

**Table 2 Variables for the parameter "Deliveries" for Pilot 3**  
  
<table>  
<tr>  
<th>

Parameter

</th>  
<th>

Type

</th>  
<th>

</th>  
<th>

Mandatory

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

**DELIVERIES**

</td>  
<td>

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

Delivery point: The Postal Code of the delivery points (if more than one
delivery points exist, they are depicted as distinct records)

</td>  
<td>

String

</td>  
<td>

YES

</td>  
<td>

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

Spoke (which DC / warehouse is responsible for the delivery)

</td>  
<td>

String

</td>  
<td>

NO

</td>  
<td>

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

Order index; i.e. the number of orders within a postcode relative to the
average

</td>  
<td>

Numeric

</td>  
<td>

YES

</td>  
<td>

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

Number of Orders

</td>  
<td>

Numeric

</td>  
<td>

YES

</td>  
<td>

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

Average items

</td>  
<td>

Numeric

</td>  
<td>

NO

</td>  
<td>

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

Carried load per delivery point (in Kg): carried load

</td>  
<td>

Numeric

</td>  
<td>

NO

</td>  
<td>

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

from the start point to the specific delivery point

</td>  
<td>

</td>  
<td>

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

Carried load per delivery point (as volume): carried load from start point to
the specific delivery point in cubic meters (m3)

</td>  
<td>

Numeric

</td>  
<td>

NO

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

Allocation of time windows of deliveries (day and hour)

</td>  
<td>

String

</td>  
<td>

NO

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

Allocation of order’s time (day and hour)

</td>  
<td>

String

</td>  
<td>

NO

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

An example of the excel files already retrieved from the industry partners of
Greece (Pilot 1) are depicted below for each of the parameters mentioned
above.

**Figure 1 Transport Dataset Example Pilot 1**
  
<table>  
<tr>  
<th>

**Postcode**

</th>  
<th>

**Spoke**

</th>  
<th>

**Order index**

</th>  
<th>

**Orders**

</th>  
<th>

**Average items**

</th>  
<th>

**Average order volume (cubic cm)**

</th>  
<th>

**Average order weight (kg)**

</th>  
<th>

**Total items**

</th>  
<th>

**Total volume (cubic cm)**

</th>  
<th>

**Total weight**

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

**CK784GY**

</td>  
<td>

**??????**

</td>  
<td>

0.3

</td>  
<td>

2.9

</td>  
<td>

53

</td>  
<td>

80,855

</td>  
<td>

35

</td>  
<td>

154

</td>  
<td>

235,553

</td>  
<td>

101

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

**4**

</th>  
<th>

**Standards and Metadata**

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

U-TURN project is related to different pillars, i.e., transportation,
logistics, environment. Several standards exist, addressing interoperability,
adaptability and dynamicity issues of data on each of these specific fields.
This section presents the standards (BSI), (GS1), that will be taken into
account in order for the project to produce aligned data structures and data
exchange services.

**4.1 CEN 16258:2012**

This European Standard establishes a common methodology for the calculation
and declaration of energy consumption and greenhouse gas (GHG) emissions
related to any transport service (of freight, passengers or both). It
specifies general principles, definitions, system boundaries, calculation
methods, apportionment rules (allocation) and data recommendations, with the
objective to promote standardised, accurate, credible and verifiable
declarations, regarding energy consumption and GHG emissions related to any
transport service quantified.

**4.2 ISO 39001:2012**

ISO 39001:2012 specifies requirements for a road traffic safety (RTS)
management system to enable an organization that interacts with the road
traffic system to reduce death and serious injuries related to road traffic
crashes which it can influence. The requirements set by ISO 39001:2012 include
development and implementation of an appropriate RTS policy, development of
RTS objectives and action plans, which take into account legal and other
requirements to which the organization subscribes, and information about
elements and criteria related to RTS that the organization identifies as those
which it can control and those which it can influence.

**4.3 ISO 14001:2015**

ISO 14001:2015 specifies the requirements for an environmental management
system that an organization can use to enhance its environmental performance.
ISO 14001:2015 is intended for use by an organization seeking to manage its
environmental responsibilities in a systematic manner that contributes to the
environmental pillar of sustainability.

**4.4 ISO 9001:2015**

ISO 9001:2015 is the revised edition of ISO 9001:2008 which specifies
requirements for a quality management system when an organization needs to
demonstrate its ability to consistently provide products and services that
meet customer and applicable statutory and regulatory requirements, and aims
to enhance customer satisfaction through the effective application of the
system, including processes for improvement of the system and the assurance of
conformity to customer and applicable statutory and regulatory requirements.

**4.5 ISO 22000:2005**

ISO 22000:2005 specifies requirements for a food safety management system
where an organization in the food chain needs to demonstrate its ability to
control food safety hazards in order to ensure that food is safe at the time
of human consumption. It is applicable to all organizations, regardless of
size, which are involved in any aspect of the food chain and want to implement
systems that consistently provide safe products. The means of meeting any
requirements of ISO 22000:2005 can be accomplished through the use of internal
and/or external resources.

**4.6 BS OHSAS 18001**

BS OHSAS 18001 is a truly international standard which sets out the
requirements for occupational health and safety management good practice for
any size of organization. It provides guidance to help companies design their
own health and safety framework – allowing them to bring all relevant controls
and processes into one management system. This system is proven to enable the
business to be pro-active rather then reactive, therefore more effectively
protecting the health and welfare of the workforce on an on-going basis.

Each file associated with data will be accompanied with unique specified
metadata in order to allow their ease of access and re-usability. Below, the
form to be followed is presented.  
  
<table>  
<tr>  
<th>

**Title**

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

Document version

</td>  
<td>

(The version of this document)

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

Description

</td>  
<td>

(A description of the data included in the document)

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

Date

</td>  
<td>

(The date of the creation of the document)

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

Keywords

</td>  
<td>

(Some keywords describing the content)

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

Subject

</td>  
<td>

(Small description of the data source)

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

**Creator (Name of the creator of the data source – In case of anonymous data
this can be empty)**

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

Sector of the provider

</td>  
<td>

(Information on the sector that this provider belongs to)

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

Permissions

</td>  
<td>

(The permission of this document are mandatory to be mentioned here)

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

**Name of the Partner (The name of the partner that collected the data and is
responsible for)**

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

Responsible person

</td>  
<td>

(The name of the person within the partner, who is responsible for the data)

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

Pilot

</td>  
<td>

(For which pilot the data will be used)

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

Scenario of data usage

</td>  
<td>

(How the data are going to be used in this scenario)

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

**Description of the Data Source**

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

File format

</td>  
<td>

(The format of the data source provided)

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

File name/path

</td>  
<td>

(The name of the file)

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

Storage Location

</td>  
<td>

(In case a URI/URL exists for the data provider)

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

Data type

</td>  
<td>

(Data type and extension of the file; e.g. Excel Sheet, .xlsx; Standard if
possible)

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

Standard

</td>  
<td>

(Data Standard, if existent. e.g. DATEX II, NaPTAN, etc.)

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

Data Size

</td>  
<td>

(Total data size, if possible)

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

Time References of Data

</td>  
<td>

Start Date

</td>  
<td>

End Date

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

Availability

</td>  
<td>

Start Date

</td>  
<td>

End Date

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

Data collection frequency

</td>  
<td>

(The time frequency in which the data is collected; e.g. Hourly, every five
minutes, on demand, etc.)

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

Data quality

</td>  
<td>

(The quality of the data; is it complete, does it have the right collection
frequency, is it available, etc.)

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

**Raw data sample**

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

(Textual copy of a data sample)

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

**Number of Parameters included:**

</td>  
<td>

</td>  
<td>

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

**Parameter #1:**

</td>  
<td>

</td>  
<td>

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

**Variables**

</td>  
<td>

**(Name)**

</td>  
<td>

**(Type)**

</td>  
<td>

**(Mandatory)**

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

</td>  
<td>

**…**

</td>  
<td>

**…**

</td>  
<td>

**…**

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

**Parameter #2:**

</td>  
<td>

</td>  
<td>

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

**Variables**

</td>  
<td>

**(Name)**

</td>  
<td>

**(Type)**

</td>  
<td>

**(Mandatory)**

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

</td>  
<td>

**…**

</td>  
<td>

**…**

</td>  
<td>

**…**

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

**5**

</th>  
<th>

**Data Access and Sharing**

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

Data Access and Sharing Plan, include several aspects that have to be
identified (DCC), (University). In line with the Consortium Agreement, access
to the data resulted from the project will be available for educational,
research and non-profit purposes. Also, according to the exploitation and
dissemination plan of the project the outcomes will be accessible to the
public. These plans may include publication of the results in waves during the
project or at the end of it. In more details, these issues regarding the data
access and sharing plan are presented below.

**5.1 Timeliness of Data Sharing**

The data sharing should occur in a timely fashion. This means that the data
resulted from the research conducted in the project should become available
close to the project results themselves. Furthermore, it is reasonable to
expect that the data would be released in waves as they become available or
main findings from waves of the data are published.

**5.2 IPRs and Privacy Issues**

Data access and sharing activities will be rigorously implemented in
compliance with the privacy and data collection rules and regulations, as they
are applied nationally and in the EU, as well as with the H2020 rules. Raw
data collected through the interviews from external to the consortium sources
may be available to the whole consortium or specific partners upon
authorization of the owners. This kind of data will not be available to the
public. Concerning the results of the project, these will become publicly
available based on the IPRs as described in the Consortium Agreement.

**5.3 Methods for Data Sharing**

Raw data or resulted data that are governed by any IPRs or confidentiality
issues will be added to a data enclave. Data enclaves are considered
controlled, secure environments for datasets that cannot be distributed to the
general public either due to participant confidentiality concerns or third-
party licensing or use agreements that prohibit redistribution.

An additional raw-data collection issue is the provision of data required
during the pilots of the project, such as basic data required for a use-case.
This kind of data will be inserted to the U-TURN platform either manually by
the user, or in batches using the defined system interfaces. Either way, the
confidentiality and integrity of these data will be guaranteed by the security
encryption scheme that will be defined in the respective deliverable regarding
the non-functional requirements of the platform.

On the other hand, data that are eligible for public distribution may be
disseminated through:

Scientific papers

Lectureships in case of Universities

Interest groups created by the partners of the project

Dissemination though the dissemination and exploitation channels of the
project to attract more interested parties

Appropriate repositories will be used for storing the results of the project
and providing access to the scientific community, such as OpenAIRE.  
  
<table>  
<tr>  
<th>

**6**

</th>  
<th>

**Archiving and Preservation**

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

**6.1 Short term**

We recognise 2 cases where raw, generated or meta-data should be preserved and
archived. The first case refers to the requirements analysis phase, where raw
data are collected from industrial partners in a predefined file format (excel
or csv), with predefined fields. These data will provide to the system
designers a clear view on data availability and requirements, shedding light
on particular details of the industrial domain and users requirements. After
this phase is complete, such raw-data will be archived in their initial format
and stored on INTRASOFT's infrastructure online and offline. Access to these
datasets will be given only after request and during the design phases of the
project to the responsible person.

The second case refers to raw-data, meta-data, or data generated by the system
during the pilots of the project. All these kinds of data will be preserved to
a database (DB), the schema of which will be defined after the requirements
analysis phase and provided in the final version of this document. Back-ups of
the DB will be performed on a monthly-basis. Both, the DB server and the back-
ups will be stored on INTRASOFT's infrastructure online and offline.

The entire storage data set will be archived until the end of the project at
least. A full schema of the database will be provided. The files containing
the datasets will be versioned over time. Also the datasets will be
automatically backed up on a nightly and monthly basis. The backups will be
stored on INTRASOFT’s infrastructure online and offline.

**6.2 Long term**

The consortium partners will further examine platform solutions (e.g.
_https://joinup.ec.europa.eu/_ and  _http://ckan.org/_ )  that will allow the
sustainable archiving of all the U-TURN datasets after the life span of the
project.  
  
<table>  
<tr>  
<th>

**7**

</th>  
<th>

**Conclusions**

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

This deliverable presents the Data Management Plan of U-TURN project, which
will be used as guidance for the data that will be collected for the project’s
purposes, for the data that will be generated as well as for the metadata that
will accompany them. Specifically, it provides a way of describing the data to
follow for the whole consortium as well as guaranteeing consistency towards
any external users. It also analyses a preliminary framework of data sharing,
accessing and preserving.

Of course, this version of the deliverable is only an initial one. It will be
evolved during the lifespan of the project and thus it will be treated as a
living document. The first version is delivered on M6 of the project, while it
will be revised at least by the mid-term and final review to be fine-tuned to
the data generated.