#  Executive Summary

In Horizon 2020 a limited pilot action on open access to research data has
been implemented. Participating projects have been required to develop a Data
Management Plan (DMP).

This deliverable provides the third version of the Data Management Plan
elaborated by the AUTOPILOT project. The purpose of this document is to
provide an overview of the main elements of the data management policy. It
outlines how research data was handled during the AUTOPILOT project and
describes what data was collected, processed or generated and following what
methodology and standards, whether and how this data was shared and/or made
open, and how was be curated and preserved. Besides, data types list, metadata
and global data collection processes are also defined in this document.

The AUTOPILOT Data Management Plan refers to the latest EC DMP guidelines  1
. This version has explicit recommendations for full life cycle management
through the implementation of the FAIR principles, which state that the data
produced shall be Findable, Accessible, Interoperable and Reusable (FAIR).

The document first provide a kind of ontology for the data used during the
AUTOPILOT projects, generated by a diversity of data sources, like vehicles,
on board and road side sensors. The report presents the hierarchical IoT
architecture, the different data set categories and the metadata, which are
important to interpret the data content in the IoT platforms.

The report includes a detailed presentation of the methodology for the
AUTOPILOT data management, taking into account the decision of the AUTOPILOT
consortium to apply for the ORDP.

The report provides the description of the data sets structures, relating to
the different categories of IoT devices and other data sources like vehicles,
but also the specific types and data set used at the different pilot sites,
according to the use cases deployed and assessed locally.

#  Introduction

##  Objectives of the project

Automated driving is expected to increase safety, to provide more comfort and
to create many new business opportunities for mobility services. The Internet
of Things (IoT) is about enabling connections between objects or "things"; it
is about connecting anything, anytime, anyplace, using any service over any
network.

**AUTO** mated Driving **P** rogressed by **I** nternet **O** f **T** hings”
(AUTOPILOT) project will especially focus on utilizing the IoT potential for
automated driving.

The overall objective of AUTOPILOT is to bring together relevant knowledge and
technology from the automotive and the IoT value chains in order to develop
IoT-architectures and platforms which will bring Automated Driving towards a
new dimension. This is realized through the following main objectives:

  * Use, adapt and innovate current and advanced technologies to define and implement an IoT approach for autonomous and connected vehicles 

  

  * Deploy, test and demonstrate IoT based automated driving use cases at several permanent pilot sites, in real traffic situations with: Urban driving, Highway pilot, Automated Valet Parking, Platooning and Real-time car sharing. 

  

  * Create and deploy new business products and services for fully automated driving vehicles, used at the pilot sites: by combining stakeholders’ skills and solutions, from the supply and demand side 

  

  * Evaluate with the involvement of users, public services and business players at the pilot sites : 

    * The suitability of the AUTOPILOT business products and services as well as the ability to create new business opportunities 

  

    * The user acceptance related to using the Internet of Things for highly or fully automated driving 

  

    * The impact on the citizens’ quality of life 

  

  

  * Contribute actively to standardization activities as well as to consensus building in the areas of Internet of Things and communication technologies 

  

Automated vehicles largely rely on on-board sensors (LiDAR, radar, cameras,
etc.) to detect the environment and make reliable decisions. However, the
possibility of interconnecting surrounding sensors (cameras, traffic light
radars, road sensors, etc.) exchanging reliably redundant data may lead to new
ways to design automated vehicle systems potentially reducing cost and adding
detection robustness.

Indeed, many types of connected objects may act as an additional source of
data, which will very likely contribute to improve the efficiency of the
automated driving functions, enable new automated driving scenarios as well as
increase the automated driving function safety while providing driving data
redundancy and reducing implementation costs. These benefits will enable
pushing the SAE level of driving automation to the full automation, keeping
the driver out of the loop. Furthermore, by making autonomous cars a full
entity in the IoT, the AUTOPILOT project enables developers to create IoT/AD
services as easy as accessing any entity in the IoT.

**Figure 1 – The AUTOPILOT overall concept**

The Figure above depicts the AUTOPILOT overall concept including the different
ingredients to apply IoT to autonomous driving:

  * The overall IoT platforms and architecture, allowing the use of the IoT capabilities for autonomous driving. 

  

  * The Vehicle IoT integration and platform to make the vehicle an IoT device, using and contributing to the IoT. 

  

  * The Automated Driving relevant sources of information (pedestrians, traffic lights …) becoming IoT devices and extending the IoT eco-systems to allow enhanced perception of the driving environment on the vehicle. 

  

  * The communication network using appropriate and advanced connectivity technology for the vehicle as well as for the other IoT devices. 

  

##  Purpose of the document

This deliverable presents the third version of the data management plan
elaborated for the AUTOPILOT project. The purpose of this document is to
provide an overview of the data set types present in the project and to define
the main data management policy adopted by the Consortium.

The data management plan defines how data in general and research data in
particular are handled during the research project.

It describes what data is collected, processed or generated by the IOT devices
and by all the IoT ecosystem, what methodologies and standards shall be
followed during the collection process, whether and how this data is shared
and/or made open not only for the evaluation needs but also to comply with the
ORDP requirements  2  , and how it shall be curated and preserved. Besides,
the Data management plan identifies the four (4) key processes requirements
that define the data collection process and provides first recommendations to
be applied.

The document is structured as the following. **The Chapter 2** outlines a data
overview in the AUTOPILOT project. It details AUTOPILOT data categories, data
types and metadata, then the data collection processes to be followed and
finally the test data flow and test data architecture environment.

**The Chapter 3** gives a global vision of the test data management
methodology developed in the WP3 across pilot sites.

**The Chapter 4** gives insights about the Open Research Data Pilot under
H2020 guidelines. **The Chapter 5** provides detailed description of the
datasets used in AUTOPILOT project with focus on used methodologies, standard
and data sharing policies.

**The Chapter 6** gives insights about the FAIR Data Management principle
under H2020 guidelines and how AUTOPILOT started actions in order to be FAIR
compliant.

Finally, the remaining chapters outline the necessary roles, responsibilities
and ethical issues

##  Intended audience

The AUTOPILOT project addresses highly innovative concepts. As such, foreseen
intended audience of the project is the scientific community interested in the
IOT and/or automotive technologies. In addition, due to the strong expected
impact of the project on their respective domains, the other expected audience
consists in automotive industrial communities, telecom operator and
standardization organizations.

#  Data in AUTOPILOT: an overview

The aim of this chapter is:

  * To provide a first categorization of the data. 

  

  * To identify a list of the data types that is generated. 

  

  * To provide a list of metadata that is used to describe generated data and enable data reuse. 

  

  * To provide recommendations on data collection and sharing processes during the project and beyond. 

  

##  The AUTOPILOT hierarchical IoT architecture

The AUTOPILOT project will collect a large amount of raw data to measure the
benefit of IoT for automated driving with multiple automated driving use cases
and services, at different pilot locations.

Data from vehicles and sensors is collected and managed through a hierarchy of
IoT platforms as illustrated in Figure 2

The figure above shows a federated architecture with the following four
layers:

  * **In-vehicle IoT Platforms:** Here is everything that is mounted inside the vehicle, i.e., components responsible for AD, positioning, navigation, real time sensor data analysis, and communication with the outside world. All mission critical autonomous driving functions should typically reside in this layer. 

  

  * **Road-Side IoT Platforms:** Road-side and infrastructure devices, such as cameras, traffic light sensors, etc., are integrated and managed as part of road-side IoT PFs covering different road segments and using local low latency communication networks and protocols as required by the devices and their usage. 

  

  * **Pilot Site IoT Platforms:** This layer constitutes the first integration level. It is responsible for collecting, processing and managing data at the pilot sites level. 

  

  * **Central IoT Platform:** This is a Cloud-based top layer that integrates and aggregates data from the various pilot sites as well as external services (weather, transport, etc.). This is where the common AD services such as car sharing, platooning, etc., will reside. Data, at this level, are standardized using common formats, structures and semantics. The central IoT platform is hosted on IBM infrastructure. 

  

The data analysis is performed according to Field Operational Test studies
(FOT  3  ) and using FESTA  4  methodology. The FESTA project funded by the
European Commission developed a handbook on FOT methodology which gives
general guidance on organizational issues, methodology and procedures, data
acquisition and storage, and evaluation.

From raw data a large amount of derived data is produced to address multiple
research needs. Derived data will follow a set of transformations: cleaning,
verification, conversion, aggregation, summarization or reduction.

In any case, data must be well documented and referenced using rich metadata
in order to facilitate and foster sharing, to enable validity assessments and
to enable its usage in an efficient way.

Thus, each data must be described using additional information called
metadata. The latter must provide information about the data source, the data
transformations and the conditions in which the data has been produced. More
details about the metadata in AUTOPILOT are described in section 2.2.

##  Data sets categories

The AUTOPILOT project will produce different categories of data sets.

  * **Context data** : data that describe the context of an experiment (e.g. Metadata) 

  

  * **Acquired and derived data** : data that contain all the collected information from measurements and sensors related to an experiment. 

  

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

  

###  Context data

Context data is any information that helps to explain observation during a
study. Context data can be collected, generated or retrieved from existing
data. For example, it contains information such as vehicle, road or drivers
characteristics.

###  Acquired and derived data

Acquired data is all data collected to be analysed during the course of the
study. Derived data is created by different types of transformations including
data fusion, filtering, classification, and reduction. Derived data are easy
to use and they contain derived measures and performance indicators referring
to a time period when specific conditions are met. This category includes
measures from sensors coming from vehicles or IOT and subjective data
collected from either the users or the environment.

The following list outlines the data types and sources that is collected:  
  
<table>  
<tr>  
<th>

**In-vehicle measures** are the collected data from vehicles, either using
their original in-car sensors or sensors added for AUTOPILOT purposes. These
measures can be divided into different types:

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

</td>  
<td>

**Vehicle dynamics** are measurements that describe the mobility of the
vehicle. Measurements can be for example longitudinal speed, longitudinal and
lateral acceleration, yaw rate, and slip angle.

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

</td>  
<td>

**Driver actions** define the driver actions on the vehicle commands that can
be measured; for instance, steering wheel angle, pedal activation or HMI
button press variables, face monitoring indicators characterizing the state of
the driver, either physical or emotional.

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

</td>  
<td>

**In-vehicle systems state** can be accessed by connecting to the embedded
controllers. It includes continuous measures like engine RPM or categorical
values like ADAS and active safety systems activation.

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

</td>  
<td>

**Environment detection** is the environment data that can be obtained by
advanced sensors like RADARs, LIDARs, cameras and computer vision, or more
simple optical sensors. For instance, luminosity or presence of rain, but also
characteristics and dynamics of the infrastructure (lane width, road
curvature) and surrounding objects (type, relative distances and speeds) can
be measured from within a vehicle.

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

</td>  
<td>

**Vehicle positioning** the geographical location of a vehicle is determined
with satellite navigation systems (e.g. GPS) and the aforementioned advanced
sensors.

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

</td>  
<td>

**Media** mostly consist of video. The data consist of media data but also
index files used to synchronize the other data categories. They are also often
collected from the road side.

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

**Continuous subjective measures** Complimentary to sensors and
instrumentation, some continuous measures can also be built in a more
subjective way, by analysts or annotators, notably using video data.

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

**Road-side measures** are the vehicle’s counting speed measurement and
positioning, using radar, rangefinders, inductive loops or pressure hose. In
ITS systems, it may also contain more complex information remotely transferred
from vehicles to road-side units.

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

**Experimental conditions** are the external factors which may have an impact
on participants’ behaviour. They may be directly collected during the
experiment, or integrated from external sources. Typical examples are traffic
density and weather conditions.

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

**IOT data** are the external sources of data that is collected/shared through
IOT services:

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

</td>  
<td>

**Users Data** can be generated by smartphones or wearables. The users can be
the pedestrians or the car drivers. These data helps the user experience for
the usage of services by vehicle or infrastructure. The privacy aspects are
well explained in chapter 4\.

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

</td>  
<td>

**Infrastructure Data** are all the data giving additional information about
the environment. Typical examples are the traffic status, road-works,
accidents and road conditions. They can also be directly collected from Road-
side cameras or traffic light control units and then transferred to IOT
Platforms. For instance, the infrastructure data can transfer hazard warnings
or expected occupancy of busses on bus lanes to vehicles using communication
networks.

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

</td>  
<td>

**In-Vehicle data** defines the connected devices or sensors in vehicles.
Typical examples are navigation status, time distance computations, real-time
pickup / drop-off information for customers, and events detected by car to be
communicated to other vehicles or GPS data to be transferred to maps.

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

**Surveys data** are data resulting from the answers of surveys and
questionnaires for user acceptance evaluation

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

###  Aggregated data

Aggregated data is generally created in order to answer the initial research
question. They are supposed to be verified and cleaned, thus facilitating
their usage for analysis purposes.

Aggregated data contains a specific part of the acquired or derived data (e.g.
the average speed during a trip or the number of passes through a specific
intersection). Its smaller size allows a simple storage in e.g. database
tables and an easy usage suitable for data analysis. To obtain aggregated
data, several data reduction processes are performed. The reduction process
summarizes the most important aspects in the data into a list of relevant
parameters or events, through one or all of the following processes:
validation, curation, conversion, annotation.

Besides helping in answering new research questions, aggregated data may be
re-used with different statistical algorithms without the need to use raw
data. For AUTOPILOT, aggregated data will represent the most important data
types that is shared by the project as described in section 4 Participation in
the open research data pilot. It does not allow potentially problematic re-
uses because it does not contain instantaneous values that would highlight
illegal behaviour of a vehicle, a driver or another subsystem.

##  Metadata

###  General principles

This section reviews the relevant metadata standards developed or used in the
previous and ongoing field operational tests (FOT) and naturalistic driving
studies (NDS) as a basis for the development of the metadata specifications of
the pilot data. Such standards will help the analysis and re-use of the
collected data within the AUTOPILOT project and beyond.

The text in this section is derived from the work done in the FOT-Net Data
project  4  for sharing data from field operational tests. The results of this
work are described in the Data Sharing Framework  6  . The CARTRE project  7
is currently updating this document to specifically addressing road automation
pilots and FOTs.

As described in the previous sections, the pilots will generate and collect a
large amount of raw and processed data from continuous data-logging, event-
based data collection, and surveys. The collected data is analysed and used
for various purposes in the project including the impact assessment carried
out by partners who are not involved in the pilots. This is a typical issue
encountered in many FOT/NDS projects in which the data analyst (or re-user)
needs to know how the raw data was collected and processed in order to perform
data analysis, modelling and interpretation. Therefore, good metadata is
vital.

The Data Sharing Framework defines metadata as ‘ **any information that is
necessary in order to use or properly interpret data** ’. The aim of this
section is to address these issues and to provide methods to efficiently
describe a dataset and its associated metadata. It results in suggestions for
good practices in documenting a data collection and datasets in a structured
way. Following the definition of metadata by the data sharing framework, we
divide the AUTOPILOT’s Metadata into four different categories as follows.

  * **AUTOPILOT pilot design and execution** documentation, which corresponds to a high level description of a data collection: its initial objectives and how they were met, description of the test site, etc. 

  

  * **Descriptive** metadata, which describes precisely each component of the dataset, including information about its origin and quality. 

  

  * **Structural** metadata, which describes how the data is being organized. 

  

  * **Administrative** metadata, which sets the conditions for how the data can be accessed and how this is being implemented. 

  

Field Operational Tests (FOTs) have been carried out worldwide and adopted
different metadata formats to manage the collected data. One of good examples
is the ITS Public Data Hub hosted by the US Department of Transport  5  .
There are over 100 data sets created using ITS technologies. The data sets
contain various types of information, such as highway detector data, travel
times, traffic signal timing data, incident data, weather data, and connected
vehicle data, many of them will also be collected in the AUTOPILOT data. The
ITS Public Data Hub uses ASTM 2468-05 standard format for metadata to support
archived data management systems. This standard would be a good start point to
design metadata formats for various types of operational data collected by the
IoT devices and connected vehicles in AUTOPILOT.

In a broader context of metadata standardisation, there are a large number of
metadata standards available which address the needs of particular user
communities. The Digital Curation Centre (DCC) provides a comprehensive list
of metadata standards  9  for various disciplines such as general research
data, physical science as well as social science & humanities. It also lists
software tools that have been developed to capture or store metadata
conforming to a specific standard.

###  IOT metadata

The metadata describing IoT data are specified in the context of OneM2M
standard  10  . In such context “Data” signifies digital representations of
anything. In practice, that digital representation is associated to a
“container” resource having specific attributes. Those attributes are both
metadata describing the digital object itself, and the values of the variables
of that object, which are called “content”.

Every time an IoT device publishes new data on the OneM2M platform a new
“content instance” is generated, representing the actual status of that
device. All the “content instances” are stored in the internal database with a
unique resource ID.

The IOT metadata are describing the structure of the information, according to
the OneM2M standard. The IoT metadata are described in the Table 1below.

####  Table 1 – OneM2M Metadata for IoT data  6  
  
<table>  
<tr>  
<th>

**Metadata Element**

</th>  
<th>

**Extended name**

</th>  
<th>

**Description**

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

pi

</td>  
<td>

parentID

</td>  
<td>

ResourceID of the parent of this resource.

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

ty

</td>  
<td>

resourceType

</td>  
<td>

Resource Type attribute identifies the type of the resource as specified in
clause. For E.g. “4 (contentInstance)”.

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

ct

</td>  
<td>

creationTime

</td>  
<td>

Time/date of creation of the resource.

This attribute is mandatory for all resources and the value is assigned by the
system at the time when the resource is locally created. Such an attribute
cannot be changed.

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

ri

</td>  
<td>

resourceID

</td>  
<td>

This attribute is an identifier for the resource that is used for 'non-
hierarchical addressing method', i.e. this attribute contains the
'Unstructured-CSErelative-Resource-ID' format of a resource ID as defined in
table 7.2-1 of [5].

This attribute is provided by the Hosting CSE when it accepts a resource
creation procedure. The Hosting CSE assign a resourceID which is unique in
that CSE.

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

rn

</td>  
<td>

resourceName

</td>  
<td>

This attribute is the name for the resource that is used for 'hierarchical
addressing method' to represent the parent-child relationships of resources.
See clause 7.2 in [5] for more details.

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

lt

</td>  
<td>

lastModifiedTime

</td>  
<td>

Last modification time/date of the resource. The lastModifiedTime value is
updated when the resource is updated.

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

et

</td>  
<td>

expirationTime

</td>  
<td>

Time/date after which the resource is deleted by the Hosting CSE.

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

acpi

</td>  
<td>

accessControlPolicyIDs

</td>  
<td>

The attribute contains a list of identifiers of an <accessControlPolicy>
resource. The privileges defined in the <accessControlPolicy> resource that
are referenced determine who is allowed to access the resource containing this
attribute for a specific purpose (e.g. Retrieve, Update, Delete, etc.).

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

lbl

</td>  
<td>

label

</td>  
<td>

Tokens used to add meta-information to resources. This attribute is optional.

The value of the labels attribute is a list of individual labels, that can be
used for example for discovery

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

</td>  
<td>

</td>  
<td>

purposes when looking for particular resources that one can "tag" using that
label-key.

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

st

</td>  
<td>

stateTag

</td>  
<td>

An incremental counter of modification on the resource. When a resource is
created, this counter is set to 0, and it is incremented on every modification
of the resource

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

cs

</td>  
<td>

contentSize

</td>  
<td>

Size in bytes of the content attribute.

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

cr

</td>  
<td>

creator

</td>  
<td>

The ID of the entity (Application Entity or Common Services Entity) which
created the resource containing this attribute

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

cnf

</td>  
<td>

contentinfo

</td>  
<td>

Information on the content that is needed to understand the content. This
attribute is a composite attribute. It is composed first of an Internet Media
Type (as defined in the IETF RFC 6838) describing the type of the data, and
second of an encoding information that specifies how to first decode the
received content. Both elements of information are separated by a separator
defined in OneM2M TS-0004 [3].

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

or

</td>  
<td>

ontologyRef

</td>  
<td>

This attribute is optional.

A reference (URI) of the ontology used to represent the information that is
stored in the contentInstances resources of the <container> resource. If this
attribute is not present, the contentInstance resource inherits the
ontologyRef from the parent <container> resource if present.

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

#  Data management methodology in AUTOPILOT

The AUTOPILOT data collection process and data management is built upon
requirements coming from 4 processes:

  * **The evaluation requirement** defines the minimum data that must be collected in order to perform the evaluation process at the end of the project 

  

  * **The test specification** provides details about the data to be collected on the basis of the evaluation requirements and according to use cases specifications 

  

  * **The test data management** defines the data collection, harmonization, storage and sharing requirements using the first two processes and the ORDP process 

  

  * **The Open Research Data Pilot** 7  **(ORDP)** defines the requirement related to data sharing of research data 

  

##  Evaluation process requirements

AUTOPILOT applies an evaluation methodology based on FESTA  ( _Field
opErational teSt_ _supporT Action_ )  . This methodology consist of collecting
relevant set of data to carry out the assessment of hypothesis relating to the
benefit or improvement provided by IT solutions for the driving of vehicles,
in the context of AUTOPILOT, Automated Driving.

The Figure 3 below shows a high level view of the data that is collected and
integrated in the evaluation process. Different types of data (in blue) are
collected, stored and analysed by different processes.

To fulfil the project objectives, a design of experiment is performed during
the evaluation task. This design creates requirements that define the number
of scenarios and test cases, the duration of tests and test runs, the number
of situations per specific event, the number of test vehicles, the variation
in users, the variation in situations (weather, traffic, etc.). Each pilot
site must comply with this design of experiment and provide sufficient and
meaningful data with the required quality level to enable technical
evaluation.

##  Tests specification process requirements

The pilot tests specification Task T3.1 plays a major role that must be
thoroughly followed. Indeed, this task will convert the high level
requirements defined in the evaluation process into specific and detailed
specifications of data formats, data size, data currencies, data units, data
files, and storage. The list of requirements is defined for each of the
following items: Pilot sites, Scenarios, Test Cases, Measures, Parameters,
Data quality, etc. and is described in deliverable D3.1. All the development
tasks of WP2 must implement completely, if impacted, the requirement defined
in D3.1 in order to provide all the data (test data) as expected by the
technical evaluation.

##  Open research data pilot requirement process

Additional requirements related to ORDP (Open Research Data Pilot) are defined
in this document to guarantee that the collected data is provided in
compliance to European Commission Guidelines  8  on Data Management in Horizon
2020. Those requirements are deeply defined and explained in chapter 4 .

##  Test data management methodology

The main objective of the data management plan is to define the methodology to
be applied in AUTOPILOT across all pilot sites, in particular test data
management. This includes the explanation of the common data collection and
integration methodology.

One of the main objectives within T3.4 “Test Data management” is to ensure the
comparability and consistency of collected data across pilot sites. In this
context, the methodology is highly impacted by the pilot sites specifications
of the Task 3.1 and compliant with the evaluation methodologies developed in
the task 4.1. In particular, Technical evaluation primarily needs log data
from the vehicles, IoT platforms, cloud services and situational data from
pilot sites to detect situations and events, and to calculate indicators.

The log data parameters that are needed for technical evaluation are organized
by data sources (vehicle sources, vehicle data, derived data, positioning, V2X
messages, IoT messages, events, situations, surveys and questionnaires)

For IoT data, some pilot sites use proprietary IoT platforms in order to
collect specific produced IoT data with specific devices or vehicles (e.g. the
Brainport car sharing service and automated valet parking service use Watson
IoT Platform™ to collect data from their vehicles).

On the top of that, we have OneM2M interoperability platform in each pilot
site. This is the interoperability IoT platform for exchanging IoT messages
relevant to all autonomous driving

(AD) vehicles at pilot site level. Then, the test data is stored in pilot site
test server storage that will contain mainly the vehicle data, IoT data and
surveys data. Further, the test data is packaged and sent to the AUTOPILOT
central storage that will allow evaluators access all the pilot site data in a
common format. This includes the input from all pilot sites and use cases and
for all test scenarios and test runs.

Every pilot site has its own test storage server for data collection
(distributed data management), named PSTS (Pilot Site Test Server). In
addition, there is a central storage server where data from all pilot sites is
stored for evaluation and analysis, named CTS (Centralized Test Server).

Please note that the CTS and the PSTS are resources of the project, not
available for public use.

The following figure represents the data management methodology and
architecture used in AUTOPILOT across all pilot sites.

**Figure 4 – Generic scheme of data architecture in AUTOPILOT**

#  Participation in the open research data pilot

The AUTOPILOT project has agreed to participate in the Pilot on Open Research
Data in Horizon 2020  14  . The project uses specific Horizon 2020 guidelines
associated with ‘open’ access to ensure that the results of the project
results provide the greatest impact possible.

AUTOPILOT will ensure the open access  15  to all peer-reviewed scientific
publications relating to its results and will provide access to the research
data needed to validate the results presented in deposited scientific
publications.

The following lists the minimum fields of metadata that should come with an
AUTOPILOT project-generated scientific publication in a repository:

  * The terms: “European Union (EU)”, “Horizon 2020” 

  

  * Name of the action (Research and Innovation Action) 

  

  * Acronym and grant number (AUTOPILOT, 731993) 

  

  * Publication date 

  

  * Length of embargo period if applicable 

  

  * Persistent identifier 

  

When referencing Open access data, AUTOPILOT will include at a minimum the
following statement demonstrating EU support (with relevant in-formation
included into the repository metadata):

\- “This project has received funding from the European Union’s Horizon 2020
research and innovation program under grant agreement No 731993”.

The AUTOPILOT consortium will strive to make many of the collected datasets
open access. When this is not the case, the data sharing section for that
particular dataset will describe why access has been restricted. (See. Chapter
5)

In regards to the specific repositories available to the AUTOPILOT consortium,
numerous project partners maintain institutional repositories that is listed
in the following DMP version, where project scientific publications and in
some instances, research data is deposited. The use of a specific repository
will depend primarily on the primary creator of the publication and on the
data in question.

Some other project partners will not operate publically accessible
institutional repositories. When depositing scientific publications they shall
use either a domain specific repository or use the EU recommended service
OpenAIRE (http://www.openaire.eu) as an initial step to finding resources to
determine relevant repositories.

Project research data shall be deposited to the online data repository ZENODO
16  . It is a free service developed by CERN under the EU FP7 project
OpenAIREplus (grant agreement no.283595).

The repository shall also include information regarding the software, tools
and instruments

14

http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-
cutting-

issues/open-access-dissemination_en.htm 15

http://ec.europa.eu/research/participants/docs/h2020-funding-guide/cross-
cutting-

issues/open-access-data-management/open-access_en.htm 16 https://zenodo.org/

that were used by the dataset creator(s) so that secondary data users can
access and then validate the results.

The AUTOPILOT data collection can be accessed in ZENODO repository at the
following address:  _https://zenodo.org/communities/autopilot_

Note that publishing of data into Zenodo is made by data producers during the
project and after the end of the project.

In summary, as a baseline AUTOPILOT partners shall deposit:

  * Scientific publications – on their respective institute repositories in addition (when relevant) to the AUTOPILOT Zenodo repository 

  

  * Research data – to the AUTOPILOT Zenodo collection (when possible) 

  

  * Other project output files – to the AUTOPILOT Zenodo collection (when relevant) 

  

#  AUTOPILOT dataset description

##  General Description

This section provides an explanation of the different types of data sets
produced or collected in AUTOPILOT project.

The descriptions of the different data sets, including their reference, file
format, standards, methodologies and metadata and repository to be used are
given below. These descriptions are collected using the pilot sites
requirements and specifications.

It is important to note that the dataset bellow is produced by each use case
in all the pilot sites. The dataset categories are:

  * IoT dataset 

  

  * Vehicle dataset 

  

  * V2X messages dataset 

  

  * Surveys dataset 

  

All Pilot Sites have agreed about logged parameters. Therefore, following
table describes all the parameters used across Pilot Sites: most are shared, a
subset can be specific to a Pilot Site or a Use Case.

##  Template used in dataset description

This table is a template used to describe the datasets.

###  Table 2 – Dataset description template  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_datatype_ID**

Each data set will have a reference that is generated by the combination of
the name of the project, the pilot site (PS) and the use case in which it is
generated.

**Example** : AUTOPILOT_Versailles_Platooning_IOT_01

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

Dataset Nature

</td>  
<td>

Nature 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 and standards. 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 iscome 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

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

</td>  
<td>

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

**Example** : databases, institutional repositories, public repositories.

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

##  IOT dataset

**Table 3 – IOT dataset description**  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_IOT_ID**

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

Dataset Nature

</td>  
<td>

IOT data generated from connected devices

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

Dataset Description

</td>  
<td>

This dataset refer to the IOT datasets that is generated from IOT devices
within use cases. This includes the data coming from VRUs, RSUs, smartphones,
Vehicles, drones …

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

Standards and metadata

</td>  
<td>

During the project, The metadata related to the IOT data are based on OneM2M
standard. The OneM2M IOT platforms are implemented across pilot sites to cover
the interoperability feature. More details are provided in the section 2.2.2.

In addition, the data model of these data is inspired from the DMAG (data
management activity group) work done in T2.3. The DMAG defined a unified data
model that standardizes all the IOT messages across pilot sites. The AUTOPILOT
common IOT data model is based on different standards: SENSORIS, DATEX II.

After the project, The metadata is enriched with ZENODO’s metadata, including
the title, creator, date, contributor, pilot site, use case, description,
keywords, format, resource type, etc…

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

File format

</td>  
<td>

JSON, CSV

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

Data Sharing

</td>  
<td>

This dataset is widely open to be used by 3rd party applications and is
deposited in the ZENODO repository.

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

Archiving and Preservation

</td>  
<td>

During the project, the data will first be stored in the IOT platform. Then,
the data is transferred to the pilot site test server before finishing up in
the centralized test server. At the end of the project, the data set is
archived and preserved in ZENODO repositories.

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

###  IOT parameters description

**Table 4 – IoT parameters description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

rowid

</td>  
<td>

serial

</td>  
<td>

0..

</td>  
<td>

[N/A]

</td>  
<td>

sequence of row numbers to uniquely identify a log line by <log_stationid,
log_timestamp, rowid>, only

necessary when a subtable is logged

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

log_timestamp

</td>  
<td>

long

</td>  
<td>

from 0 to

4398046511103

</td>  
<td>

msec

</td>  
<td>

timestamp at which the log_stationid logs (writes) the data row. elapsed

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

</td>  
<td>

</td>  
<td>

(= 2⁴²-1)

</td>  
<td>

</td>  
<td>

time since midnight January 1st 1970 UTC

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

log_stationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the host (e.g. stationid, server id, IoT platform or device id,
cloud service id, ...) that logs this log data row. Log_stationid can be
another host than the source

generating the data to be logged

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

log_action

</td>  
<td>

enum

</td>  
<td>

['SENT', 'RECEIVED']

</td>  
<td>

[N/A]

</td>  
<td>

Action that triggered the logging event. (Enum: 'SENT', 'RECEIVED')

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

log_communicationprofile

</td>  
<td>

enum

</td>  
<td>

['ITS_G5',

'CELLULAR',

'UWB',

'LTE_V2X']

</td>  
<td>

[N/A]

</td>  
<td>

Communication profile, medium or path used to send or receive the message.
This needs to be logged in case messages are communicated via alternative
profiles. Default is ITS_G5. multiple channels are used to communicate similar
messages

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

log_messagetype

</td>  
<td>

enum

</td>  
<td>

['ETSI.CAM',

'ETSI.DENM',

'ISO.IVI',

'ETSI.MAPEM',

'ETSI.SPATEM']

‘IoT.IOT-

OBJECT’

</td>  
<td>

[N/A]

</td>  
<td>

Type of standardised message, used for automated processing in case multiple
message types are combined in a single log file. The enum fields refer to the
<standardisation organisation>.<message type>.

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

data

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

JSON containing data extracted from IoT platform, according to Use Case.

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

##  Vehicles dataset

**Table 5 – Vehicles dataset description**  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_VEHICLES_ID**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors.

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

Dataset Description

</td>  
<td>

This dataset refer to the vehicle datasets that is generated from the vehicle
sensors within use cases. This includes the data coming from the CAN bus,
cameras, RADARs, LIDARs and GPS.

Following log types can be produced by vehicles :

  * Vehicle 

  

  * Positioning system 

  

  * Vehicle dynamics 

  

  * Driver vehicle interaction 

  

  * Environment sensors 

  

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

Standards and metadata

</td>  
<td>

The vehicle data standards used in AUTOPILOT are developed in the task 2.1.
The pilot site implementations are based on well-known standards to come up
with a common data format: CAN, ROS … More details are provided in D2.1. After
the project, The metadata is based on ZENODO’s metadata, including the title,
creator, date, contributor, pilot

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

</td>  
<td>

site, use case, description, keywords, format, resource type, etc…

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

File format

</td>  
<td>

XML, CSV, SQL, JSON

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

Data Sharing

</td>  
<td>

This dataset is widely open to be used by 3rd party applications and is
deposited in the ZENODO repository.

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

Archiving and Preservation

</td>  
<td>

During the project, the data will first be stored in pilot site test server
before finishing up in the centralized test server. At the end of the project,
the data set is archived and preserved in ZENODO repositories.

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

###  Vehicles parameters description

All Pilot Sites have agreed about logged parameters. Therefore, following
table describes all the parameters used across Pilot Sites: most are common; a
subset can be specific to a Pilot Site or a Use Case.

First table describes the common metadata for the data that is logged with
every parameter

####  Table 6 – Vehicle common metadata description  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

rowid

</td>  
<td>

serial

</td>  
<td>

0..

</td>  
<td>

[N/A]

</td>  
<td>

sequence of row numbers to uniquely identify a log line by <log_stationid,
log_timestamp, rowid>, only necessary when a subtable is logged

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

log_timestamp

</td>  
<td>

long

</td>  
<td>

from 0 to 4398046511103

(= 2⁴²-1)

</td>  
<td>

msec

</td>  
<td>

timestamp at which the log_stationid logs (writes) the data row. elapsed time
since midnight January 1st 1970 UTC

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

log_stationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the host (e.g. stationid, server id, IoT platform or device id,
cloud service id, ...) that logs this log data row. Log_stationid can be
another host than the source generating the data to be logged

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

log_applicationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the application, instance or thread, on the log_stationid host
that logs this log data row. Applicationid is at least unique within the
log_station. ApplicationId is mandatory if multiple components on a host log
to the same table or if the application logging into a table is not trivial
(e.g. it is trivial that a CAM Basic Service is the only application logging
CAM messages in the cam table). For vehicle data, the log_applicationid is
also used to identify specific physical and virtual sensors, such as
front_camera, radar, lidar, GPS, CAN

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

####  Table 7 – Vehicle parameters description  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

speed

</td>  
<td>

doub

le

</td>  
<td>

from 0

163.82

</td>  
<td>

to

</td>  
<td>

[m/s]

</td>  
<td>

Speed over ground, meters per second.

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

outsidetempera ture

</td>  
<td>

doub

le

</td>  
<td>

from -60 to 67

</td>  
<td>

[°C]

</td>  
<td>

Vehicle outside temperature during trip.

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

insidetemperat ure

</td>  
<td>

doub

le

</td>  
<td>

from -60 to 67

</td>  
<td>

[°C]

</td>  
<td>

Vehicle inside temperature during trip.

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

batterysoc

</td>  
<td>

doub

le

</td>  
<td>

from 0 to

100

</td>  
<td>

[%]

</td>  
<td>

Percentage of the battery of the vehicle.

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

rangeestimated

</td>  
<td>

doub

le

</td>  
<td>

from 0 to

1000

</td>  
<td>

[km]

</td>  
<td>

Range estimated with the actual percentage of the battery and/or available
fuel.

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

fuelconsumptio n

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 1

</td>  
<td>

[L/k m]

</td>  
<td>

Average fuel consumption during a route or trip.

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

enginespeed

</td>  
<td>

int

</td>  
<td>

from 0 to 10000

</td>  
<td>

[1/mi

n]

</td>  
<td>

Engine speed calculated in terms of revolutions per minute.

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

owndistance

</td>  
<td>

doub

le

</td>  
<td>

from 0 to

5000

</td>  
<td>

[km]

</td>  
<td>

Total kilometrage per day or trip or road type etc.

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

**Table 8 – Positioning system parameters description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

speed

</td>  
<td>

double

</td>  
<td>

from 0 to

163.82

</td>  
<td>

[m/s]

</td>  
<td>

Speed over ground, meters per second. Measured by GNSS receiver.

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

longitude

</td>  
<td>

double

</td>  
<td>

from -90 to 90

</td>  
<td>

[degree]

</td>  
<td>

Longitude

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

latitude

</td>  
<td>

double

</td>  
<td>

from -180 to 180

</td>  
<td>

[degree]

</td>  
<td>

Latitude

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

heading

</td>  
<td>

double

</td>  
<td>

from 0 to

360

</td>  
<td>

[degree]

</td>  
<td>

Heading

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

ggasente nce

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[NMEA format]

</td>  
<td>

GGA - Fix information.

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

gsasente nce

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[NMEA format]

</td>  
<td>

GSA - Overall Satellite data.

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

rmcsente nce

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[NMEA format]

</td>  
<td>

RMC - recommended minimum data for gps.

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

vtgsente nce

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[NMEA format]

</td>  
<td>

VTG - Vector track an Speed over the Ground.

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

zdasente nce

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[NMEA format]

</td>  
<td>

ZDA - Date and Time.

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

**Table 9 – Vehicle dynamics description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

yawrate

</td>  
<td>

doub

le

</td>  
<td>

from -327.66 to 327.66

</td>  
<td>

[°/s]

</td>  
<td>

Vehicle rotation around the centre of mass of the empty vehicle. The leading
sign denotes the direction of rotation. The value is negative if the motion is
clockwise when viewing from the top.

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

acclateral

</td>  
<td>

doub

le

</td>  
<td>

from -16 to 16

</td>  
<td>

[m/s

2]

</td>  
<td>

Lateral acceleration of the vehicle.

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

acclongitudinal

</td>  
<td>

doub

le

</td>  
<td>

from -16 to 16

</td>  
<td>

[m/s

2]

</td>  
<td>

Longitudinal acceleration of the vehicle.

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

accvertical

</td>  
<td>

doub

le

</td>  
<td>

from -16 to 16

</td>  
<td>

[m/s

2]

</td>  
<td>

Vertical acceleration of the vehicle.

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

speedwheelunitd istance

</td>  
<td>

doub

le

</td>  
<td>

from 0 to

163.82

</td>  
<td>

[m/s]

</td>  
<td>

Sensor on free running wheel for increased accuracy. Speed measured from
wheels (???).

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

lanechange

</td>  
<td>

enu m

</td>  
<td>

[ 'NO' 'YES']

</td>  
<td>

[N/A]

</td>  
<td>

Lane change detection.

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

speedlimit

</td>  
<td>

int

</td>  
<td>

from 0 to

150

</td>  
<td>

[km/

h]

</td>  
<td>

Maximum legal speed limit (log_applicationid identifies the source: updated in
real time, from map information, from traffic sign).

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

**Table 10 – Driver vehicle interaction**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

throttlestatu

s

</td>  
<td>

int

</td>  
<td>

from 0 100

</td>  
<td>

to

</td>  
<td>

[%]

</td>  
<td>

Position of the throttle pedal (% pushed). Modify to boolean (i.e., 0->NOT
PUSHED, 1-> PUSHED) if % is not available on the car.

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

clutchstatus

</td>  
<td>

int

</td>  
<td>

from 0 100

</td>  
<td>

to

</td>  
<td>

[%]

</td>  
<td>

Position of the clutch pedal (% pushed). Modify to boolean (i.e., 0->NOT
PUSHED, 1-> PUSHED) if % is not available on the car.

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

brakestatus

</td>  
<td>

int

</td>  
<td>

from 0 100

</td>  
<td>

to

</td>  
<td>

[%]

</td>  
<td>

Position of the brake pedal (% pushed). Modify to boolean (i.e., 0->NOT
PUSHED, 1-> PUSHED) if % is not available on the car.

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

brakeforce

</td>  
<td>

double

</td>  
<td>

from 0 300

</td>  
<td>

to

</td>  
<td>

[bar]

</td>  
<td>

Measure of master cylinder pressure.

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

wipersstatus

</td>  
<td>

enum

</td>  
<td>

[ 'OFF' 'ON']

</td>  
<td>

[N/A]

</td>  
<td>

Position of the windscreen wipers (boolean). Extend the enumeration if more
details are available (e.g., ['OFF', 'SLOW', 'FAST'], ['OFF', 'SLOW1',
'SLOW2', 'FAST1', 'FAST2']).

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

steeringwhe

el

</td>  
<td>

double

</td>  
<td>

from -720 to 720

</td>  
<td>

[°]

</td>  
<td>

Position of the steering wheel.

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

adaptivecrui se controlstate

</td>  
<td>

enum

</td>  
<td>

[ 'OFF' 'ON']

</td>  
<td>

[N/A]

</td>  
<td>

ACC activated (ON) / or not (OFF)

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

adaptivecrui se controlsetsp eed

</td>  
<td>

double

</td>  
<td>

>0.0

</td>  
<td>

[m/s]

</td>  
<td>

Speed target setting of ACC

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

**Table 11 – Environment sensors absolute**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

longitude

</td>  
<td>

doub

le

</td>  
<td>

from -90 to 90

</td>  
<td>

[degree]

</td>  
<td>

Main object transformed to geolocalized coordinates longitudinal
(log_applicationid identifies the sensor providing this measurement (e.g.,
camea, lidar, radar,...)).

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

latitude

</td>  
<td>

doub

le

</td>  
<td>

from -180 to 180

</td>  
<td>

[degree]

</td>  
<td>

Main object transformed to geolocalized coordinates lateral position

(log_applicationid identifies the sensor providing this measurement (e.g.,
camea, lidar, radar,...)).

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

obstacle_ID

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[-]

</td>  
<td>

ID of the obstacle detected by

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

</th>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

environmental sensors

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

obstacle_covaria nce

</td>  
<td>

float 64

</td>  
<td>

</td>  
<td>

</td>  
<td>

Covariance matrix of positions of lon, lat, altitude of RADAR detected objects

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

ObjectClass

</td>  
<td>

int

</td>  
<td>

from 0 to 65

</td>  
<td>

[-]

</td>  
<td>

65 classes from Mapillary dataset --> see
http://research.mapillary.com/publication/ iccv17a/

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

lanewidthsensor based

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 10

</td>  
<td>

[m]

</td>  
<td>

Lane width measured by on-board sensor(s).

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

lanewidthmapba sed

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 10

</td>  
<td>

[m]

</td>  
<td>

Lane width from map information.

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

trafficsigndescrip tion

</td>  
<td>

strin g

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

speedlimit_sign

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 250

</td>  
<td>

[km/h]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

servicecategory

</td>  
<td>

enu m

</td>  
<td>

['dangerWarni

ng',

'regulatory',

'informative', 'publicFacilitie

s',

'ambientCondi

tion',

'roadCondition

' ]

</td>  
<td>

[N/A]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

servicecategoryc ode

</td>  
<td>

int

</td>  
<td>

[11, 12, 13, 21,

31, 32 ]

</td>  
<td>

[N/A]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

countrycode

</td>  
<td>

strin g

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1 (ISO 3166-1
alpha-2)

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

pictogramcategor ycode

</td>  
<td>

int

</td>  
<td>

from 0 to 999

</td>  
<td>

[N/A]

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

VRU_pedestrian_

class

</td>  
<td>

int

</td>  
<td>

from 0 - 3

</td>  
<td>

1 = children, 2 = adults, 3 = elderly

</td>  
<td>

sub classes of pedestrians

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

VRU_cyclist_class

</td>  
<td>

int

</td>  
<td>

from 0 - 3

</td>  
<td>

1 = children, 2 = adults, 3 = elderly

</td>  
<td>

sub classes of cyclists/riders

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

confidence_level

s

</td>  
<td>

doub

le

</td>  
<td>

from 0 - 100

</td>  
<td>

[%]

</td>  
<td>

Indication for false positive detections (minimum default level)

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

Environ_info

</td>  
<td>

int

</td>  
<td>

from 1 - 6

</td>  
<td>

[-]

</td>  
<td>

1=sunny/day, 2=raining/day, 3=snow/day,

4=night/dry, 5=raining/night, 6=snow/night

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

Road_hazard

</td>  
<td>

int

</td>  
<td>

from 0 to 42

</td>  
<td>

[N/A]

</td>  
<td>

No standardized dataset available --> current proposal: pothole detection,
slippery road, black ice etc.

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

sensor_position

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[mm]

</td>  
<td>

position of sensor on vehicle wrt. CoG. required for correlating to
environmental

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

detetction with Iot detections

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

process_delay

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[ms]

</td>  
<td>

is processing delay known or unknown?

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

**Table 12 – Environment sensors relative**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

</th>  
<th>

**Description**

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

x

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 500

</td>  
<td>

[m]

</td>  
<td>

</td>  
<td>

Main object relative distance longitudinal / x-direction (log_applicationid
identifies the sensor providing this measurement (e.g., camea, lidar,
radar,...)).

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

y

</td>  
<td>

doub

le

</td>  
<td>

from -50 to 50

</td>  
<td>

[m]

</td>  
<td>

</td>  
<td>

Main object relative distance lateral / ydirection (log_applicationid
identifies the sensor providing this measurement (e.g., camea, lidar,
radar,...)).

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

obstacle_ID

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[-]

</td>  
<td>

</td>  
<td>

ID of the obstacle detected by

environmental sensors

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

obstacle_covaria nce

</td>  
<td>

float 64

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

Covariance matrix of positions of lon, lat, altitude of RADAR detected objects

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

ObjectClass

</td>  
<td>

int

</td>  
<td>

from 0 to 65

</td>  
<td>

[-]

</td>  
<td>

</td>  
<td>

65 classes from Mapillary dataset --> see
http://research.mapillary.com/publication/ iccv17a/

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

lanewidthsensor based

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 10

</td>  
<td>

[m]

</td>  
<td>

</td>  
<td>

Lane width measured by on-board sensor(s).

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

lanewidthmapba sed

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 10

</td>  
<td>

[m]

</td>  
<td>

</td>  
<td>

Lane width from map information.

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

trafficsigndescrip tion

</td>  
<td>

strin g

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

speedlimit_sign

</td>  
<td>

doub

le

</td>  
<td>

from 0 to 250

</td>  
<td>

[km/h]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

servicecategory

</td>  
<td>

enu m

</td>  
<td>

['dangerWarni

ng',

'regulatory',

'informative', 'publicFacilitie

s',

'ambientCondi tion',

'roadCondition

' ]

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

servicecategoryc ode

</td>  
<td>

int

</td>  
<td>

[ 11, 12, 13,

21, 31, 32 ]

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

countrycode

</td>  
<td>

strin g

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1 (ISO 3166-1
alpha-2)

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

pictogramcategor ycode

</td>  
<td>

int

</td>  
<td>

from 0 to 999

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

signrecognition -- as defined in IVI - ISO TS 19321 (2015) v1

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

VRU_pedestrian_

class

</td>  
<td>

int

</td>  
<td>

from 0 - 3

</td>  
<td>

  1. = 

  

  

children,

  2. = 

  

  

adults,

  3. = 

  

  

elderly

</td>  
<td>

sub classes of pedestrians

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

VRU_cyclist_class

</td>  
<td>

int

</td>  
<td>

from 0 - 3

</td>  
<td>

  1. = 

  

  

children,

  2. = 

  

  

adults,

  3. = 

  

  

elderly

</td>  
<td>

sub classes of cyclists/riders

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

confidence_level

s

</td>  
<td>

doub

le

</td>  
<td>

from 0 - 100

</td>  
<td>

[%]

</td>  
<td>

</td>  
<td>

Indication for false positive detections (minimum default level)

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

Environ_info

</td>  
<td>

int

</td>  
<td>

from 1 - 6

</td>  
<td>

[-]

</td>  
<td>

</td>  
<td>

1=sunny/day, 2=raining/day, 3=snow/day,

4=night/dry, 5=raining/night, 6=snow/night

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

Road_hazard

</td>  
<td>

int

</td>  
<td>

from 0 to 42

</td>  
<td>

[N/A]

</td>  
<td>

</td>  
<td>

No standardized dataset available --> current proposal: pothole detection,
slippery road, black ice etc.

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

sensor_position

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[mm]

</td>  
<td>

</td>  
<td>

position of sensor on vehicle wrt. CoG. required for correlating to
environmental detetction with Iot detections

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

process_delay

</td>  
<td>

int

</td>  
<td>

from 0 to 1000

</td>  
<td>

[ms]

</td>  
<td>

</td>  
<td>

is processing delay known or unknown?

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

##  V2X messages dataset

**Table 13 – V2X messages dataset description**  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_V2X_ID**

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

Dataset Nature

</td>  
<td>

V2X messages communicated during test sessions

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

Dataset Description

</td>  
<td>

This dataset refer to the V2X messages that is generated from the
communication between the vehicles and any other party that could affect the
vehicle. This includes the other vehicles and the pilot site infrastructure.

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

Standards and metadata

</td>  
<td>

The V2X messages are mainly generated from the communication standard ITS-G5.

After the project, The metadata is enriched by ZENODO’s metadata, including
the title, creator, date, contributor, pilot site, use case, description,
keywords, format, resource type, etc…

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

File format

</td>  
<td>

CAM, DEMN, IVI, SPAT, MAP, CSV

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

Data Sharing

</td>  
<td>

This dataset is widely open to be used by 3rd party applications and is
deposited in the ZENODO repository.

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

Archiving and Preservation

</td>  
<td>

During the project, the data will first be stored in pilot site test server
before finishing up in the centralized test server. At the end of the project,
the data set is archived and preserved in ZENODO repositories.

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

###  V2X parameters description

**Table 14 – V2X parameters description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

rowid

</td>  
<td>

serial

</td>  
<td>

0..

</td>  
<td>

[N/A]

</td>  
<td>

sequence of row numbers to uniquely identify a log line by <log_stationid,
log_timestamp, rowid>, only

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

</th>  
<th>

</th>  
<th>

</th>  
<th>

</th>  
<th>

necessary when a subtable is logged

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

log_timestamp

</td>  
<td>

long

</td>  
<td>

from 0 to 4398046511103

(= 2⁴²-1)

</td>  
<td>

msec

</td>  
<td>

timestamp at which the log_stationid logs (writes) the data row. elapsed time
since midnight January 1st 1970 UTC

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

log_stationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the host (e.g. stationid, server id, IoT platform or device id,
cloud service id, ...) that logs this log data row. Log_stationid can be
another host than the source

generating the data to be logged

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

log_applicationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the application, instance or thread, on the log_stationid host
that logs this log data row.

Applicationid is at least unique within the log_station. ApplicationId is
mandatory if multiple components on a host log to the same table or if the
application logging into a table is not trivial (e.g. it is trivial that a CAM
Basic Service is the only application logging CAM messages in the cam table).
For vehicle data, the log_applicationid is also used to identify specific
physical and virtual sensors, such as front_camera, radar, lidar, GPS, CAN

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

log_action

</td>  
<td>

enum

</td>  
<td>

['SENT', 'RECEIVED']

</td>  
<td>

[N/A]

</td>  
<td>

Action that triggered the logging event. (Enum: 'SENT', 'RECEIVED')

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

log_communicationprofile

</td>  
<td>

enum

</td>  
<td>

['ITS_G5',

'CELLULAR',

'UWB',

'LTE_V2X']

</td>  
<td>

[N/A]

</td>  
<td>

Communication profile, medium or path used to send or receive the message.
This needs to be logged in case messages are communicated via alternative
profiles. Default is ITS_G5. multiple channels are used to communicate similar
messages

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

log_messagetype

</td>  
<td>

enum

</td>  
<td>

['ETSI.CAM',

'ETSI.DENM',

'ISO.IVI',

'ETSI.MAPEM',

'ETSI.SPATEM']

</td>  
<td>

[N/A]

</td>  
<td>

Type of standardised message, used for automated processing in case multiple
message types are combined in a single log file. The enum fields refer to the
<standardisation organisation>.<message type>.

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

log_messageuuid

</td>  
<td>

uuid

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

Universal Unique Identifier of the message. This is an alternative for the
identification of messages from the message contents. If used, then the uuid
should also be included in the payload of the message and communicated between
senders and receivers.

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

data

</td>  
<td>

string

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

CAM or DENM message payload

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

##  Application messages dataset

**Table 15 – Applications dataset description**  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_APPLICATION_ID**

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

Dataset Nature

</td>  
<td>

Application data collected during test sessions

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

Dataset Description

</td>  
<td>

This data refers to the data generated by AD applications.

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

Standards and metadata

</td>  
<td>

The application messages are mainly text application status exchanged between
AD applications and services.

After the project, The metadata is enriched by ZENODO’s metadata, including
the title, creator, date, contributor, pilot site, use case, description,
keywords, format, resource type, etc…

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

File format

</td>  
<td>

CSV

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

Data Sharing

</td>  
<td>

This dataset is widely open to be used by 3rd party applications and is
deposited in the ZENODO repository.

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

Archiving and Preservation

</td>  
<td>

During the project, the data will first be stored in pilot site test server
before finishing up in the centralized test server. At the end of the project,
the data set is archived and preserved in ZENODO repositories.

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

###  Application messages parameters description

**Table 16 – Platooning event parameters description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

rowid

</td>  
<td>

serial

</td>  
<td>

0..

</td>  
<td>

</td>  
<td>

[N/A]

</td>  
<td>

sequence of row numbers to uniquely identify a log line by <log_stationid,
log_timestamp, rowid>

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

log_timestamp

</td>  
<td>

long

</td>  
<td>

from 0

4398046511103

(= 2⁴²-1)

</td>  
<td>

to

</td>  
<td>

[millisecond]

</td>  
<td>

timestamp at which the

log_stationid logs (writes) the data row. elapsed time since midnight January
1st 1970 UTC

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

log_stationid

</td>  
<td>

long

</td>  
<td>

from 0

4294967295

(= 2³²-1)

</td>  
<td>

to

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the host (stationid or processing unit id) that logs this log
data row. Log_stationid can be another host than the source generating the
data to be logged

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

log_applicationid

</td>  
<td>

long

</td>  
<td>

from 0

4294967295

(= 2³²-1)

</td>  
<td>

to

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the application, instance or thread, on the log_stationid host
that logs this log data row. Applicationid is at least unique within the
log_station. ApplicationId is mandatory if multiple components on a host log

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

to the same table or if the application logging into a table is not trivial
(e.g. it is trivial that a CAM Basic Service is the only application logging
CAM messages in the cam table).

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

eventtypeid

</td>  
<td>

enum

</td>  
<td>

</td>  
<td>

</td>  
<td>

event type is defined in the EventModels tables, e.g. for GLOSA

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

eventid

</td>  
<td>

long

</td>  
<td>

</td>  
<td>

</td>  
<td>

unique id defined by the stationid. Note that this cannot be specific to an
application within a station

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

action

</td>  
<td>

enum

</td>  
<td>

['VEHICLE',

'PLATOON_SERVICE']

</td>  
<td>

[N/A]

</td>  
<td>

Action that triggered the logging event. (Enum: 'SENT', 'RECEIVED')

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

**Table 17 – Platooning action parameters description**  
  
<table>  
<tr>  
<th>

**Name**

</th>  
<th>

**Type**

</th>  
<th>

**Range**

</th>  
<th>

**Unit**

</th>  
<th>

**Description**

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

rowid

</td>  
<td>

serial

</td>  
<td>

0..

</td>  
<td>

[N/A]

</td>  
<td>

sequence of row numbers to uniquely identify a log line by

<log_stationid, log_timestamp, rowid>

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

log_timestamp

</td>  
<td>

long

</td>  
<td>

from 0 to

4398046511103

(= 2⁴²-1)

</td>  
<td>

[millisecond]

</td>  
<td>

timestamp at which the

log_stationid logs (writes) the data row. elapsed time since midnight January
1st 1970

UTC

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

log_stationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the host (stationid or processing unit id) that logs this log
data row. Log_stationid can be another host than the source generating the
data to be logged

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

log_applicationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

unique id of the application, instance or thread, on the log_stationid host
that logs this log data row. Applicationid is at least

unique within the log_station. ApplicationId is mandatory if multiple
components on a host log to the same table or if the application logging into
a table is not trivial (e.g. it is trivial that a CAM Basic

Service is the only application logging CAM messages in the cam table).

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

eventid

</td>  
<td>

long

</td>  
<td>

</td>  
<td>

</td>  
<td>

unique id defined by the

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

stationid. Note that this cannot be specific to an

application within a station

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

eventmodelid

</td>  
<td>

int

</td>  
<td>

</td>  
<td>

</td>  
<td>

unique id of the event model from the EventModels sheet

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

eventactionid

</td>  
<td>

int

</td>  
<td>

</td>  
<td>

</td>  
<td>

unique id of the action from the EventModels sheet

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

platooningserviceid

</td>  
<td>

?

</td>  
<td>

</td>  
<td>

</td>  
<td>

PlatooningService to subscribe to

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

leaderstationid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

stationid from platoon leader, e.g. from PlatoonFormation

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

platoonid

</td>  
<td>

long

</td>  
<td>

from 0 to 4294967295

(= 2³²-1)

</td>  
<td>

[N/A]

</td>  
<td>

platoonid e.g. from

PlatoonFormation message

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

generationtime stamputc

</td>  
<td>

long

</td>  
<td>

from 0 to

9223372036854775807 or from 0 to

4398046511103 (= 2⁴²1) [millisecond]

</td>  
<td>

[millisecond]

</td>  
<td>

generationtimestampITC from PlatoonFormation message

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

##  Surveys dataset

###  Table 18 – Surveys dataset description  
  
<table>  
<tr>  
<th>

Dataset Reference

</th>  
<th>

**AUTOPILOT_PS_UC_SURVEYS_ID**

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

Dataset Nature

</td>  
<td>

Surveys data collected during test sessions

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

Dataset Description

</td>  
<td>

This data refers to the data resulting from the answers of surveys and
questionnaires for user acceptance evaluation.

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

Standards and metadata

</td>  
<td>

Surveys data will use some well-known tools (Google Forms, Survey Monkey …)

The work of definition a common format for surveys data is still in progress
by the user acceptance evaluation team.

After the project, The metadata is enriched by ZENODO’s metadata, including
the title, creator, date, contributor, pilot site, use case, description,
keywords, format, resource type, etc…

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

File format

</td>  
<td>

CSV, PDF, XLS

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

Data Sharing

</td>  
<td>

This dataset is widely open to be used by 3rd party applications and is
deposited in the ZENODO repository. It is important to note that these data is
**anonymized** before data sharing.

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

Archiving and Preservation

</td>  
<td>

During the project, the data will first be stored in pilot site test server
before finishing up in the centralized test server. At the end of the project,
the data set is archived and preserved in ZENODO repositories.

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

##  Brainport datasets

###  Platooning

**Table 19 – Brainport platooning datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_BrainPort_Platooning_DriverVehicleInteraction**

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

Dataset Nature

</td>  
<td>

Data extracted from the CAN of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains e.g. throttlestatus, clutchstatus, brakestatus,
brakeforce, wipersstatus, steeringwheel for the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_EnvironmentSensorsAbsolute**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with absolute
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_EnvironmentSensorsRelative**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with relative
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_IotVehicleMessage**

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

Dataset Nature

</td>  
<td>

Data sent between all devices, vehicles and services

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

Dataset

Description

</td>  
<td>

Each sensor data submission is a Message. A Message has an Envelope, a Path,
and optionally (but likely) Path Events and optionally Path Media. The
envelope bears fundamental information about the individual sender (the
vehicle) but not to a level that owner of the vehicle can be identified or
different messages can be identified that originate from a single vehicle.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PlatoonFormation**

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

Dataset Nature

</td>  
<td>

Data sent from PlatoonService to vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains information about the route and speed for a specific
vehicle for forming a platoon

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PlatooningAction**

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

Dataset Nature

</td>  
<td>

Data logged by vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains information about the current status of the platooning

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PlatooningEvent**

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

Dataset Nature

</td>  
<td>

Data logged by vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains information about the identifiers used for each specific
platooning event

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

File format

</th>  
<th>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PlatoonStatus**

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

Dataset Nature

</td>  
<td>

Data sent by vehicle to PlatoonService

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

Dataset

Description

</td>  
<td>

This dataset contains information about the current status of the platooning

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PositioningSystem**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed, longitude, latitude, heading from the GPS

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PositioningSystemResample**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed,longitude,latitude,heading from the GPS, resampled
to 100 milliseconds

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_PSInfo**

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

Dataset Nature

</td>  
<td>

Data sent by PlatoonService to the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed and route information for the vehicle to create a
platoon

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_Target**

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

Dataset Nature

</td>  
<td>

Data from sensors on the vehicle

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

Dataset

Description

</td>  
<td>

Target detection in the vicinity of the host vehicle, by a vehicle sensor or
virtual sensor

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_Vehicle**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o temperature and battery state of the vehicles

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_VehicleDynamics**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o accelerations and speedlimit of the vehicle, as
observed from the CAN and the external sensors

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_Platooning_VehicleDynamics**

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

Dataset

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Nature

</td>  
<td>

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

Dataset

Description

</td>  
<td>

This dataset contains a.o accelerations and speedlimit of the vehicle, as
observed from the CAN and the external sensors

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

File format

</td>  
<td>

CSV

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

###  Automated valet parking

**Table 20 – Brainport automated valet parking datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction**

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

Dataset Nature

</td>  
<td>

Data extracted from the CAN of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains e.g. throttlestatus, clutchstatus, brakestatus,
brakeforce, wipersstatus, steeringwheel for the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand**

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

Dataset Nature

</td>  
<td>

Data sent from drone

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

Dataset

Description

</td>  
<td>

This dataset contains route information for a vehicle to a designated parking
spot

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with absolute
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with relative
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage**

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

Dataset Nature

</td>  
<td>

Data sent between all devices, vehicles and services

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

Dataset

Description

</td>  
<td>

Each sensor data submission is a Message. A Message has an Envelope, a Path,
and optionally (but likely) Path Events and optionally Path Media. The
envelope bears fundamental information about the individual sender (the
vehicle) but not to a level that owner of the vehicle can be identified or
different messages can be identified that originate from a single vehicle.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection**

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

Dataset Nature

</td>  
<td>

Data sent from drone to parkingService

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

Dataset

Description

</td>  
<td>

This dataset contains informaton about detected parking spots

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed, longitude, latitude, heading from the GPS

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed,longitude,latitude,heading from the GPS, resampled
to 100 milliseconds

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o temperature and battery state of the vehicles

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand**

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

Dataset Nature

</td>  
<td>

Data sent from ParkingService to vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains route to parkingspot, and some other environmental
information

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus**

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

Dataset Nature

</td>  
<td>

Data sent from vehicle to ParkingService

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

Dataset

Description

</td>  
<td>

This dataset contains information about the current status and parkingstatus
of the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o accelerations and speedlimit of the vehicle, as
observed from the CAN and the external sensors

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

File format

</td>  
<td>

CSV

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

###  Highway pilot

**Table 21 – Brainport highway pilot datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_BrainPort_HighwayPilot_AdasCommand**

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

Dataset Nature

</td>  
<td>

Data from the automated driver assistance system

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

Dataset

</td>  
<td>

This dataset contains the ADAS command in the vehicle

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

Description

</th>  
<th>

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_Anomaly**

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

Dataset Nature

</td>  
<td>

Data sent from detecting vehicle to the service, and from service to vehicles

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

Dataset

Description

</td>  
<td>

This dataset contains information about all the detected anomalies on the road

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_AnomalyImage**

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

Dataset Nature

</td>  
<td>

Data sent from detecting vehicle to service

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

Dataset

Description

</td>  
<td>

This dataset contains images of the detected anomalies

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_DriverVehicleInteraction**

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

Dataset Nature

</td>  
<td>

Data extracted from the CAN of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains e.g.
throttlestatus,clutchstatus,brakestatus,brakeforce,wipersstatus,steeringwheel
for the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_EnvironmentSensorsAbsolute**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with absolute
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_EnvironmentSensorsRelative**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with relative
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_Hazard**

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

Dataset Nature

</td>  
<td>

Data sent from service to vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains specific information for a vehicle about anomalies and
hazards

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_IotVehicleMessage**

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

Dataset Nature

</td>  
<td>

Data sent between all devices, vehicles and services

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

Dataset

Description

</td>  
<td>

Each sensor data submission is a Message. A Message has an Envelope, a Path,
and optionally (but likely) Path Events and optionally Path Media. The
envelope bears fundamental information about the individual sender (the

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

</td>  
<td>

vehicle) but not to a level that owner of the vehicle can be identified or
different messages can be identified that originate from a single vehicle.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_PositioningSystem**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed, longitude, latitude, heading from the GPS

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_Vehicle**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o temperature and battery state of the vehicles

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_HighwayPilot_VehicleDynamics**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o accelerations and speedlimit of the vehicle, as
observed from the CAN and the external sensors

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

File format

</td>  
<td>

CSV

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

###  Urban driving

**Table 22 – Brainport urban driving datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_BrainPort_ UrbanDriving_DriverVehicleInteraction**

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

Dataset Nature

</td>  
<td>

Data extracted from the CAN of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains e.g. throttlestatus, clutchstatus, brakestatus,
brakeforce, wipersstatus, steeringwheel for the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_EAI2Mobile**

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

Dataset Nature

</td>  
<td>

Data from the service to the mobile

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

Dataset

Description

</td>  
<td>

This dataset contains information sent to the mobile about the Estimated
Arrival time and position

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_EnvironmentSensorsAbsolute**

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

Dataset Nature

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with absolute
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_EnvironmentSensorsRelative**

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

Dataset

</td>  
<td>

Data extracted from the vehicle environment sensors

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

Nature

</th>  
<th>

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

Dataset

Description

</td>  
<td>

This dataset contains information about detected object, with relative
coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_IOT_CEMA_Message**

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

Dataset Nature

</td>  
<td>

Data from the service to the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains information from the Crowd Estimation and Mobility
Analytics service

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_IOT_FlowRadar_Message**

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

Dataset Nature

</td>  
<td>

Data from the vehicle to the service

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

Dataset

Description

</td>  
<td>

This dataset contains the GPS informaton (speed,position,heading) from the
vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_IotVehicleMessage**

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

Dataset Nature

</td>  
<td>

Data sent between all devices, vehicles and services

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

Dataset

Description

</td>  
<td>

Each sensor data submission is a Message. A Message has an Envelope, a Path,
and optionally (but likely) Path Events and optionally Path Media. The
envelope bears fundamental information about the individual sender (the
vehicle) but not to a level that owner of the vehicle can be identified or
different messages can be identified that originate from a single vehicle.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_IOT_VehicleStatus**

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

Dataset Nature

</td>  
<td>

Data sent from the vehicle to the service

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

Dataset

Description

</td>  
<td>

This dataset contains the current status of the vehicle

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_PositioningSystem**

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

Dataset Nature

</td>  
<td>

Data from GPS on the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains speed,longitude,latitude,heading from the GPS

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_SmartphoneGPS**

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

Dataset Nature

</td>  
<td>

Data sent by the mobile to the service

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

Dataset

Description

</td>  
<td>

This dataset contains the GPS informaton (speed,position,heading) from the
mobile

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_SmartphoneStatus**

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

Dataset Nature

</td>  
<td>

Data sent from the mobile to the service

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

Dataset

Description

</td>  
<td>

This dataset contains the current status of the mobile

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_TaxiRequest**

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

Dataset Nature

</td>  
<td>

Data sent from the mobile to the service

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

Dataset

Description

</td>  
<td>

This dataset contains the requests for a taxi from the mobile phones

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_Vehicle**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o temperature and battery state of the vehicles

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_BrainPort_ UrbanDriving_VehicleDynamics**

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

Dataset Nature

</td>  
<td>

Data from the CAN and sensors about the state of the vehicle

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

Dataset

Description

</td>  
<td>

This dataset contains a.o accelerations and speedlimit of the vehicle, as
observed from the CAN and the external sensors

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

File format

</td>  
<td>

CSV

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

##  Livorno datasets

###  Urban driving

**Table 23 – Livorno urban driving datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Livorno_UrbanDriving_Vehicle_all**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

This dataset refers to the vehicle datasets generated from the vehicle sensors
during Platooning at Versailles. This includes the data coming from the CAN
bus and GPS.

It includes following kind of dataset:

Vehicle: general data (speed, battery)

PositioningSystem: data from GPS

VehicleDynamics: data about dynamic (acceleration...)

LateralControl: steering and lane control data

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Livorno_UrbanDriving_V2X_all**

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

Dataset Nature

</td>  
<td>

V2V messages during platooning sessions

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

Dataset

Description

</td>  
<td>

This dataset refers to the V2V messages exchanged between ITS stations
(vehicles and RSUs) during the Urban Drining in Livorno.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Livorno_UrbanDriving_IoT_all**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refers to messages exchanged by Urban Driving devices,
applications and services across the oneM2M platform.

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

File format

</td>  
<td>

CSV

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

###  Highway pilot

**Table 24 – Livorno highway pilot datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Livorno_HighwayPilot_Vehicle_all**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

This dataset refers to the vehicle datasets generated from the vehicle sensors
during Platooning at Versailles. This includes the data coming from the CAN
bus and GPS.

It includes following kind of dataset:

Vehicle: general data (speed, battery)

PositioningSystem: data from GPS

VehicleDynamics: data about dynamic (acceleration...)

LateralControl: steering and lane control data

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Livorno_HighwayPilot_V2X_all**

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

Dataset Nature

</td>  
<td>

V2V messages during platooning sessions

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

Dataset

Description

</td>  
<td>

This dataset refers to the V2V messages exchanged between ITS stations
(vehicles and RSUs) during the Highway Piloting in Livorno.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Livorno_HighwayPilot_IoT_all**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refers to messages exchanged by HighwayPilot devices,
applications and services across the oneM2M platform.

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

File format

</td>  
<td>

CSV

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

##  Versailles datasets

###  Platooning

**Table 25 – Versailles platooning datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Versailles_Platooning_Vehicle**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

Vehicle datasets generated by the vehicle sensors during platooning at
Versailles. This includes the data coming from the CAN bus and GPS. It
includes following kind of datasets:

Vehicle: general data (speed, battery)

PositioningSystem: data from GPS

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

</td>  
<td>

VehicleDynamics: data about dynamic (acceleration...) LateralControl: steering
and lane control data

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Versailles_Platooning_V2X**

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

Dataset Nature

</td>  
<td>

V2X messages during platooning sessions

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

Dataset

Description

</td>  
<td>

This dataset refers to the V2V messages exchanged between the vehicles during
the platooning at Versailles.

TCPwlan logs contain mainly the identification of sender and receiver and the
payload extracted from TCP messages captured on the CAN bus.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Versailles_Platooning_IoT**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refers to messages exchanged by platooning application and
services, Traffic Light Assist service, traffic light controllers across
oneM2M platform.

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

File format

</td>  
<td>

CSV

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

###  Urban driving

**Table 26 – Versailles urban driving datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Versailles_UrbanDriving_Vehicle**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

Vehicle datasets generated by the vehicle sensors during urban driving at
Versailles. This includes the data coming from the CAN bus and GPS. It
includes following kind of datasets:

Vehicle: general data (speed, battery)

PositioningSystem: data from GPS

VehicleDynamics: data about dynamic (acceleration...)

Accel: acceleration data

EnvironmentSensorsAbsolute: environment sensors in absolute coordinates

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Versailles_UrbanDriving_V2X**

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

Dataset Nature

</td>  
<td>

V2X messages during urban driving sessions

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

Dataset

Description

</td>  
<td>

Data exchanged with other vehicles and pedestrian during urban driving.
SortOfCam: messages sent or received from bicycles

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Versailles_UrbanDriving_IoT**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refers to messages exchanged by urban driving and car sharing
application with vehicle, across oneM2M platform. oneM2M: car sharing status
data

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Versailles_UrbanDriving_CAM**

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

Dataset Nature

</td>  
<td>

CAM messages

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

Dataset

Description

</td>  
<td>

This dataset refers to messages captured inside the vehicle during car
sharing.

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

File format

</td>  
<td>

CSV

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

##  Vigo datasets

###  Automated valet parking

**Table 27 – Vigo automated valet parking datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Vigo_Automated_Valet_Parking_Vehicle_all**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

Datasets generated from the vehicle sensors

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Vigo_Automated_Valet_Parking_V2X_all**

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

Dataset Nature

</td>  
<td>

V2X messages during avp sessions

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

Dataset

Description

</td>  
<td>

This dataset refer to the V2X messages generated from the communication
between the vehicle and the infrastructure.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Vigo_Automated_Valet_Parking_IoT_all**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refer to the IOT datasets generated from IOT devices

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

File format

</td>  
<td>

CSV

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

###  Urban driving

**Table 28 – Vigo urban driving datasets description**  
  
<table>  
<tr>  
<th>

**AUTOPILOT_Vigo_Automated_Urban_Driving_Vehicle_all**

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

Dataset Nature

</td>  
<td>

Data generated from the vehicle sensors

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

Dataset

Description

</td>  
<td>

Datasets generated from the vehicle sensors

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Vigo_Automated_Urban_Driving_V2X_all**

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

Dataset Nature

</td>  
<td>

V2X messages during urban driving sessions

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

Dataset

Description

</td>  
<td>

This dataset refer to the V2X messages generated from the communication
between the vehicle, others vehicles and the infrastructure.

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

File format

</td>  
<td>

CSV

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

**AUTOPILOT_Vigo_Automated_Urban_Driving_IoT_all**

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

Dataset Nature

</td>  
<td>

Data extracted from IoT oneM2M platform

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

Dataset

Description

</td>  
<td>

This dataset refer to the IOT datasets generated from IOT devices

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

File format

</td>  
<td>

CSV

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

#  FAIR data management principles

The data that is generated during and after the project should be **FAIR** 9
, that is Findable, Accessible, Interoperable and Reusable. These requirements
do not affect implementation choices and don’t necessarily suggest any
specific technology, standard, or implementation solution.

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

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

This is intended as an implementation of the FAIR concept rather than a strict
technical implementation of the FAIR principles. AUTOPILOT project has
implemented several actions described below to carry on the FAIR principles.

##  Making data findable, including provisions for metadata

  * The data sets will have very rich metadata to facilitate the findability. In particular for IOT data, the metadata are based on the OneM2M standard. 

  

  * All the data sets will have a Digital Object Identifiers provided by the public repository (ZENODO) 

  

  * The reference used for the data set will follow this format : **AUTOPILOT_PS_UC_Datatype_XX**

  

  * The standards for metadata are defined in the chapter 5 tables and explained in section 2.2. 

  

##  Making data openly accessible

  * All the data sets that are openly available are described in the chapter 5. 

  

  * The data sets for evaluation is accessible via AUTOPILOT centralized test server. 

  

  * The data sets is made available using public repository (e.g. ZENODO) after the project 

  

  * The data sharing in chapter 5 explains the methods or software used to access the data. Basically, no software is needed to access the data 

  

  * The data and their associated metadata is deposed in a public repository or either in an institutional repository. 

  

  * The data sharing in the section 4 will outline the rules to access the data if restrictions exist 

  

##  Making data interoperable

  * The metadata vocabularies, standards and methodologies will depend on the public repository and are mentioned in the chapter 5 0tables. 

  

  * The AUTOPILOT WP2 made several actions in order to define common data formats. 

  

This work was developed in task 2.1 for vehicle data and task 2.3 for Iot
data. The

goal is to have the same structure across pilot sites and enable evaluators
dealing with the same format for all pilot sites.

  * AUTOPILOT PS use IOT platforms based on OneM2M standards to enable data interoperability across pilot sites. 

  

##  Increase data re-use (through clarifying licenses)

  * All the data producers will license their data to allow the widest reuse possible. 

  

  * By default, the data is made available for reuse. If any constrains exist, an embargo period is mentioned in the section 4 tables to keep the data for only a period of time 

  

  * The data producers will make their data for third-parties within public repositories. They is reused for the scientific publications validation purpose 

  

#  Responsibilities

In order to face the data management challenges efficiently, All AUTOPILOT
partners have to respect the policies set out in this DMP and datasets have to
be created, managed and stored appropriately.

The Data controller role within AUTOPILOT is undertaken by Francois Fischer
(ERTICO) who will directly report to the AUTOPILOT Ethics Board. The Data
controller acts as the point of contact for Data Protection issue and will
coordinate the actions required to liaise between different beneficiaries and
their affiliates, as well as their respective Data Protection agencies, in
order to ensure that data collection and processing within the scope of
AUTOPILOT, is carried out according to EU and national legislation. Regarding
the ORDP, the data controller must ensure that data are shared and easily
available.

Each data producer and WPL is responsible for the integrity and compatibility
of its data during the project lifetime. The data producer is responsible for
sharing its datasets through open access repositories. He is in charge of
providing the latest version.

Regarding ethical issues, the deliverable D7.1 details all the measures that
AUTOPILOT will use to comply with the H2020 Ethics requirements.

The Data Manager role within AUTOPILOT will directly report to the Technical
Meeting Team (TMT). The Data Manager will coordinate the actions related to
data management and in particular the compliance to Open Research Data Pilot
guideline. The data manager is responsible for implementing the data
management plan and he ensures it is reviewed and revised.

#  Ethical issues and legal compliance

As explained in Chapter 2, the central IoT platform is a cloud platform that
is hosted on IBM infrastructure, and maintained by IBM IE. It will integrate
and aggregate data from the various vehicles and pilot sites.

All data transfers to the IBM hosted central IoT Platform are subject to and
conditional upon compliance with the following requirements:

  * Prior to any transfer of data to the IBM hosted central IoT platform, all partners must execute an agreement as provided for in Attachment 6 of Autopilot Collaboration Agreement. 

  

  * All the partners must agree to commit not to provide personal data to the central IoT platform and to represent that it secures all necessary authorizations & consents before sharing data or any other type of information (“Background, Results, Confidential Information and/or any data”) with other parties. 

  

  * Every partner that needs to send and store data in the central IoT platform has to request access to the servers, and inform IBM IE what type of data they will send. 

  

  * IBM IE will review all data sources BEFORE approving them and allowing them into the central IoT platform, to ensure they are transformed into data that cannot be traced back to personal information. 

  

  * No raw videos/images or private information can be sent to the central IoT platform. The partners who will send data to the platform must anonymize data first. Only anonymized information that is extracted from the raw images/videos (e.g., distance between cars, presence of pedestrians, etc.) is accepted and stored. 

  

  * The central IoT platform will only be made available to the consortium partners, and not to external entities. 

  

  * IBM IE reserves the right to suspend partner’s access in case of any suspicious activities detected or non-compliant data received. IBM IE may re-grant access to the platform if a solution demonstrating how to prevent such sharing of personal data and sensitive personal data is reached and implemented. 

  

  * IBM IE may implement validation procedures to check that the submitted data structures and types are compliant with what the partners promised to send to the central IoT platform. 

  

  * All the data is deleted at the end of the project from all servers of the central IoT platform. 

  

#  Conclusion

This deliverable provides an overview of the data that AUTOPILOT project
produced together with related data processes and requirements taken into
consideration.

The document outlines an overview about the data set types with detailed
description and explains the processes followed for test sites and evaluation
within high level representations.

The chapter 5, which describes the data sets, has been enriched with the last
progress of the project comparing to the previous version of the DMP (D6.9).
This includes detailed description of the standards, methodologies, sharing
policies and storage methods.

This final version of the Data Management Plan provides all the details
concerning the datasets. These dataset are the results of the test sessions
performed at pilot sites level. However, some additional data may be provided
later as soon as the partners agree on the data to be shared.

Work on data preparation and data processing are ongoing and will enable help
increasing the amount of data to be shared in public repository after the
project according to ORDP initiative.