#  Introduction

##  Overall Objective

As part of its exploitation and sustainability strategy, SecureIoT will be
releasing part of its platform as open source software, which will be made
available through the project’s ecosystem portal that is developed in WP7 of
the project. Along with software, the project plans to release datasets as
well, as means of facilitating third-parties (i.e. members of the SecureIoT
platform community) to test, validate and possibly extend SecureIoT
developments. This intention is fully in-line with SecureIoT’s strategy for
data management, as the latter is reflected in the project’s DoA (Description
of the Action) document. In this context, this part of the deliverable is
devoted to the presentation of the project’s Data Management Plan (DMP).

In principle, the release of data in the scope of SecureIoT is aimed at the
following objectives:

  * **Validation of SecureIoT components** : SecureIoT needs to provide partners and thirdparties with an easy way for using and validating its developments. In most cases, this requires the availability of some data that can be used to validate the operation of SecureIoT components. 

  

  * **Demonstration of SecureIoT components** : In addition to boosting the validation of SecureIoT components, datasets are also needed for running demonstrations of the various prototypes. Demonstrations is an essential element for ecosystem building, as third-parties are usually starving for one-click demonstrations that could easily help them understand the operation of certain software components. 

  

  * **Training and Education** : Open datasets can be an invaluable resource for developing training and education modules, such as the ones developed in the scope of the SecureIoT training services. 

  

  * **Follow the GDPR guidelines** : In May 2018, the new European Regulation on Privacy, the General Data Protection Regulation, (GDPR) came into effect. In this DMP we will describe the measures to protect the privacy of all data provided in the light of the GDPR. 

  

In order to realize these objectives, SecureIoT is considering the release of
certain datasets as open data. This DMP identifies candidate datasets, along
with the preconditions for making them openly accessible as part of offerings
to the project’s ecosystem.

##  DMP Evolution

The DMP presented in this deliverable is characterized as preliminary, given
that the project is still in the process of finalizing the specifications of
validating scenarios and use cases, while actual data capturing has not
commenced yet. SecureIoT will release updates to the present DMP, in-line with
the evolution of the specification and implementation of validating use cases,
including their deployment in the test environments.

As already outlined, this preliminary version of the DMP has a dual objective:
First to identify available datasets that are likely to be opened and shared
as part of the SecureIoT ecosystem. Second, to identify the conditions that
should be met in order for these datasets to be opened. The identification of
such conditions is particularly important, given that making data public is
against the corporate policies of the manufacturers of the consortium. In
certain case, this important barrier can be lowered following appropriate
processing of the data (e.g., anonymization), as well as following reception
of appropriate approvals.

##  GDPR

Since the 25  th  May 2018, GDPR is valid and obligatory and that applies also
for SecreIoT project. Therefore, partners are following the same new rules and
principles. In this section, we are describing how the founding principles of
the GDPR will be followed in the SecureIoT project. More specifically,
following points are taken into account:

  * **Lawfulness, fairness and transparency** : Personal data shall be processed lawfully, fairly and in a transparent manner in relation to the data user. 

  

  * **Purpose limitation** : Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes. 

  

  * **Data minimization** : Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed. 

  

  * **Accuracy** : Personal data shall be accurate and, where necessary, kept up to date. All data collected will be checked for consistency. 

  

  * **Storage limitation** : Personal data shall be kept in a form, which permits identification of data for no longer than is necessary for the purposes for which the personal data are processed. 

  

  * **Integrity and confidentiality** : Personal data shall be processed in a manner that ensures appropriate security of the personal data, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures. 

  

  * **Accountability** : The controller shall be responsible for, and be able to demonstrate compliance with the GDPR. 

  

##  Datasets Description Template

In following paragraphs we provide an overview of the datasets that SecureIoT
will be considering for release as part of its ecosystem. Note that the
inclusion of a dataset in the list implies that it is considered to be offered
in the project’s portal, subject to the clearance of some precondition.
Datasets information is divided in five different categories and in each
category the information is described in a tabular form. The attributes of the
information provided are:

###  General information

  * **Ref. No** : Sequence Number 

  

  * **Title** : The title of the Dataset 

  

  * **Version** : The dataset info version 

  

  * **Description** : Briefly describe what data would represent 

  

  * **Type of data** : Data already existing OR date to be released 

  

  * **Dataset availability** : Date of the dataset availability 

  

  * **Future revisions anticipated** : Define if future revisions are anticipated  **Owner** : Denotes the provider of the datasets. 

  

  * **Contact Person** : Person in charge of the release of the dataset and its inclusion in the SecureIoT portal. 

  

  * **Related Use Cases** : The set of SecureIoT use cases that the dataset related. The description of the use cases is performed with reference to deliverable D2.2. 

  

  * **Utility / Potential Use** : An illustration of why the particular dataset could be useful to the SecureIoT community. e.g.: 

  

o Research and experimentation o Service Development / Integration o Training
& Education

###  Environment / Context

  * **Directly observable device types** : i.e., Sensor, robot, vehicle board, monitor device, edge node, gateway 

  

  * **Directly observable software** : i.e., IoT application, gateway software, cloud service app… 

  

  * **Indirectly observable device** : i.e., Sensor, robot, vehicle board, monitor device, edge node, gateway (devices which are not directly monitored, be exhaustive to the extent possible) 

  

  * **Indirectly observable software** : List the software which is observed indirectly 

  

  * **Architecture/Topology description and communication protocols** : Figure showing where are the monitoring probes (some incertitude may occur) 

  

###  Data access

Here there are three cases:

  1. Data is already retrieved and stored as data files 

  

  2. Monitoring data can be retrieved through an interface 

  

  3. Data is present in sw/hw but no means exists yet to access them remotely, need for a probe to be developed 

  

  

The first two may coincide. Data access has the following attributes:

  * **Dataset provided as data file(s)** : Define if the dataset is provided as data file(s)  **Remote accessibility** : Define if the data are remotely accessible and how. 

  

  * **If data is not yet accessible, how can they be retrieved?** : Define the method which the data can be accessed in the future. 

  

###  Data description

  * **Data format** : i.e., NetFlow, pcap, syslog, json (when an interface is used, the format of embedded data is needed to be described) 

  

  * **Encryption** : explain if and how the data are encrypted. 

  

  * **Data format description** : describe the syntax and semantics of data (very important for non-standard formats, e.g. describe the columns of a csv file, or the structure and semantics of what contains a JSON file) 

  

  * **For unusual format, tool to read it** : specify the required tool/library to read the data if their data type is not standard. 

  

  * **Dataset generation** : specify if the data was monitored in a system with real users? If no, how the data has been generated? 

  

  * **Attack** : specify if the dataset contain attacks? If yes, specify if the attacks are annotated? If yes, specify what is the granularity of the annotations? 

  

  * **Dataset statistics** : i.e., Duration, size(s) in appropriate format (MB, pkts), number of packets breakdown per IP address, protocols… (be exhaustive as possible) 

  

  * **Sample of data** : Provide a sample of data in this attribute or a link to them. 

  

###  Data restrictions

  * **Is the data open publicly?** : Specify if the data are public 

  

  * **If no, is there a plan to make data open?** : Specify if the data are not public a plan to make them public. 

  

  * **If no, will the data be accessible to the consortium, or to specific partner(s)?** : Specify if the data can be accessible to the consortium, or to specific partner(s) in case they cannot be public. 

  

  * **If yes, for how long?** : Specify the time period the data can be accessible to the consortium, or to specific partner(s) in case they cannot be public. 

  

  * **Can the data be used for public dissemination** : Specify if the data can be used for public dissemination (without revealing the full content of the data, aggregated view) 

  

  * **Who owns the data?** : Identify the data owner 

  

  * **Legal issues** : Specify the confidentiality level of the dataset and the license under which the dataset could be opened and offered publicly. 

  

##  SecureIoT Datasets  
  
<table>  
<tr>  
<th>

Ref. No

</th>  
<th>

_0001_

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

Title

</td>  
<td>

Manufacturing data resulting from sensors, machines, IACS

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

Version

</td>  
<td>

1.0

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

Description

</td>  
<td>

This dataset contains or will contain different kind of data generated within
manufacturing. These will be sensor data sometimes aggregated for a complete
machine.

Moreover, data generated by IACS shall be considered in the use case.

The data may include application information, context information, status
information, traffic data and much more.

Details will be specified within the use case

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

Type of data

</td>  
<td>

Application, context, performance, status, usage, alerts, etc.

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

Dataset

availability

</td>  
<td>

TBD

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

This is the first version of the DMP deliverables and some of the Dataset
information has not been determined yet. The missing fields will be completed
in the coming versions of the deliverable. The information provided below has
been collected in collaboration with WP3 and WP4.

###  Multi-Vendor Industrie 4.0 Usage Scenarios Data

1.5.1.1 General information  
  
<table>  
<tr>  
<th>

Directly observable device types

</th>  
<th>

  * IoT Gateways, e.g. FUJITSU Intelliedge 

  

  * IACS systems 

  

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

Directly observable software

</td>  
<td>

  * TBD in the use case. We consider several systems to be relevant: 

  

  * P@SSPORT factory virtualization 

  

  * SIEMENS Minsphere 

  

  * FUJITSU IoT-Platform 

  

  * FUJITSU Colmina Intelligent Dashboard 

  

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

Indirectly observable device

</td>  
<td>

_Sensor, robot, vehicle board, monitor device, edge node, gateway (devices
which are not directly monitored, be exhaustive to the extent possible)_

 Manufacturing devices connected to the IACS or gateways. These may be
sensors, etc. The objective

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

Future revisions anticipated

</th>  
<th>

Yes

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

Owner

</td>  
<td>

Weidmüller, Phoenix, it's OWL

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

Contact

Person

</td>  
<td>

David Schubert ( _d.schubert@its-owl.de_ )

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

Related Use

Cases

</td>  
<td>

TBD

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

Utility /

Potential

Use

</td>  
<td>

TBD

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

1.5.1.2 Environment / Context  
  
<table>  
<tr>  
<th>

</th>  
<th>

within the use case will be to use virtualized control systems and sensors.

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

Indirectly observable software

</td>  
<td>

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

Architecture/Topolog y description and

communication protocols

</td>  
<td>

_Figure showing where are the monitoring probes (some incertitude may occur)_

Probes may be placed on each level and within the vertical communications.
Moreover, probes should be placed at the IoT-Platform level

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

Dataset provided as data file(s)

</th>  
<th>

_Yes/No_

TBD

</th>  
<th>

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

Remote

accessibility

</td>  
<td>

Yes/No

</td>  
<td>

Usually: No

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

Protocol

</td>  
<td>

TBD

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

1.5.1.3 Data access  
  
<table>  
<tr>  
<th>

</th>  
<th>

Message format

</th>  
<th>

TBD

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

Pull/Push

</th>  
<th>

TBD

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

Provided interface

</th>  
<th>

TBD

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

If data is not yet accessible, how can they be retrieved?

</td>  
<td>

Describe the architecture and where the probe can deployed

</td>  
<td>

TBD

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

</td>  
<td>

Probe development requirements

</td>  
<td>

TBD

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

Usable software API on device

</td>  
<td>

TBD

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

Data format

</th>  
<th>

 TBD inm the use case

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

Encryption

</td>  
<td>

_Is the data encrypted? (explain)_

Yes, communication between all the components will rely on secure
communication protocols, i.e., HTTPS.

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

Data format description

</td>  
<td>

 TBD in the use case

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

For unusual format, tool to read it

</td>  
<td>

TBD

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

Dataset generation

</td>  
<td>

Was the data We consider virtualized systems with monitored in a scenarios and
no real users

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

1.5.1.4 Data description  
  
<table>  
<tr>  
<th>

</th>  
<th>

system with real users?

</th>  
<th>

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

If no, how the data

has been generated?

</th>  
<th>

_Actions triggered /performed/simulated, how many of them, methodology_

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

Attack

</td>  
<td>

Does the dataset contain attacks?

</td>  
<td>

In a first step we plan to provide normal operations data

Later on the virtualized plant(s) shall be exposed to attacks and the data
shall include attacks

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

If yes, are the attack labeled?

</td>  
<td>

No

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

If yes, what is the granularity of the labels?

</td>  
<td>

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

Dataset statistics

</td>  
<td>

TBD

</td>  
<td>

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

Sample of data

</td>  
<td>

TBD

</td>  
<td>

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

Is the data open publicly?

</th>  
<th>

No

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

If no, is there a plan to make data open?

</td>  
<td>

No

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

If no, will the data be accessible to the consortium, or to specific
partner(s)?

</td>  
<td>

Yes, whole consortium

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

If yes, for how long?

</td>  
<td>

End of project

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

Can the data be used for public dissemination (without revealing the full
content of the data, aggregated view)

</td>  
<td>

TBD

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

1.5.1.5 Data restrictions  
  
<table>  
<tr>  
<th>

Who owns the data?

</th>  
<th>

The respective partners of use case scenario T6.2

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

Legal issues

</td>  
<td>

There may be several issues regarding personal data of either customers or
employees. Within the Industrie4.0 use case we shall consider anonymization of
data for SecureIoT data collection.

Moreover we will face M2M communications and thus

telecommunication data will be a key part if the data collection.

Finally, the data may contain business secrets, e.g. process parameters.

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

Ref. No

</th>  
<th>

_0002_

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

Title

</td>  
<td>

QTrobot

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

Version

</td>  
<td>

1.0

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

Description

</td>  
<td>

This dataset consists of traffic

  * In QTrobot 

  

  * Between robot and its tablet GUI 

  

  * Between robot and CC2U of iSprint 

  

  * Between robot and internet 

  

  * Between tablet and its cloud backup server 

  

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

###  IoT-Enabled Socially Assistive Robots Usage Scenarios Data

1.5.2.1 QTrobot

1.5.2.1.1 General information  
  
<table>  
<tr>  
<th>

</th>  
<th>

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

Type of data

</td>  
<td>

  * Raw sensory data (video stream, sound stream, robot’s joint angles) 

  

  * Perception data (recognized images, objects, faces, human gesture, speech, direction of voice) 

  

  * Application and actuation data (video, sound and gesture outputs of QT, application events, recognized activity, proposed activities ) 

  

  * Robot and tablet config and performance (CPU, RAM, HDD and network bandwidth access and usage, network connection, running processes) 

  

  * User data (user profile, application history, user performance and progress data, user-built applications) 

  

  * Network traffic (packages) 

  

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

Dataset

availability

</td>  
<td>

Mechanisms and Interfaces to capture and communicate the data to the
destination device are to be developed.

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

Future revisions anticipated

</td>  
<td>

Yes

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

Owner

</td>  
<td>

LuxAI

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

Contact

Person

</td>  
<td>

Pouyan Ziafati (ziafati@luxai.eu)

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

Related Use

Cases

</td>  
<td>

Social Assistive Robots

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

Utility /

Potential

Use

</td>  
<td>

Research and experimentation

Training & Education

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

Directly observable device types

</th>  
<th>

_Sensor, robot, vehicle board, monitor device, edge node, gateway_

  * Robot Gateway 

  

  * Tablet Gateway 

  

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

Directly observable software

</td>  
<td>

 Robot Operating System (ROS)

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

Indirectly observable device

</td>  
<td>

  * 3D camera 

  

  * Microphone array 

  

  * Motor sensors 

  

  * Computer inside the robot 

  

  * Android tablet 

  

  * Router inside the robot 

  

  * Wi-fi inside the robot 

  

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

Indirectly observable software

</td>  
<td>

Camera interface, microphone interface, motor interface, image recognition,
face recognition, object and gesture recognition, sound play, video play,
robot plan executor, gesture record and play

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

Architecture/Topology description and communication protocols

</td>  
<td>

Robot --- ROS (JSON API through Websocket server can be developed)

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

1.5.2.1.2 Environment / Context  
  
<table>  
<tr>  
<th>

Dataset provided as data file(s)

</th>  
<th>

Yes

</th>  
<th>

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

Remote

accessibility

</td>  
<td>

Yes/No

</td>  
<td>

Yes (but means have to be developed)

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

Protocol

</td>  
<td>

ROS (or its Websocket server interface)

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

Message format

</td>  
<td>

_ROS messages (or JSON equivalent of ROS messages)_

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

Pull/Push

</td>  
<td>

_Pull, push_

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

</td>  
<td>

Provided interface

</td>  
<td>

_ROS service/pub-sub interface + message description (or Websocket URI to be
developed)_

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

If data is not yet accessible, how can they be retrieved?

</td>  
<td>

Describe the architecture and where the probe can deployed

</td>  
<td>

_We use ROS to communicate between different_

_pieces of software in the robot, and to communicate among the robot and
tablet. ROS can be provided with a websocket JSON-based interface which we can
use to develop a prob to access the robot. The other way around however would
be to extend the SecureIoT data capturing interface to support direct
communication with ROP._

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

Probe development requirements

</td>  
<td>

_See previous answer._

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

Usable software API on device

</td>  
<td>

_See previous answer._

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

1.5.2.1.3 Data access  
  
<table>  
<tr>  
<th>

Data format

</th>  
<th>

_NetFlow, pcap, syslog, json (when an interface is used, the format of
embedded data is needed to be described)_

Network traffic (could be pcap for instance)

ROS Messages (proprietary format, or Jason equivalent)

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

Encryption

</td>  
<td>

Most of the data is not encrypted.

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

Data format description

</td>  
<td>

Full pcap file including payload

Each type of data has its own format.

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

For unusual format, tool to read it

</td>  
<td>

_ROS messages are simple data structures similar to C structs._

_http://wiki.ros.org/Messages_

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

Dataset generation

</td>  
<td>

Was the data monitored in a system with real users?

</td>  
<td>

_May be possible_

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

If no, how the data

has been generated?

</td>  
<td>

_Data has not been generated_

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

Attack

</td>  
<td>

Does the dataset contain attacks?

</td>  
<td>

No

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

If yes, are the attack labeled?

</td>  
<td>

_-_

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

</td>  
<td>

If yes, what is the granularity of the labels?

</td>  
<td>

_Per packet, per flow, timeline of anomalies_

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

Dataset statistics

</td>  
<td>

TBD

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

Sample of data

</td>  
<td>

TBD

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

1.5.2.1.4 Data description

1.5.2.1.5 Data restrictions  
  
<table>  
<tr>  
<th>

Is the data open publicly?

</th>  
<th>

_No_

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

If no, is there a plan to make data open?

</td>  
<td>

_Some parts can be made open_

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

If no, will the data be accessible to the consortium, or to specific
partner(s)?

</td>  
<td>

_Most part yes, Anonymization may be needed._

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

If yes, for how long?

</td>  
<td>

TBD

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

Can the data be used for public dissemination (without revealing the full
content of the data, aggregated view)

</td>  
<td>

_TBD_

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

Who owns the data?

</td>  
<td>

TBD

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

Legal issues

</td>  
<td>

_**_Flags:_ ** _

_data may be “personal data”_

_we plan to combine/merge the data with this other data source:_

___________________

_data may be “telecommunication_

_metadata”_

_data may be “telecommunication_

_content”_ _data is encrypted data may contain business secrets_

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

1.5.2.2 CC2U  
  
<table>  
<tr>  
<th>

Ref. No

</th>  
<th>

_0003_

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

Title

</td>  
<td>

CC2U

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

Version

</td>  
<td>

1.0

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

Description

</td>  
<td>

The Cloud Gateway if CC2U has different set of software interfaces used for
exchange of commands and data primarily from and to

Remote Proxy and that can be grouped to the following categories:

  * Control and configuration interfaces (I  1  ) 

  

  * Sensing data interfaces (I  2  ) 

  

  * Notifications interface (I  3  ) 

  

  * Actuator interfaces (I  4  ) 

  

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

Extended

Description

</td>  
<td>

Control and configuration Cloud Gateway interfaces (I1) are used for receiving
registration and point of contact information (version, status, etc.) from
remote proxy running in local home environments, synchronization of local and
cloud data, obtaining device configuration data from cloud and remote
configuration of local platform.

Sensing data interfaces (I2) are used for receiving all sensing data from home
environments and storing them using Data Manager. This includes user activity
data, environmental sensing data (temperature, humidity, luminance, gas
levels, movement, and presence), furniture sensing data, appliance sensing
data, speaker sensing data, visual sensing and vitals data.

Notification interface (I3) is used for exchanging notification messages from
local reasoners in local environments and Notification Manager. Actuator
interface (I4) is used for control and sensing actuator commands from cloud
components towards local home environment.

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

Type of data

</td>  
<td>

Application, context, performance, status, usage, alerts, etc.

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

1.5.2.2.1 General information  
  
<table>  
<tr>  
<th>

Directly observable device types

</th>  
<th>





</th>  
<th>

Wearable devices (e.g. Fitbit tracker)

Medical devices (e.g. NONIN SpO2, OMRON blood pressure)

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

</td>  
<td>



</td>  
<td>

Environmental sensors (temperature, humidity)

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

</td>  
<td>



</td>  
<td>

A/V sensing (e.g. cameras, KINECT)

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

</td>  
<td>



</td>  
<td>

QT Robot

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

Directly observable software

</td>  
<td>



</td>  
<td>

CloudCare2U – Cloud Gateway

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

Indirectly observable device

</td>  
<td>

TBD

</td>  
<td>

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

Indirectly observable software

</td>  
<td>

TBD

</td>  
<td>

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

Dataset

availability

</th>  
<th>

TBD

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

Future revisions anticipated

</td>  
<td>

Yes

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

Owner

</td>  
<td>

iSPRINT

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

Contact

Person

</td>  
<td>

Sofoklis Kyriazakos

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

Related Use

Cases

</td>  
<td>

Social Assistive Robots

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

Utility /

Potential

Use

</td>  
<td>

TBD

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

1.5.2.2.2 Environment / Context  
  
<table>  
<tr>  
<th>

Dataset provided as data file(s)

</th>  
<th>

TBD

</th>  
<th>

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

Remote

accessibility

</td>  
<td>

Yes/No

</td>  
<td>

Yes

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

Protocol

</td>  
<td>

TBD

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

Message format

</td>  
<td>

_JSON_

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

Pull/Push

</td>  
<td>

_Pull, push_

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

Provided interface

</td>  
<td>

TBD

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

If data is not yet accessible, how

</td>  
<td>

Describe the architecture and where

</td>  
<td>

TBD

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

Architecture/T

opolog

y description and

communication

protocols

_Figure showing where are the monitoring probes (some_

_incertitude may occur)_

1.5.2.2.3 Data access  
  
<table>  
<tr>  
<th>

Data format

</th>  
<th>

TBD

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

Encryption

</td>  
<td>

Yes, communication between all the components will rely on secure
communication protocols, i.e., HTTPS.

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

Data format description

</td>  
<td>

 TBD in the use case

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

For unusual format, tool to read it

</td>  
<td>

_-_

</td>  
<td>

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

Dataset generation

</td>  
<td>

Was the data monitored in a system with real users?

</td>  
<td>

Yes

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

</td>  
<td>

If no, how the data

has been generated?

</td>  
<td>

TBD

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

Attack

</td>  
<td>

Does the dataset contain attacks?

</td>  
<td>

No

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

If yes, are the attack labeled?

</td>  
<td>

_Yes/No_

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

can they be retrieved?

</th>  
<th>

the probe can deployed

</th>  
<th>

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

Probe development requirements

</th>  
<th>

TBD

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

Usable software API on device

</th>  
<th>

TBD

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

1.5.2.2.4 Data description  
  
<table>  
<tr>  
<th>

</th>  
<th>

\-

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

If yes, what is the _-_ granularity of the labels?

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

Dataset statistics

</td>  
<td>

TBD

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

Sample of data

</td>  
<td>

_**Url** _

_ <HOST_URI>/Notif?user={user_name}&&date= _

_{date} &time={time}&type={type}&title={title}&content= _

_{content} &prior={priority}&source={source} _

_**Parameters** _

_user – user name (e.g. “Bob”), date – Date of the trigger (e.g._

_"08-05-2014"), time – Time of the trigger (e.g. "12.30.21"), type – The
design type of the notification, in regards to its representation to the UI
(e.g. "two-buttons"), title- The title of the notification shown on the UI
(e.g. " Congratulations!"), content – The information content of the
notification shown on the UI (a JSON formatted information), prior – the
priority value for the given type of notification. This facilitates the
possibility to sort the notifications based on priority (left for future use),
source – the url address of the component that sends the notification._

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

Is the data open publicly?

</th>  
<th>

No

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

If no, is there a plan to make data open?

</td>  
<td>

No

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

If no, will the data be accessible to the consortium, or to specific
partner(s)?

</td>  
<td>

TBD

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

If yes, for how long?

</td>  
<td>

\-

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

Can the data be used for public dissemination (without revealing the full
content of the data, aggregated view)

</td>  
<td>

Yes thru Anonymization

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

1.5.2.2.5 Data restrictions  
  
<table>  
<tr>  
<th>

Ref. No

</th>  
<th>

_0004_

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

Title

</td>  
<td>

Connected car and autonomous driving data

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

Version

</td>  
<td>

1.0

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

Description

</td>  
<td>

This dataset contains or will contain different kind of data related to the
connected car and autonomous driving data, i.e., application information,
context information, traffic data…

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

Type of data

</td>  
<td>

Application, context, performance, usage, alert.

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

Dataset

availability

</td>  
<td>

Application data is available however this is not formally put into a log
(e.g. JSON) so formally capturing this log and putting it into a dataset file
is to be developed.

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

Future revisions anticipated

</td>  
<td>

Yes

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

Owner

</td>  
<td>

IDIADA

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

Contact

Person

</td>  
<td>

David Evans

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

Related Use

Cases

</td>  
<td>

Connected and Autonomous Vehicles

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

Utility /

Potential

Use

</td>  
<td>

Research and experimentation

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

Who owns the data?

</th>  
<th>

iSPRINT/LuxAI

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

Legal issues

</td>  
<td>

TBD

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

###  Connected Car and Autonomous Driving Usage Scenarios Data

1.5.3.1 General information  
  
<table>  
<tr>  
<th>

Directly observable device types

</th>  
<th>

 IDIADA IDAPT platform

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

Directly observable software

</td>  
<td>

 IoT FIWARE related components:

o IoT Agent (JSON) o Orion Context Broker

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

Indirectly observable device

</td>  
<td>

 Vehicle components connected to the IDAPT platform. For instance: o Vehicle
Speed o Braking information o Steering Wheel Angle o GPS Heading o GPS Speed o
Yaw_Rate o …

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

Indirectly observable software

</td>  
<td>

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

Architecture/Topology description and communication protocols

</td>  
<td>

Vehicle components --- CAN bus --- IDAPT platform

IDAPT platform --- MQTT / TCP + HTTPS + REST (monitoring probe)--- FIWARE IoT
Agent

FIWARE IoT Agent --- TCP + HTTPS + REST (monitoring probe) --- FIWARE Context
Broker ---

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

1.5.3.2 Environment / Context  
  
<table>  
<tr>  
<th>

Dataset provided as data file(s)

</th>  
<th>

Yes

</th>  
<th>

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

Remote

accessibility

</td>  
<td>

Yes/No

</td>  
<td>

No

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

Protocol

</td>  
<td>

_-_

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

Message format

</td>  
<td>

_-_

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

Pull/Push

</td>  
<td>

_-_

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

</td>  
<td>

Provided interface

</td>  
<td>

_-_

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

If data is not yet accessible, how can they be retrieved?

</td>  
<td>

Describe the architecture and where the probe can deployed

</td>  
<td>

TBD

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

Probe development requirements

</td>  
<td>

TBD

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

Usable software API on device

</td>  
<td>

TBD

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

1.5.3.3 Data access

1.5.3.4 Data description

Data format _NetFlow, pcap, syslog, json (when an interface is used, the
format of embedded data is needed to be described)_

 Application data / Context data o _ROS is available at the moment, but this
is moreso for development purposes, JSON to be implemented,_  
  
<table>  
<tr>  
<th>

</th>  
<th>

_however we are quite flexbile in relation to how the data is captured to a
file._

o At Cloud level: FIWARE NGSI model

( _http://fiware.github.io/context.Orion/api/v2/latest/_ )

 Traffic data

o Pcap files  Syslogs

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

Encryption

</td>  
<td>

Yes, communication between all the components will rely on secure
communication protocols, i.e., HTTPS.

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

Data format description

</td>  
<td>

_Syntax and semantics of data (very important for non-standard formats, e.g.
describe the columns of a csv file, or the structure and semantics of what
contains a JSON file)_

  * Application data / Context data 

    * _ROS is available at the moment, but this is moreso for development purposes, JSON to be implemented, however we are quite flexbile in relation to how the data is captured to a file._

  

    * At Cloud level: FIWARE NGSI model 

  

  

( _http://fiware.github.io/context.Orion/api/v2/latest/_ )

  * Traffic data 

    * Pcap files 

  

  

  * Syslogs 

  

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

For unusual format, tool to read it

</td>  
<td>

TBD

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

Dataset generation

</th>  
<th>

Was the data monitored in a system with real users?

</th>  
<th>

We are

_1._

</th>  
<th>

analysing several options:

_To use synthetic data generated by a simulator tool_

_(_http://www.dlr.de/ts/en/desktopdefault.aspx_ _

__/tabid-9883/16931_read-41000/_ ) _

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

</td>  
<td>

</td>  
<td>

_2._

</td>  
<td>

_To use real data:_

_a._ _Logs from vehicles and / or near-realtime streaming of data._

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

</td>  
<td>

If no, how the data has been generated?

</td>  
<td>

TBD

</td>  
<td>

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

Attack

</td>  
<td>

Does the dataset contain attacks?

</td>  
<td>

No

</td>  
<td>

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

If yes, are the attack labeled?

</td>  
<td>

_-_

</td>  
<td>

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

If yes, what is

the

granularity of the labels?

</td>  
<td>

_-_

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

Dataset statistics

</td>  
<td>

TBD

</td>  
<td>

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

Sample of data

</td>  
<td>

TBD

</td>  
<td>

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

Is the data open publicly?

</th>  
<th>

No

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

1.5.3.5 Data restrictions  
  
<table>  
<tr>  
<th>

If no, is there a plan to make data open?

</th>  
<th>

No

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

If no, will the data be accessible to the consortium, or to specific
partner(s)?

</td>  
<td>

Yes, whole consortium

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

If yes, for how long?

</td>  
<td>

End of project

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

Can the data be used for public dissemination (without revealing the full
content of the data, aggregated view)

</td>  
<td>

No

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

Who owns the data?

</td>  
<td>

IDIADA / ATOS

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

Legal issues

</td>  
<td>

We have identified that there may be some legal issues regarding the collected
data. For instance, the GPS position of the vehicle (indirect identification),
a vehicle identification number… Therefore, the data could lead to single out
car driver.

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

#  Data Access and Sharing

Due to the nature of the data involved, some of the results that will be
generated by each project phase will be restricted to authorized users, while
other results will be publicly available. As is our commitment, data access
and sharing activities will be rigorously implemented in compliance with the
privacy and data collection rules and regulations, as they are applied
nationally and in the EU, as well as with the H2020 rules. In the case end-
user testing will be performed, SecureIoT users would be required to pre-
register and consent using the system. Then they will need to authenticate
themselves against a user database. If successful, the users will have roles
associated with them. These roles will determine the level of access that a
user will be given and what they will be permitted to do.

As the raw data included in the data sources will be gathered from the closed
and controlled SecureIoT environment, collected measurements will be seen as
highly commercially-sensitive. Therefore, access to raw data can only take
place through the partners involved in the project. For the data analytic
models to function correctly, the data will have to be included into the
SecureIoT databases. The results of the IoT data collection and analysis will
be secured and all privacy concerns will be catered during the design phase.
In the cases of trend analytics, anonymization methods will be applied as part
of the built-in cloud platform features.

,

Publications will be released and disseminated through the project
dissemination and exploitation channels to make external research and market
actors aware of the project as well as appropriate access to the data.

Within the project, our produced conference papers and journal publications
will be Green Open

Access and stored in an appropriate repository – such as OpenAIRE (European
Comission, 2015) Registry of Research Data Repositories (German Research
Foundation, 2015) or Zenodo (CERN Data Centre, 2015).

#  Data Management Plan Checklist

At the end of the project, we will be carrying out the following checklist to
ensure that we are meeting the criteria to have successfully implemented an
Open Access Data Management Plan. The required KPIs will be updated in
subsequent versions of this document. By adhering to the items below, we are
confident that the project will provide open access to the appropriate data
and software, and thereby, enable researchers to utilize the findings of this
project to further expand their knowledge capacity and personal gains as well
as to provide the IoT industry with the necessary tools to advance their
business and processes.

  1. Discoverable: 

    1. Are the relevant data that are to be made available, our project publications or any Open software that has been produced or used in the project, easily discoverable and readily located? 

  

    2. Have we identified these by means of a standard identification mechanism? 

  
  

  

  2. Accessible: 

    1. Are the data and associated software in the project accessible, where appropriate, and what are the modes of access, scope for usage of this data and what are the licensing frameworks, if any, associated with this access (e.g. licensing framework for research and education, embargo periods, commercial exploitation, etc.)? 

  
  

  

  3. Useable beyond the original purpose for which it was collected: 

    1. Are the data and associated software, which are made available, useable by third parties even after the collection of the data? 

  

    2. Are the data safely stored in certified repositories for long term preservation and curation? 

  

    3. Are the data stored along with the minimum software, metadata and documentation to make them useful? 

  
  

  

  4. Interoperable to specific quality standards: 

    1. Are the data and associated software interoperable, allowing data exchange between researchers, institutions, organizations, countries, etc. (e.g. adhering to standards for data annotation, data exchange, compliant with available software applications, and allowing re-combinations with different datasets from different origins)? 

  
  

  

  

#  Conclusions

This deliverable has provided an initial framework on how to build the data
collecting - and sharing plan during the course of the SecureIoT project and
after the project will be finished. This plan will be updated as the project
progresses, addressing issues such as dataset repository management and
hosting of datasets after the end of the project, also considering public
repositories. This deliverable is regarded as a live document which will be
updated incrementally as the project progresses. This version sets the overall
framework that will form the basis for two additional iterations on M18 and
M36, towards the overall delivery of a comprehensive document at the end of
the project.

In this version of the deliverable, we outlined the descriptions of the Use
Case related Datasets, which are still in development and data access aspects
have been addressed.

The upcoming revisions of this deliverable will focus -among other- to a
fuller presentation of the datasets, description of the SecureIoT data models,
update of data access and sharing and update of data interoperability
priorities.