**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 first version of the DMP elaborated by the SAFE
STRIP 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
will be handled during the project and describes what data will be collected,
processed or generated and following what methodology and standards, whether
and how this data will be shared and/or made open, and how it will be curated
and preserved. Besides, an initial list of data types, metadata and global
data collection processes are also provided in this document.

The SAFE STRIP Data Management Plan refers to the latest EC DMP guidelines.
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).

Since the data management plan is expected to evolve during the project while
taking into account the progress of the work, especially regarding sensors
specifications, use cases, system architecture, pilot preparation and data
modelling and fusion activities, an updated version will be produced as
foreseen (deliverable D2.3) in M29.

Deliverable D2.2 SAFE STRIP Initial Data Management Plan Version 1.0Date
08/11/2017

6

  1. **Introduction**

  

  

**1.1 SAFE STRIP main concept and objectives**

**SAFE STRIP** aims to introduce a **disruptive technology** that will achieve
**to embed C-ITS applications in existing road infrastructure** , including
novel I2V and V2I, as well as VMS/VSL functions **into low-cost, integrated
strips markers on the road** . The SAFE STRIP vision is to make roads self-
explanatory (with personalised in-vehicle messages) and forgiving (due to
advanced cooperative functions) for all road users (trucks, cars and
vulnerable road users, such as PTWs riders) and all vehicle generations (non-
equipped, C-ITS equipped, autonomous), with reduced maintenance cost, full
recyclability and added value services, as well as supporting real-time
predictive road maintenance functions.

A brief overview of the specific project objectives is given below:

  1. To develop a novel micro/nano sensorial system integrated in road pavement tapes/ markers; that will provide advanced safety functions to all road users at a fraction of the cost of current I2V/V2I nodes and roadside equipment. 

  

  2. To support predictive infrastructure maintenance, through dynamic road embedded sensors input. 

  

  3. To make road infrastructure (mainly for highways and interurban roads but also for city rings and selected rural roads) self-explanatory (through personalised info in own language and preferred format provided by the system to each driver/rider) and forgiving (through key I2V/V2I info provided to the cooperative system of the vehicle; such as dynamic speed limit and friction coefficient factor); for all vehicle types. 

  

  4. To extend this notion to parking depots, key intermodal nodes, such as railway crossings, harbour loading/uploading areas and logistic depots and work zone areas. 

  

  5. To reduce the infrastructure operational (including VMS/VSL info and toll collection functions), installation and maintenance costs. 

  

  6. To provide key info to C-ITS equipped and autonomous vehicles about road, weather and traffic conditions ahead, to support dynamic trajectory estimation and optimisation. 

  

  7. To support a wide range of added value services. 

  

  8. To evaluate the system in a controlled environment. 

  

  

In order to realise its vision, SAFE STRIP will implement two complementary as
well as alternative solutions, one to address equipped vehicles (namely,
intelligent vehicles with on board sensors and C-ITS or automation
applications) and one to address nonequipped vehicles (the great majority of
current vehicle fleets, including also vehicles that are very difficult to
equip with rich on-board sensorial platforms, like PTW’s).

**1.2 Purpose of the Document**

The purpose of this deliverable ( _D2.2-Data Management Plan_ ) is to provide
an analysis of the main elements of the data management policy that will be
used by the consortium with regard to all the datasets that will be generated
and/or collected by the project consortium.

As SAFE STRIP is a H2020 funded project the Data Management Plan (DMP) must at
least cover the specific aspects about project’s datasets. Particularly, in
accordance to the EC DMP guidelines and template1, describes the data
management life cycle for all datasets to be collected, processed or generated
by a research project. It must cover:

  * the handling of research data during & after the project 

  

  * what data will be collected, processed or generated 

  

  * what methodology & standards will be applied  whether data will be shared /made open access & how  how data will be curated & preserved. 

  

The DMP plays a crucial role in project’s success for two main reasons. On the
one hand, it ensures the availability and the quality of the datasets, which
will be used/produced in the technical Work Packages of the project (WP2-WP6),
serving the achievement of project’s objectives. On the other hand, it
provides a thorough elaboration of the state of all datasets and corresponding
software, proving that they are assessable and useable by third parties.

**1.3 Intended audience**

The SAFE STRIP project addresses highly innovative concepts. As such, foreseen
intended audience of the project is the scientific community in the areas of
intelligent transport systems, with emphasis on wireless communications, road
safety, and automotive engineering. 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.

**1.4 Interrelations**

This deliverable is directly related to project activity _A2.4-Data Modelling
and Fusion_ , which defines the data models and protocols for all data to be
exchanged among system modules, during the project lifecycle. Furthermore,
project activities _A1.3-Use cases and application scenarios_ and
_A2.2-Sensors specifications_ , provide the necessary input for the
specification of the various data types and models that are concerned in the
project. In particular, from the use cases and applications defined in A1.3,
we derive the types of data associated to each application, whereas A2.2
provides insight about the data to be collected and processes by sensors which
are installed in various locations of the system architectures.

  2. **Data Summary**

  

  

**2.1 Data Collection and Sharing Process**

In line with SAFE STRIP objectives, data collection in SAFE STRIP concerns the
two key following data clusters:

  1. Data that will be generated and exchanged at different communication nodes of the overall system architecture, according to the foreseen use cases. 

  

  2. Additional data that need to be collected, **on top of the above** , during **technical validation activities and Pilots with users in a real-life operational environment** during the project that will allow the meaningful evaluation of the system performance and acceptance as well as the impact assessment to be held (in the context of WP6). Those data can be raw data (the ones of cluster 1 above plus some additional data that need to be collected for evaluation purposes regarding the driving performance upon the warning/notifications provided by the system and, in addition, subjective/qualitative data that will be collected in the context of interviews and focus groups). 

  

  

Both clusters of data will be exhaustively specified in the following version
of the DMP (for M29) upon the outcomes of _D1.2: “SAFE STRIP Use Cases and
application scenarios”_ , _D2.1:_ _“System architecture, sensor
specifications, fabrication, maintenance, installation and security
requirements and Risk Assessment”_ and will be pragmatically verified – before
being reported – after the three first evaluation iterations that will have
been held until M29.

Apart from the above, a set of data has been collected already in the context
of A1.1 surveys and A1.3 workshop – anonymised – that have been used for
recognizing stakeholders’ needs and views on the system use cases and
implementation approach.

In the remaining section we present the various data categories of the
aforementioned data clusters. Where applicable, we provide the full details
that describe the data model for each category, i.e. data structure and data
type of each element. It is expected that the full details for all SAFE STRIP
data categories will be defined in the context of the activities _A2.2-Sensors
specifications_ and _A2.4-Data Modelling and Fusion_ and will be included in
the next updated version of this deliverable ( _D2.3SAFE STRIP Final Data
Management Plan_ ) on M29.

  2. **V2I & V2V Exchanged Messages **

  

  

The types of the exchanged I2V and V2V messages can be classified into:

  * **Decentralized Environmental Notification Messages** 2 

  

(DENMs – ETSI EN 302 637-3)

  * **Cooperative Awareness Messages** 3 

  

(CAMs - ETSI EN 302 637-2)

DENMs contain information related to an event that has potential impact on
road safety and are triggered by an event occurrence (event-triggered
messages). On the other hand, CAMs inform road users and roadside
infrastructure about each other’s position, dynamics and attributes. This is
achieved by periodically exchange of information among vehicles (V2V) and
between vehicles and road side infrastructure (V2I). The data associated with
the aforementioned types is presented in the remaining sections.

**2.2.1 Decentralized Environmental Notification Messages**

In our application the DENMs, which are exchanged between Road-Side-Unit (RSU)
and Vehicles, are providing information related to road wear and road
conditions based on a number of sensors data. DENMs, which are event-based
messages, are giving specific information about the event such as **Event
Type** , **Event Location** , **Transmission Area** , **Event Duration** and
are constructed by the Data Elements DE (contain one single data) & Data
Frames DF (contain more than one data element in a predefined order) described
in the clause below. The general structure of a DENM is depicted at the
following figure.

Each container is composed of a sequence of data elements (DE) and/or data
frames (DF). A DE and a DF is either optional or mandatory.

  * ITS PDU Header 

  

  * Management Container o _actionID_ o _detectionTime_ o _referenceTime_ o _termination_ o _eventPosition_ o _relevanceDistance_ o _relevanceTrafficDirection_ o _transmissionInterval_ o _station type_

  

  * Situation Container o _informationQuality_ o _eventType_

    * _causeCode_

  

    * _subCauseCode_ o _linkedCause_ o _eventHistory_

  

  

  * Location Container o _EventSpeed_ o _EventPositionHeading_ o _Traces_ o _roadType_

  

  * A la carte Container o _LanePosition_

    * _ImpactReduction_ o _ExternalTemperature_

  

    * _RoadWorks_

  

    * _PositioningSolution_ o _stationaryVehicle_

  

  

Each of these DE &DF belongs to one of the following categories4:

  * **Vehicle information:** the DE or DF describes one or a set of in vehicle data. 

  

  * **GeoReference information:** the DE or DF provides geographical description of the data. 

  

  * **Road topology information:** the DE or DF describes one or a set of road topology information. 

  

  * **Traffic information:** the DE or DF describes one or a set of road traffic information. 

  

  * **Infrastructure information:** the DE or DF describes one or a set of ITS infrastructure information. 

  

  * **Personal information:** the DE or DF describes one or a set of ITS personal information. 

  

  * **Communication information:** the DE or DF describes one or a set of data that are relevant to the ITS application layer or ITS facilities layer communication protocol. 

  

  * **Other information:** the DE or DF that does not belong to any of the above categories. 

  

The Data Elements DE & Data Frames DF, which are described below, are giving
information related to **ITS PDU Header** 4 **(** Figure 1 **)**

  * **DF_ItsPduHeader (DataType_ 114) – Communication Information**

  

**Category** o Common message header for application and facilities layer
messages. It is included at the beginning of an ITS message as the message
header. The DF shall include the following information:

  * **protocolVersion:** version of the ITS message and/or communication protocol 

  

  * **messageID:** Type of the ITS message: 

    * denm(1): Decentralized Environmental Notification 

  

  

Message (DENM) as specified in ETSI EN 302 637-3

[i.3]

  * cam(2): Cooperative Awareness Message (CAM) as specified in ETSI EN 302 637-2 [i.2] 

  

  * poi(3): Point of Interest message as specified in ETSI TS 101 556-1 [i.11] 

  

  * spat(4): Signal Phase And Timing (SPAT) message as specified in SAE J2735 [i.12] 

  

  * map(5): MAP message as specified in SAE J2735 [i.12] 

  

  * ivi(6): In Vehicle Information (IVI) message as defined in ISO TS 19321 [i.13] 

  

  * ev-rsr(7): Electric vehicle recharging spot reservation message, as defined in ETSI TS 101 556-3 [i.14] 

  

▪ **stationID:** the identifier of the ITS-S that generates the ITS message in
question. It shall be represented as specified hereafter (DataType 77).

  * **DE_StationID (DataType_ 77) - Communication Information Category** o Identifier for an ITS-S (Intelligent Transport Systems Station). The ITS-S ID may be a pseudonym. It may change over space and/or over time. 

  

o Integer value which ranges from 0 to 4294967295

The Data Elements DE & Data Frames DF, which are described below, are giving
information related to **Management Container (** Figure 1 **)** .

  * **DF_ActionID (DataType_ 102) - Communication Information Category** o Identifier used to describe a protocol action taken by an ITS-S. For example, it describes an action taken by an ITS-S to trigger a new DENM as defined in ETSI EN 302 637-3 [i.3] after detecting an event. 

  

The DF shall include a sequence of the following data:

  * **originatingStationID:** ID of the ITS-S that takes the action. It shall be presented as defined in _**DE_StationID** _

  

  * **sequenceNumber:** a sequence number. It shall be presented as defined in _**DE_SequenceNumber** . _

  

  * **DE_SequenceNumber (DataType_ 68) - Other Information Category** o Sequence number o Integer value which ranges from 0 to 65535. 

  

  * **DE_Timestamplts (DataType_ 82) - Other Information Category** o Number of milliseconds since 2004-01-01T00:00:00.000Z, as specified in ISO 8601 [i.10]. 

  

EXAMPLE: The value for TimestampIts for 2007-01-01T00:00:00.000Z is 94 694 401
000 milliseconds, which includes one leap second insertion since
2004-01-01T00:00:00.000Z. It should range from 0 to 4398046511103\.

  * (0) if utcStartOf2004 

  

  * (1 )oneMillisecAfterUTCStartOf2004 

  

  * **DF_ReferencePosition (DataType_ 124) – GeoReference Information**

  

**Category** o The geographical position of a position or of an ITS-S. It
represents a geographical point position. The DF shall include a sequence of
the following information:

  * **latitude** : latitude of the geographical point 

  

  * **longitude** : longitude of the geographical point 

  

  * **positionConfidenceEllipse** : accuracy of the geographical position 

  

  * **altitude** : altitude and altitude accuracy of the geographical point 

  

  * **DF_Latitude (DataType_ 41) – GeoReference Information Category**

    * Absolute geographical latitude in a WGS84 coordinate system, providing a range of 90 degrees in north or in south hemisphere. Positive values are used for latitude in north of the Equator, negative values are used for latitude in south of the Equator. When the information is unavailable, the value shall be set to 900 000 001\. 

  

    * Unit: 0.01 microdegree 

  

  

  * **DF_Longitude (DataType_ 44) - GeoReference Information Category** o Absolute geographical longitude in a WGS84 co-ordinate system, providing a range of 180 degrees to the east or to the west of the prime meridian. Negative values are used for longitudes to the west; positive values are used for longitudes to the east. When the information is unavailable, the value shall be set to 1 800 000 001\. 

  

o Unit: 0.01 microdegree

  * **DF_PosConfidenceEllipse (DataType_ 119) - GeoReference Information**

  

**Category** o DF that provides the horizontal position accuracy in a shape of
ellipse with a predefined confidence level (e.g. 95 %). The centre of the
ellipse shape corresponds to the reference position point for which the
position accuracy is evaluated. The DF shall include a sequence of the
following information:

  * **semiMajorConfidence** : half of length of the major axis, i.e. distance between the centre point and major axis point of the position accuracy ellipse ( _**DE_SemiAxisLength** _ ). 

  

  * **semiMinorConfidence** : half of length of the minor axis, i.e. distance between the centre point and minor axis point of the position accuracy ellipse ( _**DE_SemiAxisLength** _ ). 

  

  * **semiMajorOrientation** : orientation direction of the ellipse major axis of the position accuracy ellipse with regards to the WGS84 north ( _**DE_HeadingValue** _ ). 

  

  * **DE_SemiAxisLength (DataType_67) - GeoReference Information**

  

**Category** o Absolute position accuracy in one of the axis direction as
defined in a shape of ellipse with a predefined confidence level (e.g. 95 %).
The required confidence level is defined by the corresponding standards
applying the DE. The value shall be set to:

  * (1) if the accuracy is equal to or less than 1 cm 

  

  * (n > 1 and n < 4 093) if the accuracy is equal to or less than n cm 

  

  * (4 093) if the accuracy is equal to or less than 4 093 cm 

  

  * (4 094) if the accuracy is out of range, i.e. greater than 4 093 cm 

  

  * (4 095) if the accuracy information is unavailable o Unit: 1 cm. 

  

**NOTE** : The fact that a position coordinate value is received with
confidence set to 'unavailable(4095)' can be caused by several reasons, such
as:

  * the sensor cannot deliver the accuracy at the defined confidence level because it is a low-end sensor, 

  

  * the sensor cannot calculate the accuracy due to lack of variables, or o there has been a vehicle bus (e.g. CAN bus) error. 

  

In all 3 cases above, the reported position coordinate value may be valid and
used by the application.

If a position coordinate value is received and its confidence is set to
'outOfRange(4094)', it means that the reported position coordinate value is
not valid and therefore cannot be trusted. Such value is not useful for the
application.

  * **DE_HeadingValue (DataType_35) – GeoReference, Vehicle & Road **

  

**Topology Information Category** o Orientation of a heading with regards to
the WGS84 north.

  * wgs84North(0) 

  

  * wgs84East(900) 

  

  * wgs84South(1800) 

  

  * wgs84West(2700) 

  

  * unavailable(3601) o Unit: 0.01 degree. 

  

  * **DF_Altitude (DataType_ 103) - GeoReference Information Category** o Altitude and accuracy of an altitude in a WGS84 co-ordinate system. 

  

The DF shall include a sequence of the following information:

  * **altitudeValue** : altitude of a geographical point. 

  

  * **altitudeConfidence** : accuracy of the reported altitudeValue within a specific confidence level. 

  

  * **DF_AltitudeValue (DataType_ 9) - GeoReference Information Category** o Altitude in a WGS84 co-ordinate system. When the information is not available, the DE shall be set to 800 001. For altitude equal or greater than 8 000 m, the DE shall be set to 800 000. For altitude equal or less than -1 000 m, the DE shall be set to -100 000\. 

  

o Unit: 0.01 metre

  * **DE_AltitudeConfidence (DataType_8) - GeoReference Information**

  

**Category** o Absolute accuracy of a reported altitude value of a
geographical point for a predefined confidence level (e.g. 95 %). The required
confidence level is defined by the corresponding standards applying the usage
of this DE. The value shall be set to:

  * 0 if the altitude accuracy =< 0.01 metre 

  

  * 1 if the altitude accuracy =< 0.02 metre 

  

  * 2 if the altitude accuracy =< 0.05 metre 

  

  * 3 if the altitude accuracy =< 0.1 metre 

  

  * 4 if the altitude accuracy =< 0.2 metre 

  

  * 5 if the altitude accuracy =< 0.5 metre 

  

  * 6 if the altitude accuracy =< 1 metre 

  

  * 7 if the altitude accuracy =< 2 metres 

  

  * 8 if the altitude accuracy =< 5 metres 

  

  * 9 if the altitude accuracy =< 10 metres 

  

  * 10 if the altitude accuracy =< 20 metres 

  

  * 11 if the altitude accuracy =< 50 metres 

  

  * 12 if the altitude accuracy =< 100 metres 

  

  * 13 if the altitude accuracy =< 200 metres 

  

  * 14 if the altitude accuracy is out of range, i.e. greater than 200 metres 

  

  * 15 if the altitude accuracy information is unavailable 

  

**NOTE** : The fact that an altitude value is received with confidence set to
'unavailable(15)' can be caused by several reasons, such as:

  * the sensor cannot deliver the accuracy at the defined confidence level because it is a low-end sensor, 

  

  * the sensor cannot calculate the accuracy due to lack of variables, or o there has been a vehicle bus (e.g. CAN bus) error. 

  

In all 3 cases above, the reported altitude value may be valid and used by the
application.

If an altitude value is received and its confidence is set to
'outOfRange(14)', it means that the reported altitude value is not valid and
therefore cannot be trusted. Such value is not useful for the application.

  * **DE_RelevanceDistance (DataType_ 61) - GeoReference Information**

  

**Category** o DE describing a distance of relevance for information indicated
in a message, for example, it may be used to describe the distance of
relevance of an event indicated in a DENM as defined in ETSI EN 302 637-3
[i.3]. The value shall be set to:

  * 0 if relevance distance < 50 m 

  

  * 1 if relevance distance < 100 m 

  

  * 2 if relevance distance < 200 m 

  

  * 3 if relevance distance < 500 m 

  

  * 4 if relevance distance < 1000 m 

  

  * 5 if relevance distance < 5 km 

  

  * 6 if relevance distance < 10 km 

  

  * 7 if relevance distance > 10 km 

  

  * **DE_RelevanceTrafficDirection (DataType_ 62) - GeoReference**

  

**Information Category** o DE describing a traffic direction that is relevant
to information indicated in a message. For example, it may be used to describe
traffic direction which is relevant to an event indicated by a DENM as defined
in ETSI EN 302 637-3 [i.3], The terms "upstream",

"downstream" and "oppositeTraffic" are relative to the event position.

The value shall be set to:

  * 0 if allTrafficDirections 

  

  * 1 if upstreamTraffic 

  

  * 2 if downstreamTraffic 

  

  * 3 if oppositeTraffic(3) 

  

o The terms "upstream", "downstream" and "oppositeTraffic" are relative to the
event position

  * **DE_ValidityDuration (DataType_ 88) - Traffic Information Category** o At the end of this validity duration, the event is regarded as terminated. 

  

All information related to it may be deleted.

o Unit: Second (It could range from 0 to 86400)

  * **DE_TransmissionInterval (DataType_ 86) - Communication Information**

  

**Category** o Time interval between two consecutive message transmissions.

o Unit: Millisecond

  * **DE_StationType (DataType_78) - Other Information Category** o The type of an ITS-S. The station type depends on the integration environment of ITS-S into vehicle, mobile devices or at infrastructure. 

  

(0 … 255)

  * unknown(0) 

  

  * pedestrian(1) 

  

  * cyclist(2) 

  

  * moped(3) 

  

  * motorcycle(4) 

  

  * passengerCar(5) 

  

  * bus(6) 

  

  * lightTruck(7) 

  

  * heavyTruck(8) 

  

  * trailer(9) 

  

  * specialVehicles(10) 

  

  * tram(11) 

  

  * roadSideUnit(15) 

  

The Data Elements DE & Data Frames DF, which are described below, are giving
information related to **Situation Container (** Figure 1 **)** .

  * **DE_InformationQuality (DataType_39) - Other Information Category** Quality level of provided information (0 … 7) o Unavailable (0) o Lowest (1) 

  

o Highest (7)

  * **DF_CauseCode (DataType_104) - Traffic Information Category** o Encoded value of a traffic event type. The DF shall include the following information: 

    * causeCode: the type of a direct cause of a detected event. It shall be presented as defined in _**CauseCodeType** _

  

    * subCauseCode: sub type of the direct cause. It shall be presented as defined in _**SubCauseCodeType.** _

  

  

The values of causeCodeType and subCauseCode are defined in clause 7.1.4 of
ETSI EN 302 637-3 [i.3].

  * **DE_CauseCodeType (DataType_ 10) - Traffic Information Category** o Value of the direct cause code of a detected event. The Cause Codes are described as following: 

    * adverseWeatherCondition-Adhesion ( **Direct Cause Code** 🡪 

  

  

6): the type of event is low adhesion

  * adverseWeatherCondition-ExtremeWeatherCondition ( **Direct Cause Code** 🡪 17): the type of event is extreme weather condition 

  

  * adverseWeatherCondition-Precipitation ( **Direct Cause Code** 🡪 19): the type of event is precipitation 

  

  * adverseWeatherCondition-Visibility ( **Direct Cause Code** 🡪 

  

18): the type of event is low visibility

  * hazardousLocation-SurfaceCondition ( **Direct Cause Code** 🡪 9): the type of event is abnormal road surface condition 

  

  * roadworks ( **Direct Cause Code** 🡪 3): the type of the event is roadwork 

  

  * **DE_SubCauseCodeType (DataType_ 81) - Traffic Information Category** o Type of **Sub Cause** of a detected event as defined in ETSI EN 302 

  

637-3 [i.3]” **.**

  * **DE_AdverseWeatherCondition – AdhensionSubCauseCode (DataType_ 4) - Traffic Information Category** Low Road Adhension is due to: 

    * unavailable (Sub Causes Code 🡪 0) o heavy frost on the road (Sub Causes Code 🡪 1) o fuel on the road (Sub Causes Code 🡪 2) o mud on the road (Sub Causes Code 🡪 3) o snow on the road (Sub Causes Code 🡪 4) o ice on the road (Sub Causes Code 🡪 5) o black ice on the road (Sub Causes Code 🡪 6) o oil on the road (Sub Causes Code 🡪 7) o loose gravel or stone fragments detached from a road surface or from a hazard (Sub Causes Code 🡪 8) o instant black ice on the road surface (Sub Causes Code 🡪 9) 

  

    * salted road (Sub Causes Code 🡪 10) 

  

  

  * **DE_AdverseWeatherCondition –**

  

**ExtremeWeatherConditionSubCauseCode (DataType_ 5) - Traffic Information
Category**

Extreme Weather Condition is:

o unavailable (Sub Causes Code 🡪 0) o strong wind (Sub Causes Code 🡪 1) o
damaging hail (Sub Causes Code 🡪 2) o hurricane (Sub Causes Code 🡪 3) o
thunderstorm (Sub Causes Code 🡪 4) o tornado (Sub Causes Code 🡪 5) o blizzard
(Sub Causes Code 🡪 6)  **DE_AdverseWeatherCondition –
PrecipitationSubCauseCode**

**(DataType_ 6) - Traffic Information Category** Precipitation is:  
  
<table>  
<tr>  
<th>

o unavailable

</th>  
<th>

(Sub Causes Code 🡪 0)

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

o heavy rain

</td>  
<td>

(Sub Causes Code 🡪 1)

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

o heavy snow fall

</td>  
<td>

(Sub Causes Code 🡪 2)

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

o soft hail

</td>  
<td>

(Sub Causes Code 🡪 3)

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

  * **DE_AdverseWeatherCondition – VisibilitySubCauseCode (DataType_ 7) - Traffic Information Category** Low visibility due to: 

  

o unavailable (Sub Causes Code 🡪 0) o fog (Sub Causes Code 🡪 1) o smoke (Sub
Causes Code 🡪 2) o heavy snow fall (Sub Causes Code 🡪 3) o heavy rain (Sub
Causes Code 🡪 4) o heavy hail (Sub Causes Code 🡪 5) o sun glare (Sub Causes
Code 🡪 6) o sand storm (Sub Causes Code 🡪 7)

  * **DE_HazardousLocation – SurfaceConditionSubCauseCode (DataType_ 33) - Traffic Information Category** Hazardous Location in case: 

  

o unavailable further detailed information of the road surface condition

(Sub Causes Code 🡪 0) o the road surface is damaged by earthquake (Sub Causes
Code 🡪 2) o road surface is damaged by subsidence (Sub Causes Code 🡪 4) o road
surface is damaged due to snow drift (Sub Causes Code 🡪 5) o road surface is
damaged by strong storm (Sub Causes Code 🡪 6) o road surface is damaged due to
pipe burst (Sub Causes Code 🡪 7) o road surface damage is due to falling ice
(Sub Causes Code 🡪 9)

The sensors can be connected to On-Road-Unit (ORU) and/or Road-Side-Unit (RSU)
and can provide information about the Temperature, Humidity, Barometric Air
Pressure, Wind Direction & Speed, Precipitation Quantity, Solar Radiation,
Chemicals Detection (e.g. oil) on Road and Road Wear (string gauges)5  ,  6\.

The Data Elements DE & Data Frames DF, which are described below, are giving
information related to **A la Carte Container (** Figure 1 **)** .

  * **DE_Temperature (DataType_ 83) - Other Information Category** o Temperature. For temperature equal to or less than -60 °C, the value shall be set to -60. For temperature equal to or greater than 67 °C, the value shall be set to 67. 

    * equalOrSmallerThanMinus60Deg (-60) 

  

    * oneDegreeCelsius(1) 

  

    * equalOrGreaterThan67Deg (67) o Unit: Degree Celsius (It could range from -60 to 67)  **DE_RoadworksSubCauseCode (DataType_ 66) ) - Traffic Information Category**

  

  

RoadWork Type:

o unavailable further detailed information on roadworks

(Sub Causes Code 🡪 0) o a major roadworks is ongoing (Sub Causes Code 🡪 1) o a
road marking work is ongoing (Sub Causes Code 🡪 2) o slow moving road
maintenance work is ongoing (Sub Causes Code 🡪

3) o a short term stationary roadwork is ongoing (Sub Causes Code 🡪 4) o a
vehicle street cleaning work is ongoing (Sub Causes Code 🡪 5) o winter service
work is ongoing (Sub Causes Code 🡪 6)

Table 1 shows an example of DENM message with RoadWorks cause-code selected.

Table 1: Example of DENM generated by a roadside unit.  
  
<table>  
<tr>  
<th>

ETSI ITS (DENM)

DENM

header

protocolVersion: currentVersion (1) messageID: denm (1)

stationID: 2 denm management actionID originatingStationID: 148
sequenceNumber: 33 detectionTime: 2158628750 (2158628.750 s) referenceTime:
2158628750 (2158628.750 s) eventPosition latitude: (45.8510750 deg) longitude:
(11.0006270 deg) positionConfidenceEllipse semiMajorConfidence: unavailable
(4095) semiMinorConfidence: unavailable (4095) semiMajorOrientation:
unavailable (3601) altitude

altitudeValue: (800.00 m)

altitudeConfidence: unavailable (15) relevanceDistance: lessThan500m (3)

relevanceTrafficDirection: allTrafficDirections (0) validityDuration: Unknown
(60 sec) stationType: roadSideUnit (15) situation informationQuality: lowest
(1) eventType

causeCode: roadworks (3) subCauseCode: 0

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

**2.2.2 Cooperative Awareness Messages**

Cooperative awareness within road users means that vehicles and infrastructure
become aware of each other’s presence thanks to periodic messages containing
each other’s position, dynamics and attributes. The information to be
exchanged is packed up in the periodically transmitted Cooperative Awareness
Message (CAM) whose construction, management and processing is part of the ITS
Communication architecture ETSI EN 302 6657\. The requirements on the
performance of the CAM and the quality of its data elements are derived from
the Basic Set of Applications (BSA) defined in ETSI TR 102 6388. Figure 2
shows the general structure of a CAM message.

Each container consists of a sequence of DE and DF similarly to DENM. Here is
a description of typical containers:

  * ITS PDU Header 

  

  * Basic Container o stationType o referencePosition 

    * latitude 

  

    * longitude 

  

    * positionConfidenceEllipse 

  

    * altitude 

  

  

  * High Frequency Container o Basic Vehicle Container HF 

    * heading 

  

    * speed 

  

    * driveDirection 

  

    * vehicleLength 

  

    * vehicleWidth 

  

    * longitudinalAcceleration 

  

    * curvature 

  

    * yawRate OR 

  

  

o Basic RSU Container HF o Protected Communication Zone

  * protectedZoneType 

  

  * protecetedZoneLatitude 

  

  * protectedZoneLongitude 

  

  * protectedZoneRadius 

  

  * Low Frequency Container o vehicleRole o exteriorLights o pathHistory 

    * ItemX: deltaLatitude 

  

    * ItemX: deltaLongitude 

  

    * ItemX: deltaAltitude 

  

  

The content of CAM varies from the type of ITS-S station. In SAFE STRIP two
types of stations will be used to identify the presence of equipped vehicles.
The CAM messages will be used to notify the vehicle that it is approaching a
location with equipped infrastructure and vice versa the vehicles will send a
notification to the infrastructure about their presence. Table 2 shows the
implementation of two CAM messages from a vehicle and a roadside unit.

Table 2: Example of CAM generated by: (a) a vehicle, (b) a road-side unit.  
  
<table>  
<tr>  
<th>

ETSI ITS (CAM)

CAM

header

protocolVersion: currentVersion (1) messageID: cam (2) stationID: 200 cam

generationDeltaTime: 30204 camParameters basicContainer

stationType: passengerCar (5) referencePosition

latitude: (45.8501000 deg)

longitude: Unknown (11.0012658 deg) positionConfidenceEllipse

semiMajorConfidence: (12.00 m) semiMinorConfidence: (11.50 m)

semiMajorOrientation: (36.01 deg) altitude

altitudeValue: (173.60 m)

altitudeConfidence: unavailable (15)

highFrequencyContainer: basicVehicleContainerHighFrequency (0)
basicVehicleContainerHighFrequency heading headingValue: (129.7 deg)
headingConfidence: (1) speed

speedValue: (20.50 m/s, 73.80 km/h)

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

speedConfidence: (0.16 m/s) driveDirection: unavailable (2) vehicleLength

vehicleLengthValue: (3.8 m)

vehicleLengthConfidenceIndication: noTrailerPresent (0) vehicleWidth: (2.0 m)
longitudinalAcceleration

longitudinalAccelerationValue: (1.61) longitudinalAccelerationConfidence:
(1.02) curvature

curvatureValue: straight (0)

curvatureConfidence: unavailable (7)

curvatureCalculationMode: yawRateUsed (0) yawRate yawRateValue: straight (0.00
deg/sec) yawRateConfidence: unavailable (8) lowFrequencyContainer:
basicVehicleContainerLowFrequency vehicleRole: specialTransport (2)
exteriorLights: 12 [0001 0010]

pathHistory: 1 item

Item 0

PathPoint pathPosition deltaLatitude: (0.0000003 deg) deltaLongitude:
(0.0000002 deg) deltaAltitude: (0.01 m)

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

(a)

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

ETSI ITS (CAM)

CAM

header

protocolVersion: currentVersion (1) messageID: cam (2)

stationID: 2 cam

generationDeltaTime: (35748) camParameters basicContainer

stationType: roadSideUnit (15) referencePosition latitude: (45.8510750 deg)
longitude: (11.0006270 deg) positionConfidenceEllipse

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

semiMajorConfidence: unavailable (4095) semiMinorConfidence: unavailable
(4095) semiMajorOrientation: unavailable (3601) altitude

altitudeValue: unavailable (800001) altitudeConfidence: unavailable (15)

highFrequencyContainer: rsuContainerHighFrequency (1)
rsuContainerHighFrequency

protectedCommunicationZonesRSU: 1 item

Item 0

ProtectedCommunicationZone protectedZoneType: cenDsrcTolling (0)
protectedZoneLatitude: (45.8510750 deg) protectedZoneLongitude: (11.0006270
deg) protectedZoneRadius: (300)

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

(b)

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

The data content transmitted from the two stations is different: the vehicles
are moving objects, therefore it is necessary to spread information about
vehicle dynamics. On the contrary, RSUs are characterized by static
coordinates and protected areas. For the same reason vehicles send CAMs and
DENMs at higher rates as opposed to roadside units: typically the vehicles
transmit 10[mex/s] while roadside units sends out CAM messages at 1[Hz]. In
ETSI EN 302 637-23 the mandatory fields are defined, such as the input source
of the message and the proper operation of the Cooperative Awareness service.
Here the most relevant containers from SAFE STRIP perspective are reported.

The Data Elements DE & Data Frames DF, which are described below, provide
information related to **ITS PDU Header**

  * **DF_ItsPduHeader (DataType_ 114) – Communication Information**

  

**Category** o ITS PDU header of the CAM, it’s composed by three containers:

  * **protocolVersion** version of the ITS message and/or communication protocol; 

  

  * **messageID** Type of the ITS message. Following message type values are assigned in the present document: denm(1): Decentralized Environmental Notification Message, cam(2): Cooperative Awareness Message, poi(3): Point of Interest message, spat(4): Signal Phase And Timing (SPAT) message, map(5): MAP message, ivi(6): In Vehicle Information (IVI) message and ev-rsr(7): Electric vehicle recharging spot reservation message; **stationID:** the identifier of the ITS-S that generates the ITS message in question. It shall be represented as specified hereafter (DataType 77). 

  

Generation Delta Time is a container described in ETSI EN 302 637-2, it is not
included into ITS-PDU Header, nor into High Frequency Container, but it is
mandatory to evaluate the time validity.

  * **generationDeltaTime** this is the reference time of the CAM, considered as time of the CAM generation. It shall be used as time basis for application with predefined time validity. 

  

The following DF and DE comprise information of the Basic container, which
provides basic information of the originating ITS-station.

  * **DE_StationType (DataType_78) - Other Information Category** o The type of an ITS-S: unknown, pedestrian, cyclist, moped, motorcycle, passengerCar, bus, lightTruck, heavyTruck, trailer, specialVehicles, tram, roadSideUnit. 

  

  * **DF_referencePosition (DataType_124) - GeoReference Information**

  

**Category** o Position at the reference point of the originating ITS-S. The
measurement time shall correspond to generationDeltaTime. This parameter shall
be used to locate the vehicle and roadside units into absolute coordinate
system. The DF shall include a sequence of the following information:

  * latitude: latitude of the geographical point, 

  

  * longitude: longitude of the geographical point, 

  

  * positionConfidenceEllipse accuracy of the geographical position, 

  

  * altitude: altitude and altitude accuracy of the geographical point. 

  

  * **DF_PosConfidenceEllipse (DataType_119) - GeoReference Information**

  

**Category** o positionConfidenceEllipse provides the accuracy of the measured
position with the 95 % confidence level. The DF shall include a sequence of
the following information:

  * semiMajorConfidence: half of length of the major axis, i.e. distance between the centre point and major axis point of the position accuracy ellipse, 

  

  * semiMinorConfidence: half of length of the minor axis, i.e. distance between the centre point and minor axis point of the position accuracy ellipse, 

  

  * semiMajorOrientation: orientation direction of the ellipse major axis of the position accuracy ellipse with regards to the WGS84 north. 

  

The following DF and DE comprise information of the high Frequency Container,
which contains the high frequency signals of the vehicle or roadside units. An
example of DF and DE includes car acceleration, speed and yaw rate. Thanks to
this information the following scenario could be realised: the infrastructure
and a vehicle can determine if a user is properly approaching an intersection,
or any other obstacle. On the contrary, the roadside units could disseminate
as high frequency container the position of a CEN DSRC Tolling Station.

  * **DF_Heading (DataType_112) – GeoReference, Vehicle & Road Topology **

  

**Information Category** o Heading in a WGS84 co-ordinates system. The DF
shall include a sequence of the following information:

  * headingValue: a heading value, 

  

  * headingConfidence: the accuracy of the reported heading value with a predefined confidence level. 

  

  * **DF_Speed (DataType_126) - Vehicle Information Category** o It describes the speed and corresponding accuracy of the speed information for a moving object (e.g. vehicle). The DF shall include the a sequence of the following information: 

    * speedValue, 

  

    * speedConfidence: accuracy of the reported speed value. 

  

  

  * **DE_DriveDirection (DataType_22) - Vehicle Information Category** o It denotes whether a vehicle is driving forward or backward. 

  

  * **DF_vehicleLength (DataType_131) - Vehicle Information Category** o Length of vehicle and accuracy indication information. The DF shall include a sequence of the following information: 

    * vehicleLengthValue: length of vehicle, 

  

    * vehicleLengthConfidenceIndication: indication of reported length value confidence 

  

  

  * **DE_VehicleWidth (DataType_95) - Vehicle Information Categor** o Width of a vehicle, including side mirrors. 

  

  * **DF_LongitudinalAcceleration (DataType_129) - GeoReference**

  

**Information Category** o It indicates the vehicle acceleration at
longitudinal direction and the accuracy of the longitudinal acceleration.

The DF shall include a sequence of the following information:

  * longitudinalAccelerationValue: longitudinal acceleration value at a point in time, 

  

  * longitudinalAccelerationConfidence: accuracy of the reported longitudinal acceleration value with a predefined confidence level. 

  

  * **DF_Curvature (DataType_107) - Vehicle Information Category** o It describes the curvature of the vehicle trajectory and the accuracy. The curvature detected by a vehicle represents the curvature of actual vehicle trajectory. The DF shall include a sequence of the following information: 

    * curvatureValue: detected curvature of the vehicle trajectory, 

  

    * curvatureConfidence: accuracy of the reported curvature value with a predefined confidence level. 

  

  

  * **DE_CurvatureCalculationMode (DataType_13) - Vehicle Information**

  

**Category** o It describes whether the yaw rate is used to calculate the
curvature for a reported curvature value.

  * **DF_YawRate (DataType_132) - Vehicle Information Category** o Yaw rate of vehicle at a point in time. The DF shall include a sequence of the following information: 

    * yawRateValue: yaw rate value at a point in time, 

  

    * vehicleLengthConfidenceIndication: accuracy of reported yaw rate value. 

  

  

The following DF and DE comprise information of the low Frequency Container,
which contains information changing with more relaxed dynamics, such as the
exterior-lights, or the vehicle role. This information allows the user to
react to different type of operations: public transport, roadwork vehicles
etc.

  * **DE_VehicleRole (DataType_94) - Vehicle Information Category** o Role played by a vehicle at a point in time: default, publicTransport, specialTransport, dangerousGoods, roadWork, rescue, emergency, safetyCar, agriculture, commercial, military, roadOperator, taxi. 

  

  * **DE_ExteriorLights (DataType_28) - Vehicle Information Category** o This DE describes the status of the exterior light switches of a vehicle. 

  

  * **DF_ProtectedCommunicationZonesRSU (DataType_122) –**

  

**Infrastructure & Communication Information Category ** o DF that describes a
list of protected communication zones by a road side ITS-S (Road Side Unit
RSU). It may provide up to 16 protected communication zones information. Each
protected communication zone shall be presented as
DF_ProtectedCommunicationZone.

  * **DF_ProtectedCommunicationZone (DataType_121) – Infrastructure & **

  

**Communication Information Category** o DF that describes a zone of
protection inside which the ITSG5 communication should be restricted. It shall
include a sequence of the following information :

  * protectedZoneType: type of the protected zone, 

  

  * expiryTime: (otional) time at which the validity of the protected communication zone will expire, 

  

  * protectedZoneLatitude: latitude of the centre point of the protected communication zone, 

  

  * protectedZoneLongitude: longitude of the centre point of the protected communication zone, 

  

  * protectedZoneRadius: (optional) radius of the protected communication zone in metres, 

  

  * protectedZoneID: (optional) the ID of the protected communication zone. o A protected communication zone may be defined around a CEN DSRC road side equipment 

  

**2.3 TMC Messages**

Standard RDS-TMC user messages provide the following five basic items of
explicit, broadcast information9:

  * **Event description** , giving details of: 

  

o road event situation o general traffic problems o weather situations

In some cases more information about the severity of the event is given. 
**Location** (road segment or point location of event occurrence)

  * **Direction and Extent** , identifying the adjacent segments or specific point locations also affected by the incident, and where appropriate the direction of traffic affected. 

  

  * **Duration** (indication of expected problem duration) 

  

  * **Diversion advice** (showing whether or not end-users are recommended to find and follow an alternative route) 

  

Optional information can be added to any message using one or more additional
RDS data groups. This optional addition can give greater detail or can deal
with unusual situations. Any number of additional fields can in principle be
added to each basic message, subject only to a maximum message length of five
RDS data groups4.

  4. **User model**

  

  

In the context of SAFE STRIP, any user is an entity that has its own data
model. The elements of the User model are shown below.

Table 3: User model in SAFE STRIP  
  
<table>  
<tr>  
<th>

**Field Name**

</th>  
<th>

**Type**

</th>  
<th>

**Required**

</th>  
<th>

**Details**

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

**_id**

</td>  
<td>

objectid

</td>  
<td>

True

</td>  
<td>

Unique id

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

**email**

</td>  
<td>

string

</td>  
<td>

True

</td>  
<td>

Email

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

**password**

</td>  
<td>

string

</td>  
<td>

True

</td>  
<td>

Password

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

**name**

</td>  
<td>

string

</td>  
<td>

True

</td>  
<td>

First/ last name

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

**phone**

</td>  
<td>

string

</td>  
<td>

True

</td>  
<td>

Phone number

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

**fcm_token**

</td>  
<td>

string

</td>  
<td>

True

</td>  
<td>

FireCloud Message token

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

All data related to user personal information will not be open by any means,
but it will be stored according to the SAFE STRIP data privacy policy (Section
6.3).

  5. **Data Collection and Management in Pilots**

  

  

Data management in Pilots will follow the principles below as a minimum, at
each pilot site level. This list will be updated in the next DMP version
(deliverable D2.3):

  * Each Pilot site must ensure the data collection according to the evaluation requirement and with the right accuracy. 

  

  * Each pilot site must provide, in a timely fashion, the requested data to perform test analysis. Data must be provided with its metadata or a complete description. To enable an accurate usage, data must be generated in compliance with evaluation requirements (formats, measurements, etc.) that will be defined in the technical validation and evaluation plans of A5.6 and A6.1 respectively. 

  

  * Each pilot site must provide an easy access to collected data and a secure environment for data storage. 

  

  * Each pilot site needs to have all the necessary tools to check data quality and to read raw data. Automated scripts will be provided to process large dataset in order to ease and enable post-processing of aggregated data, whereas the logging of the raw data will be pre-defined in a homogeneous way for all types of them. 

  

The data that will be collected during technical validation and user trials
activities are as follows:

  * Subjective anonymised data from users (drivers) and other stakeholders (i.e. TMC operators) – collected at **pilot site level** related to system evaluation and acceptance. Indicative list of evaluation indicators to be collected is as follows (list is not exhaustive – will be finalized in technical and pilot evaluation plans): usage, user satisfaction, user compliance (following the system’s advice), user acceptance (perceived/rated by users), usability ratings (perceived by users), system efficiency rates, willingness to have and use the system. 

  

  * Driving performance data from drivers/riders that will be logged during trials in the logging mechanisms installed in the vehicles and the mobile devices **– collected at pilot site level, but in an homogeneous way and upon common protocols,** related with speed, lateral deviation, safety headway, acceleration/deceleration, lane merging and overtaking, etc. 

  

  * **Data from sensors** . This includes the data that will be collected by the various sensors, e.g. road sensors for _humidity_ , _temperature_ , _oil_ _detection_ , _road wear_ , as well as tyre sensors for _friction_ , RFID sensors for _parking slots_ , _car position_ , _speed limit_ , etc. This data will be collected by the hardware sensors and will be stored in the cloud via the SAFE STRIP communication modules (i.e., through LTE), according to the data model defined in Section 2.2. In particular, for parking slots and relevant information, the SAFE STRIP data model will be compatible with the ETSI TR 102 638 standard8. For any data element that no reference to the existing standards occurs (e.g. _vehicle_ _lane position_ for autonomous vehicles) _,_ the project will propose a new data model to be potentially included in the existing standards. 

  

  * **TMC messages** , as the ones shown in section 2.3. Storage of those messages will be done centrally, by the means of the OMNIA cloud repository (provided by SWARCO). Hence, the corresponding data model will adhere to the one supported by the OMNIA Web API. Only data that do not confront any IPR related issues will be available as open data. A final decision about this will be made in the context of activity A2.4 and be included in the next version of the DMP. Access to all data of the OMNIA repository will be done in an authenticated manner. 

  

  * **Vehicle position** received from the GPS device **.** This can be stored in the cloud in an anonymised format **,** according to the data model defined in Section 

  

2.2 (“event position”).

The final definition of the data, the way and place they will be logged will
be defined in _D5.4-Test sites set-up and experimental technical validation
plan_ , _D5.5-Updated experimental technical validation plan and results –
final report_ , D6.1- _Initial report on Pilot framework and plans_ and
_D6.2-Final report on Pilot framework and plans_ , and will be also presented
in the next version of DMP (deliverable D2.3). All test sites participating in
either the technical and/or user-based evaluation of the system are obliged to
follow the common plans, where the experiments will be defined in detail. In
specific, the validation plans, starting from Key Performance Indicators that
will be set, will 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, traffic context, etc.) together with the validation
approaches and data collection tools (questionnaires, user surveys protocols,
logging mechanisms on different ends – e.g., the vehicle, mobile phone, the
cloud, or other) that will be used to store all types of data in need in an
appropriate and consistent manner and format (in order to allow aggregated and
crosssite post processing).

Additional requirements related to ORDP are defined in section 4 to guarantee
that the collected data will be provided in compliance to European Commission
Guidelines1 on Data Management in Horizon 2020.

**2.6 Data Flow in SAFE STRIP Test Environment**

The test data management process carried out by activity A3.4 will define the
architecture that enables the implementation of the data collection processes
in all SAFE STRIP modules. Data generated during SAFE STRIP system operation
will be stored in the long term in a cloud repository, as data storage at the
local infrastructure will be volatile due to the limited capabilities of those
devices and their low energy requirements. However, interconnection is
foreseen to the OMNIA platform provided by SWARCO, which is also built upon a
cloud architecture. OMNIA can be seen as a gateway to TMC data, hence access
to this data will be performed in an authenticated manner via the OMNIA Rest
web API. It is not yet clear of the OMNAI platform will provide all required
resources for hosting the SAFE STRIP cloud or only part of it, as at the time
of this writing the system architecture (activity A2.1) is not yet finished.
The test data management process will focus on services that will be deployed
on the Pilot Site Test Servers and that will comprise the central SAFE STRIP
cloud. Special care will be given so that for each specific pilot site test a
dedicated VM will collect and store all the data created by the pilot site.
Figure 3 shows the data flow in the SAFE STRIP test environment. Finally, the
aggregated and validated data will be fed into the SAFE Decision Support for
posting the warning message to the drivers.

**Sensor data**

**(**

**Road**

**,**

**Parking slots**

**,**

**etc**

**.)**

**Pilot site VM**

**OMNIA cloud**

**(**

**TMC data**

**)**

**Decision Support**

**System**

**Pilot site specific data sources**

**(**

**mobile phone**

**,**

**static data**

**,**

**user**

**questionnaires**

**)**

**Data Aggregation**

**Data import**

**/**

**export**

**SAFE STRIP Cloud**

**Data enrichment**

**User feedback**

**Data Fusion**

  3. **FAIR Data Principles**

  

  

**3.1 Making data findable, including provisions for metadata**

According to the principle of making data discoverable, all data to be made
openly available in SAFE STRIP will have rich metadata. The foreseen data
quality assurance process of the project will take special care in order to
prevent storage of data for open access, unless adequate metadata will be
provided.

All data in SAFE STRIP will be encoded in adherence to a set of standards
(e.g. ETSI TS 102 894-2, etc.) that are mentioned in Section 3.3. Adherence to
those standards will ensure that the appropriate metadata will be provided,
making data visible in a searchable context based on the semantics of data.

Also the use of persistent and unique in the form of Digital Object
Identifiers will be supported in order to facilitate data search and
discovery.

The naming conventions used for SAFE STRIP data will be as follows. The DE
introduced in the previous section, and the connection among them (see e.g.
Figures 1-4), where the **Cause Code** (TPEGS-TEC (CEN ISO/TS 21219-15))
corresponds to the **Direct Cause Code of** **DE_CauseCodeType** **(DataType_
10)** and the **Sub Cause Code** (TPEGS-TEC (CEN

ISO/TS 21219-15)) corresponds to the **Sub Causes Code** of the following DE:

  * **DE_AdverseWeatherCondition – AdhensionSubCauseCode (DataType_ 4)**

  

  * **DE_AdverseWeatherCondition – ExtremeWeatherConditionSubCauseCode (DataType_ 5)**

  

  * **DE_AdverseWeatherCondition – PrecipitationSubCauseCode (DataType_ 6)**

  

  * **DE_AdverseWeatherCondition – VisibilitySubCauseCode (DataType_ 7)**

  

  * **DE_HazardousLocation – SurfaceConditionSubCauseCode (DataType_ 33)**  **DE_RoadworksSubCauseCode (DataType_ 66)**

  

The aforementioned standards (DATEX II, TPEG) and the metadata they provide
will be applied in order to make data searchable. For enabling keyword search-
based data discovery off-the-self solutions will be deployed for allowing ease
and fast search (see also section 3.2).
slippery road”  10
weather conditions”  4
visibility”  11
works” 4

**3.1.1 Data documentation**

In addition to metadata inherited by the aforementioned standards, further
documentation and metadata will be provided where applicable. The initial
documentation details that will be included for each service are shown in the
template shown below.

Table 4: Data documentation template  
  
<table>  
<tr>  
<th>

**Basic**

</th>  
<th>

</th>  
<th>

**Service 1**

</th>  
<th>

**Service 2**

</th>  
<th>

**Service n**

</th>  
<th>

**Advanced**

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

Data name

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

Definition of variables

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

Who

created/contributed data

</td>  
<td>

to

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

Vocabularies

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

Date created

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

Units of Measurement

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

Data modified

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

File format and type

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

Conditions

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

Methods

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

**Basic**

</td>  
<td>

**Service 1**

</td>  
<td>

**Service 2**

</td>  
<td>

**Service n**

</td>  
<td>

**Advanced**

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

</td>  
<td>

</td>  
<td>

</td>  
<td>

</td>  
<td>

used/assumptions made/analytical procedural info; description

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

The role of this template will be to accompany any data to be accessed and
used by other than the individuals/organizations who collected the data. The
details that will define and create the specific dataset profile can be:

_Basic:_ details defining the origin, the type, the creation dates and the way
in which this data was created.

_Advanced_ : include definitions of variables, the methods used and applied in
order to gather and capture data based on common standards (incl. any
procedural steps taken). A detailed and technical specification of data might
be included like the variables that define the specific dataset, the units of
measurements and the assumptions applied for the data collection (e.g. zero
might mean no activity recorded, therefore the patient is not active). The
format and file types used for collecting and storing the data (and size) can
be of help if external users show interest in re-using a dataset (i.e.
checking compatibility with s/w they use in order to aggregate or analyse data
utilise import/export functionalities).

**3.2 Making data openly accessible**

All data described in Section 1 will be made available with open access with
the exception of those datasets that will be assessed by the project
consortium as being subject to IPR violation, e.g. proprietary data owned by
consortium beneficiaries or third legal parties (e.g. suppliers), in
accordance with the policies outlined in DoASection 5, the Ethics requirement
deliverables of the project (D9.1, D9.2), as well as the project CA especially
concerning data that will be generated or made available as background assets
by one or more beneficiaries. In case restrictions such as the aforementioned
ones will occur, access will be granted only to authorised users.

All datasets will be available for sharing and re-use via the
management/exploitation portals of the project. These portals will be the
common means for exchanging data either among the partners of the project or
between the consortium and third parties. The specifications of how and which
of the portals will be used in the context of data sharing and reuse will be
defined in the next months (up to M9) by the consortium and will be included
in the final version of the DMP. These specifications have to be referred to
any new features that have to be added to the current portal infrastructure
for dealing with the different data manipulation needs.

All datasets will be stored in a private cloud-based repository, e.g. ZENODO
( _https://zenodo.org/_ )  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 that were
used by the dataset creator(s) so that secondary data users can access and
then validate the results. The SAFE STRIP data collection can be accessed in
ZENODO repository in a similar address as the following link:
_https://zenodo.org/collection/ <<safestrip _ > >. The datasets in the cloud
repository will be linked to the management/exploitation portals of the
project, as well, and they will be assigned to DOIs in order for 3  rd
parties to have access to them. Through the use of the above repository (or
similar, e.g. ownCloud), we will ensure that the most up to date security
features will be applied out of the box, e.g., firewall, password protection,
encryption, etc. If any IPR issue exist on sharing, they will be handed
accordingly. Moreover, all necessary material that supplements each dataset
(software for parsing the datasets, standards documents, etc.) will be
provided by the consortium via the management/exploitation portals.

**3.3 Making data interoperable**

Data interoperability is foreseen in the project through conformance to
standards Specifically, SAFE STRIP data will confront to the following
standards:

  * ETSI TS 102 894-24 

  

  * ETSI EN 302 637-2  12 

  

  * ETSI EN 302 637-32 

  

  * DATEX II, TPEG2-TEC- and TMCEvents for safety messages  13 

  

**3.4 Increase data re-use (through clarifying licenses)**



SAFE STRIP participates in the Pilot on Open Research Data launched by the
European Commission along with the Horizon2020 Programme. As such, all data
produced by the project are to be published with open access. Particularly,
access will be given through Creative Commons CC0 license for all datasets at
this project stage, unless it is defined otherwise.

All datasets will be maintained for the entire duration of the project as well
as for 2 additional years after its conclusion. After the project ends, all
datasets will be stored in a centralized facility in order to minimize
maintenance costs. Datasets with acknowledged long-term value may be kept for
longer period of time. The long-term value of a dataset will be decided
according to exploitation plan as well as its relation to a scientific
publication.

For the time period in which the data will be available for open access, no
restrictions will be imposed on their access. In case IPR protected or
proprietary data will be generated or made available as background assets in
the context of the project by one or more beneficiaries, access to this data
will be treated in accordance to the rules and regulations foreseen in the
project Consortium Agreement. For all this data, access will be granted only
to authorised users.

All data to be available as open data will undergo a quality assurance
process.

At a first level, each partner in charge follows specific procedures to assure
the quality of the data and conformance to standards as referred to each
dataset’s description in Section 2. Those procedures regard calibration of the
measurements, as well as, internal post-measurement review. In a higher level,
quality will be also monitored periodically on the different versions of the
dataset as conservation experts of the consortium will review each update.
Finally, additional peer-reviews will take place in case of publication in
Journals.

**4 SAFE STRIP Open Strategy & Participation in the Open Research Data Pilot
**

The SAFE STRIP project has agreed to participate in the Pilot on Open Research
Data in Horizon 2020 and uses the specific Horizon 2020 guidelines associated
with ‘open’ access to ensure that the results of the project results provide
the greatest impact possible. SAFE STRIP will ensure the open access  14  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 a
SAFE STRIP project-generated scientific publication in the Library section of
the project web site (  _http://safestrip.eu/publications-index-p/_ )  , where
a Publication Index has been anticipated:

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

  

  * Name of the action (Research and Innovation Action) 

  

  * Acronym and grant number (SAFE STRIP, 723211) 

  

  * Publication date 

  

  * Publication type 

  

  * Publication place 

  

  * Publication name 

  

  * Publication authors 

  

  * Length of embargo period if applicable 

  

  * Persistent identifier 

  

Apart from the scientific publications index, SAFE STRIP will publish all its
public Deliverables and dissemination material in its web site (under
“Library”). When referencing Open access data, SAFE STRIP 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 723211”.

Finally, SAFE STRIP will target **Open Access journals** , when applicable,
whereas it will also target Gold OA publications and Green OA, wherever Gold
OA is not possible. The target is to maximize the impact on scientific
excellence through result publication in open access yet highly appreciated
journals, without releasing any confidential information that could
potentially violate the security nature of the project.

The SAFE STRIP 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 also
section 3.2).

In regards to the specific repositories available to the SAFE STRIP
consortium, numerous project partners maintain institutional repositories that
will be listed in the next DMP version (Deliverable D2.3), where project
scientific publications and in some instances, research data will be
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 on an online data repository (see
also Section 3.2) about ZENODO. In summary, as a baseline SAFE STRIP partners
shall deposit:

  * _Scientific publications_ – on their respective institute repositories in addition 

  

(when relevant) to the SAFE STRIP online data repository

  * _Research data_ – to the SAFE STRIP online data collection (when possible) 

  

  * _Other project output files_ – to the SAFE STRIP online data collection (when relevant) 

  

This version of the DMP does not include the actual metadata about the
Research Data being produced in SAFE STRIP project. Details about technical
means and services for building repositories and accessing to this metadata
will be provided in the next version of the DMP (deliverable D3.2). A template
document is defined in section 3.1.1 and will be used by project partners to
provide all requested information.

  5. **Allocation of Resources**

  

  

In order to face the data management challenges efficiently, all SAFE STRIP
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
SAFE STRIP will be undertaken by Dionysis Kehagias (CERTH/ITI) who will
directly report to the SAFE STRIP Ethics Board and the Project Management Team
(PMT). 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 SAFE STRIP, will be 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 WP leader 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. In
summary, the Data Manager will coordinate the actions related to data
management, will be responsible for the actual implementation of the DMP
successive versions and for the compliance to Open Research Data Pilot
guidelines.

As the SAFE STRIP open data will be hosted by an open free of charge platform
(e.g. Zenodo), no additional costs will be required for hosting the data.

  6. **Ethical and Security Aspects**

    1. **Ethical issues**

  
  

  

  

Regarding ethical issues, the deliverables D9.1 and D9.2 detail all the
principles, processes and measures that SAFE STRIP will use to comply with the
H2020 Ethics requirements. In addition, security and privacy requirements will
be addressed in _D2.1: “System architecture, sensor specifications,
fabrication, maintenance, installation and security requirements and Risk
Assessment”_ for M18.

  2. **Data Protection and Security**

  

  

To avoid any data losses and ensure fast and reliable access to the data
common storage facility to be deployed in SAFE STRIP, appropriate redundancy
mechanisms will be deployed (e.g. RAID-1, RAID-5 etc.) for the online data
repository. In addition to online data, an appropriate number of off-line
copies will be maintained in hard disks or network-attached storage (NAS)
owned by every partner in charge of their data. For the time of this writing,
the total volume of the generated data has not yet been estimated accurately.

A separate checklist has been prepared and should be used by all data
providers not only during evaluations but also technical testing and
validation. Any data that will be stored as a result of regular checks and
tests performed by the service administrators wish to perform regular checks
and tests and want to be able to create a database:  
  
<table>  
<tr>  
<th>

**Checklist** :

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

  

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

  

  * Which storage medium will you use for your storage and backup strategy? Network storage; personal storage media (e.g. external hard drives); cloud storage 

  

  * Are backups made with sufficient frequency so that you can restore in the event of data loss? 

  

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

Each site and service responsible should ensure that the research data is
regularly backed-up and stored in secure and safe location. There is a common
“rule-of-thumb” to only store data that you actually need in three different
copies. It is advised that copies can be stored in both local and remote
storage units/locations.

**6.3 SAFE STRIP data privacy policy**

SAFE STRIP system aims to be a cost-efficient safety and comfort provision
cooperative system. It performs so with due respect, as all required
participants’ physical, vehicle, driving performance and subjective data (e.g.
driving background data) will be stored separately from identification
information and be securely protected by relevant mechanisms.

Personal data on subjects will be used in strictly confidential terms and will
be published only as integrated statistics (anonymously) and under no
circumstances as individual data set. All test data will be anonymized. Only
one person per site (relevant Pilot responsible) will have access to the
relation between test participants’ code and identity, in order to administer
the tests. People who will analyse data will receive anonymised and coded
information. One month after the tests end, this reference will be deleted,
thus safeguarding full anonymisation. The stored data will only refer to
users’ age, gender, nationality and driving profile. No other identifier will
be kept. Nevertheless, **stored data will by no means relate to a person’s
health, religious, political and sexual beliefs and preferences.** In
addition, SAFE STRIP pilot participants **will not receive any medication,
related to project research.**

As such, anonymised data will be publicly available for other researchers;
still with no possibility for identification of participants. In addition,
participants will be recorded only if they provide consent.

To avoid risks related to the processing of personal data such as identity
theft, discriminatory profiling or continuous surveillance, the principle of
proportionality has to be respected. Data can be used only for the initial
purpose for which they were collected. Anonymisation or pseudonymisation is a
way to prevent violations of privacy and data protection rules. Processing has
to be limited to what is truly necessary and less intrusive means for
realising the same end have to be considered.

All this information falls under the European legislation for the lawful
processing of personal data:

  * Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation). 

  

  * Directive 95/46/EC of the European parliament and the Council (1995) on the protection of individuals with regard to the processing of personal data and on the free movement of such data. 

  

  * Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the retention of data generated or processed in connection with the provision of publicly available electronic communications services or of public communications networks and amending Directive 2002/58/EC. 

  

  * Directive 2002/58/EC of the European Parliament and of the Council, concerning the processing of personal data and the protection of privacy in the electronic communications sector. 

  

  * Reform of the legislative framework for personal data protection (In January 2012, the European Commission proposed a reform of the Directive 95/46/CE, which constituted until now the basic instrument for personal data protection, in the form of a global Regulation on data protection 2012/001 (COD), supplemented by Directive 2012/0010 (COD) concerning the processing of personal in the area of police and judicial cooperation in criminal matters). 

  

  * Art.29 Data Protection Working party: Working Document on Privacy on the Internet. 

  

Still, apart from the above, attention will be paid to national legislation,
that has to be respected even if the users have given their consent for the
processing of their personal data.

As such, during the SAFE STRIP Pilot tests:

  1. Drivers/riders (but also other stakeholders) participating in the trials will give their names, address, and contact phone, together with age, gender, nationality and, if any, functional problem type (not medical term of impairment), to a single person in each pilot site, to be stored in a protected local database (to contact them and arrange for the tests). The contact person will issue a single Participant ID for each of them. This person will not participate in the evaluation and will not know how each user behaved. 

  

  2. The names, address and contact phone will be kept in the database only for the duration of each trial (short term trials-up to 1 week, long term trials- up to 1 month). Such data will not be communicated to any other partner or even person in each pilot site. Once the test ends, they will be deleted. 

  

  3. Each month the anonymised data will be re-sorted randomly, to mix participants order. 

  

  4. Since personal data will be deleted, no follow-up studies with the same people will be feasible. 

  

  5. Personal data will be used in strictly confidential terms and will be published as statistics (anonymously). 

  

  6. In pilots, all necessary safety precautions will be taken (i.e. use of professional drivers or drivers with valid driving license under normal traffic conditions, and , in case of need, using a test car with double pedals and a driving instructor as codriver). 

  

  

**7 Conclusions – Next Steps**

The first data management analysis contained in this report allows
anticipating the procedures and infrastructures to be implemented in SAFE
STRIP to efficiently manage the generated and/or collected data.

This document points to present the general principles of DMP and to summarize
the current state of each and every identified dataset, containing information
regarding brief descriptions, standards and metadata specifications,
activities and responsibilities of each partner, access, data sharing and
reuse policies and archiving/preservation strategies over the respective
datasets from each and every related partner.

Finally, open issues have been recognized, i.e., the role and the
functionality of the management/exploitation portals as a common means for
data sharing have to be specified, and the metadata specifications which
cannot be explicitly defined yet. These open issues are taken into sincere
consideration and they are to be addressed in the next period.

The next version of the data management plan (D2.3), which is scheduled for
M29, will include more detailed dataset descriptions according to the process
defined in this version. Until M29, WP1 will have been completed, but also WP2
and WP3 will be approaching their ending (both end at M33), therefore the main
input regarding the data types from sensors and the end user applications and
services will have been comprehensively defined in detail. Hence, an enhanced
and possibly revised version of the SAFE STRIP data models that have been
introduced in this initial version of the DMP will be provided.