EXECUTIVE SUMMARY / ABSTRACT

According to the task T9.3 of WP9, a Data Management Plan (DMP) should be
outlined and delivered by M06. The present report is focused on the
preparation of the Data Management Plan (DMP) for ROSSINI and aims to define
the guidelines that the project consortium will follow to manage the data
generated within the project, to protect them and to guarantee their
availability for other researchers. In particular, DMP will define how this
data will be managed and shared by the project partners, and also, how this
information will be updated and preserved during and after the project
duration. The building of the DMP started at the proposal stage when the good
research data management was addressed under the impact criterion, however all
partners will be responsible for updating the knowledge management system
periodically and will characterise their produced data to ensure that they
will be: discoverable (means of an identification mechanism such as Digital
Object Identifier), accessible (in what modalities, scope, licenses,
Intellectual Property Rights (IPR)), assessable and intelligible (they allow
third parties to make assessments about their reliability and the competence
of the creators), useable beyond the original purpose for which it was
collected are usable to third parties after the collection of the data for
long periods (repositories, preservation and curation) and interoperable.

SCOPE

The ROSSINI DMP describes the observed data that are collected and processed
during the life time of the project while providing the overview of available
research data, access, data management and terms of use. The DMP reflects the
current state of the discussions, plans and ambitions of the partners. It
includes the preliminary scenario of data set definitions and expected results
and will be updated and implemented with new datasets and results during the
lifespan of ROSSINI.

Moreover, ROSSINI project takes part to the Open Research Data Pilot (ORDP) in
Horizon 2020 that aims to improve access to and re-use of research data with a
special focus on the need to balance openness and protection of scientific
information.

ABBREVIATIONS  
  
<table>  
<tr>  
<th>

Data Management Plan

</th>  
<th>

DMP

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

Intellectual Property Rights

</td>  
<td>

IPR

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

Open Research Data Pilot

</td>  
<td>

ORDP

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

Key Performance Indicators

</td>  
<td>

KPI

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

European Commission

</td>  
<td>

EC

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

Findable, accessible, interoperable and re-usable data

</td>  
<td>

FAIR

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

European Union

</td>  
<td>

EU

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

General Data Protection Regulation

</td>  
<td>

GDPR

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

European Factories of the Future Research Association

</td>  
<td>

EFFRA

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

Simple Web-service Offering Repository Deposit

</td>  
<td>

SWORD

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

Human Robot Collaboration

</td>  
<td>

HRC

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

</td>  
<td>

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

**1**

</th>  
<th>

**Introduction**

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

Good data management is not a goal in itself, but rather is the key conduit
leading to knowledge discovery and innovation, and to subsequent data and
knowledge integration and reuse by the community after the data publication
process  1  . The amount of data generated by scientific research and research
projects continuously increase, however re-using the data for further research
purposes and thus maximising the benefit deriving from the research
investments still represents a hard challenge. The data needs to be properly
collected, annotated, filed in such a way that they will be available in the
long-term and can be re-used for downstream investigations, either alone, or
in combination with newly generated data.

**1.1 The Data Management Plan in H2020:**

According to the guidelines of the EC, the DMP is “the key element of good
data management. A DMP describes the data management life cycle for the data
to be collected, processed and/or generated by a Horizon 2020 project”.

There DMP is a document that outlines the procedures and methodologies of data
treatment during the project and how the data will be used and shared after
the project ends. It deals with the generation and discovery of the data,
their collection, evaluation by quality assurance, classification,
organization and documentation. Dissemination and sharing policies are also
addressed within the DMP.

The process of creation of the DMP respects some golden rules that ensure the
successful management of research data arising from the project. W. K.
Michener in his article “Ten Simple Rules for Creating a Good Data Management
Plan”  2  well outlines the building process of the DMP, which starts with the
identification of the data to be collected (1), followed by the definition on
how the data will be organized (2), documented (3), how data quality will be
assured (4), the strategy adopted to preserve and store the data collected
(5), the data policies adopted (6), ending with the rules for the
dissemination of the data and the appointment of the roles and
responsibilities of data management (7).

Even if having a clear vision of the nature of the data could be quite
challenging in the early phases of the project, when the ROSSINI DMP is
released, the plan will include the characterization of the data collected:  
  
<table>  
<tr>  
<th>

−

</th>  
<th>

the types of data: text, spreadsheets, software, algorithms, pictures, videos,
audio files;

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

−

</td>  
<td>

the volume of data: data management activities might be influenced by the
number of the data to be handled;

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

−

</td>  
<td>

sources: stakeholders or research centers that wish to re-use the data
generated by the project are interested in the source of the data, if they are
proprietary, derive from other research studies, are subject to restrictions
or can be freely used;

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

−

</td>  
<td>

data and file formats: non-proprietary formats are preferred as they ensure
the accessibility to the data for the long term; examples could be Comma
Separated Values [CSV].

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

The DMP is a living document that must be revised during the project.
Therefore, if some of the above-mentioned information are not clear and known
yet at M06, the contents will be updated with the missing data.

The definition of the **way** the **data** will be **organized** should be
addressed as well and it is strongly influenced by the volume of the data
generated and used within the project. Larger data volumes and usage
constraints may require the use of relational database management systems
(RDBMS) for linked data tables like ORACLE or mySQL, or a Geographic
Information System (GIS) for geospatial data layers like ArcGIS, GRASS, or
QGIS, while a small number of data could be effectively managed with
commercial or open source spreadsheet programs like Excel and OpenOffice Calc.
2  The data organization will be defined once a clear scenario of the types of
data and the volume of data collected within the project will be made clear.

The documentation of the data by means of proper **metadata** is fundamental
to ensure that data will be discoverable, usable and properly cited by those
ones who will look for them and use them for further research purposes.
Indeed, metadata means "data about data". Metadata is defined as the data
providing information about one or more aspects of the data; it is used to
summarize basic information about data which can make tracking and working
with specific data easier.  3  In the this project, structural and descriptive
metadata will be deployed to define formats, types, versions and relationships
between digital data and to identify the data through some of their
characteristics, like data of collection, volume, name, authors/owners and
keywords.

Once the whole vision of data collected will be clear, the project will state
the guidelines and the approaches to be followed to perform quality control
and quality assurance checks, that should guarantee the measurement and
improvement of the quality of the results of the project.

**Data storage and preservation strategy** will be an important topic that the
DMP will address, by answering to the following questions:

− How long will the data be accessible?

− How will data be stored and protected over the duration of the project?

− How will data be preserved and made available for future use?

The answers to those questions are expected to vary from one partner to
another due to several factors. The internal data policy of each partner will
influence the possibility to make some of the research data collected public
or not. Moreover, if the partners will make the data available to be consulted
by other researchers after the end of the project, the storage may depend on
the type of data generated, indeed some of them may need to be kept for a
short time as they are extremely repeatable, while if they are strongly
variable from one experiment to another might need to be stored for a very
long time. The data that will receive the authorization by the owners to be
published and available for others to use will be stored within online
collaborative platforms accessible by the project consortium and will also be
uploaded on online repositories like Zenodo (  _http://zenodo.org/_ )  .

The DMP will also include explicit **policy statements** about how data will
be managed and shared. Such policies include the licensing or sharing
arrangements that pertain to the use of preexisting materials; the plans for
licensing, sharing, and embargoing (i.e., limiting use by others for a period
of time) data, code, and other materials; the legal and ethical restrictions
on access and use of human subject and other sensitive data. The policies will
be in line with what has been stated in the Consortium Agreement with respect
to the Intellectual Property Rights (IPr) and the joint ownership of the
results and the data beyond them, and to what the Ethics Requirements
deliverables report with regards to the Personal Data treatment and the
treatment of data deriving from the involvement of humans beings in the
project experiments.

The IPR and non-disclosure statements will be very important for the
dissemination actions taken by the project partners. The DMP will be compliant
with the statements of the Consortium Agreement (CA) and the Ethics
Deliverables in defining when, how and which data will be made available.
Dissemination actions will range form posting the data on social media and the
project website, to publishing the data in online repositories (like Zenodo)
and in scientific journals.

##  1.2 Open Research Data Pilot

Since 2017, all the thematic areas of the H2020 programme have been included
in the work programme Open Research Data Pilot (ORD Pilot) which is a flexible
pilot on open access to research data and scientific publication in H2020. The
pilot considers the need to balance the possibility to make the data open with
the protection of scientific information, commercialisation and Intellectual
Property Rights (IPR), privacy concerns, and security, as well as questions of
data management and preservation.

The Europe H2020 strategy for a smart, sustainable and inclusive economy
underlines the central role of knowledge and innovation in generating growth.
The reason for the creation of the ORD Pilot is that the free access to
scientific publications and data should improve the quality of the results on
which further research will hopefully be built, encourage collaboration and
avoid duplication of efforts, speed up the entrance of the results into the
market and should boost and underline the benefits of public investments in
research funded under the H2020 programme also among citizens and society  4
.

From a high-level perspective, open access (OA) consists in providing on-line
access to scientific information free of charge to the users to promote the
reusability of the data. Within the context of the R&D actions there are two
main categories of data that OA addresses: the scientific papers and the
research data collected from the experiments conducted in the laboratories.
Research data refer in particular to facts or numbers, collected to be
examined and considered as a basis for reasoning and discussion on project
results, examples include statistics, results of experiments, measurements,
observations resulting from fieldwork, survey results, interview recordings
and images. The focus is on research data that is available in digital form.

Indeed, the ORD Pilot run by the European Commission applies to the datasets
at the basis of scientific publication and to the peer reviewed papers
released within the context of the H2020 projects. According to the Budapest
declaration (2002) and Berlin Declaration (2003), within the context of ORD
Pilot, open access means not only the basic rights to download, save and print
a document, but also to copy, distribute, search, link, crawl and mine data.
The DMP will be useful to state which type of data will be made available and
which restriction may apply to some data.

The two main routes to open access are  5  :  
  
<table>  
<tr>  
<th>

−

</th>  
<th>

**Self-archiving / 'green' open access** – the author, or a representative,
archives (deposits) the published article or the final peer-reviewed
manuscript in an online repository before, at the same time as, or after
publication. Some publishers request that open access be granted only after an
embargo period has elapsed.

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

−

</td>  
<td>

**Open access publishing / 'gold' open access** \- an article is immediately
published in open access mode. In this model, the payment of publication costs
is shifted away from subscribing readers. The most common business model is
based on one-off payments by authors. These costs, often

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

referred to as Article Processing Charges (APCs) are usually borne by the
researcher's university or research institute or the agency funding the
research. In other cases, the costs of open access publishing are covered by
subsidies or other funding models.

According to the Article 29.2 of the Grant Agreement, under H2020 “each
beneficiary must ensure open access to all peer-reviewed scientific
publications relating to its results”. Following the recommendation of the EC,
ROSSINI project is participating on the Open Research Data Pilot and the DMP
is considered as a Deliverable (D.9.3) due in M06.

To ensure visibility and openness of ROSSINI resources, some platforms have
been considered to be used, where general public, researchers and other
investigators can discover and download information, data and documents on the
project’s results. The platforms and widely used research data repositories
that are considered for ROSSINI, which allow research stakeholders to search
and retrieve vilely open and all types of data that are uploaded by other
researchers, are Zenodo and EC’s OpenAIRE platform. Furthermore, the EFFRA
Innovation Portal is also taken into consideration since being provided by the
European Factories of the Future Research Association (EFFRA), is a unique
resource database combining various projects’ databases’ information about the
latest projects’ outputs, together with reports and demo materials.

##  1.3 Objectives of the Data Management Plan

The overall objective of ROSSINI project is to develop a disruptive,
inherently safe hardwaresoftware platform for the design and deployment of
human-robot collaboration (HRC) applications in manufacturing. The research
lines of ROSSINI project will address several points: sensing (smart sensors
for quickening sensors response), control (safety aware control architecture
to reduce robot task execution time), actuation (collaborative robot
manipulation), human factors (human-robot interactions) and risk assessment.
The research lines will be combined into 3 demonstrators (white goods,
electronic equipment, and food packaging).

Thus, the purpose of ROSSINI DMP is to define the management of project
research data that are collected from the smart sensors, log of informatic
systems and data derived from the metrics that will be used to evaluate the
job quality in the use cases.

The plan is intended as a roadmap illustrating how data arisen from project
research lines will be treated throughout the project lifetime and beyond,
once it will be finished. ROSSINI DMP will provide a vehicle for conveying
information to and setting expectations for the project team during the
different stages of project, especially when the project is underway. The plan
will be a living document that is periodically reviewed and revised as
necessary according to the new data gathered, the needs and any changes in
protocols (e.g., metadata, QA/QC, storage) and policies.

##  1.4 ROSSINI Data Management Plan: General description

The present report is focused on the preparation of the Data Management Plan
(DMP) for ROSSINI project to be delivered at M06. The DMP provides an analysis
of the main elements of the data management policy that will be used
throughout the project with regard to all the datasets that will be generated.
In particular, DMP will define how this data will be managed and shared by the
project partners, and also, how this information will be updated and preserved
during and after the project duration and made available after the end of the
project.

The DPM of the ROSSINI project has been prepared following the template
provided by the European Commission of the “ _Guidelines on Data Management in
H2020_ ”.This document will be updated and augmented with new datasets and
results according to the progress of activities of ROSSINI project. Also, the
plan will be updated including changes in consortium composition and policies
over the course of the project. The procedures that will be implemented for
data collection, storage and access, sharing policies, protection, retention
and destruction will be according to the requirements of the national
legislation of each partner and in line with the EU standards.

The first part of the DMP will assess the types of data collected, their
origin, their dimension, the purpose for gathering them and how they are going
to be reused. Moreover, as part of making research data findable, accessible,
interoperable and re-usable (FAIR), ROSSINI DMP should include information on:
(i) how data will be collected, processed and/or generated: which will be the
metadata describing them, which numbers and keywords will make them findable;
(ii) which methodology & standards will be applied; (iv) whether data will be
shared/made open access: which methods or software tools will be needed to
access the data; (v) how data will be curated & preserved (including after the
end of the project); how data will allow their exchange and re-use: standard
vocabularies used, common ontologies, mappings to more common ontologies,
definition of which data might be used by third parties after the project and
which quality assurance strategies an processes will be followed. Finally the
plan will focus on the costs to be incurred for making data FAIR and the roles
and responsibilities for Data Management within the project.

The M06 version of the DMP is only a preliminary plan since the effective
phase of the project has just started and the scenario of the types, formats,
dimension od data is still not clear and complete. Moreover, some strategies
for collection, classification and organization of the data are still object
of discussion among the partners.

The DMP is intended as a living document that will be kept constantly updated
with more detailed breakdown as the project progresses and knew knowledge and
results will be achieved.  
  
<table>  
<tr>  
<th>

**2**

</th>  
<th>

**Data Sets identification**

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

##  2.1 Register on numerical data sets generated or collected in ROSSINI

The intention of the DMP is to describe numerical model or observation
datasets collected or created by ROSSINI project. Since the project is at its
very beginning, there is not yet any dataset generated or collected until the
delivery date of this DMP. However, the register on numerical data sets has to
be understood as a living document, which will be updated regularly during
project lifetime.

The information listed below reflects the conception and design of the
individual partners in the different work packages at the beginning of the
project. The data register will deliver information according to information
detailed in Annex 1 (Part A) of the Grant Agreement Document (GA):

  * Data set reference and name: identifier for the data set to be produced. 

  

  * Data set description: descriptions of the data that will be generated or collected, its origin or source (in case it is collected), nature, scale, to whom it could be useful and whether it underpins a scientific publication. Information on the existence (or not) of similar data and the possibilities for integration and reuse. 

  

  * Partners activities and responsibilities: partner owner of the device, in charge of the data collection, data analysis and/or data storage, and WPs and tasks it is involved. 

  

  * Standards and metadata: reference to existing suitable standards of the discipline. If these do not exist, an outline on how and what metadata will be created. Format and estimated volume of data. 

  

  * Data exploitation and share: description of how data will be shared, including access procedures and policy, embargo periods (if any), outlines of technical mechanisms for dissemination and necessary software and other tools for enabling re-use, and definition of whether access will be widely open or restricted to specific groups. Identification of the repository where data will be stored, if already existing and identified, indicating in particular the type of repository (institutional, standard repository for the discipline, etc.) and if this information will be confidential (only for members of the Consortium and the Commission Services) or public. In case of dataset cannot be shared, the reasons for this should be mentioned (e.g. ethical, rules of personal data, intellectual property, commercial, privacyrelated, security-related). 

  

  * Archiving and preservation (including storage and backup): description of the procedures that will be put in place for long-term preservation of the data. Indication of how long the data should be preserved, what is its approximated end volume, what the associated costs are and how these are planned to be covered. 

  

Such data can be anonymised for statistical or other purposes and shared with
open access, which could be further analysed and provide the possibility to
extract information and knowledge from them. Each dataset can be accompanied
by several metadata (e.g. type, gender, age, etc.) which can support various
kinds of historical data analysis.

**2.1.1 Data set per partner**

All partners have identified the data that will be produced in the different
project activities and have provided an overview on the nature and details for
each dataset as listed below.

#  Table 1, Datalogic dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Besides the project documentation (mainly made of SW source codes, schematics,
drawings and MS Office documents) we will collect sequences of sensor data
including 2D or 3D images, safety laser scanner measurements and safety radar
traces.

The datasets will be used exclusively for the development of our data
processing algorithms.

Stored datasets will allow both off-line development and for nonregression
tests.

IRIS may need some dataset for the same purpose.

Each set will contain from one to many tens of acquisitions, i.e. from a few
MBytes to some hundreds of MBytes.

As images will contain pictures of human operators (typically a Datalogic
developer) they will be considered personal data and be, by default,
confidential. Laser scans and radar traces will not be considered personal
data even if capturing human beings.

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

**Provenance of data: sources**

</td>  
<td>

All the data will be acquired using 2D or 3D cameras (both commercial and our
prototypes), Datalogic safety laser scanners and Pilz safety radar prototypes.

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

**Nature and formats of data**

</td>  
<td>

A dataset will be a sequence of images and/or scans and/or radar traces saved
in the same directory.

2D images will be saved in a standard lossless format like BMP or TIFF.

3D images will be saved in standard format too, e.g. PCL.

Data coming from laser scanners or from the radar prototypes will be saved in
a raw binary format.

All data will be tagged with an acquisition timestamp.

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

**New data set value**

</td>  
<td>

The safety and robot control algorithms that will be developed in the Rossini
project will start from the data acquired by a set of safe (RS4) and non-safe
sensors.

Developing the algorithms using real sensors in a real world has the advantage
of generating a huge variety of cases, but requires the continuous
availability of a real (or, at least, realistic) environment. Saving sequences
of acquisitions will allow the developers to work off-line and to use
repeatable sequences for non-regression tests.

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

**Audio-visual material**

</td>  
<td>

Considering that each image has a size of 1-3 Mbytes, we plan to acquire up to
1-2 TByte of data.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

Datalogic (2D and 3D images and laser scans) and, maybe, Pilz (radar traces)

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

Datalogic (2D and 3D images and laser scans) and, maybe, Pilz (radar traces)

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

Datalogic and, on request, IRIS

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

Datalogic and, on request, IRIS

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

**WPs and tasks**

</th>  
<th>

Data will be collected using sensors from WP3, and will be used for the
development of the algorithms of WP3 and WP4.1

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

Only a textual description of each dataset will be provided. The description
will include the working cell, the environmental data (e.g. lighting
conditions), the type of sensors and their setup.

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

**Methodology for data collection/generation**

</td>  
<td>

Datalogic (or Pilz) will collect the data recording brief sequences of
acquisitions of a realistic work situation.

The data will be stored in a company network server and will be available for
the developer for future use.

Datalogic will collect the datasets and store them in an internal network
space with a limited access.

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

When a Datalogic developer will need a dataset, he will download it from the
network and use it to feed his algorithms.

On request, some datasets will be transferred to IRIS using secured channels.

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

**Data ownership**

</td>  
<td>

The owner of the data will be the company that acquired it. No pre-existing
data will be used

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

**Suitability for sharing**

</td>  
<td>

All images will be considered confidential by default. Other type of data can
potentially be shared, at least inside the Consortium.

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

**Data utility**

</td>  
<td>

Datalogic developers working on Rossini will have full access to the datasets.

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

**Open research data pilot**

</td>  
<td>

No

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

**Embargo periods (if any)**

</td>  
<td>

N.a.

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

A dataset will be a sequence of images and/or scans and/or radar traces saved
in the same directory together with their description. Datasets will be saved
in a company fileserver and periodically backed-up as from Datalogic IT
policy.

In case of need, copies of the datasets will be downloaded on the developer
PCs for fastest access and removed when not useful any more. Access to
developer PCs require personal logins as from Datalogic IT policy.

Should some datasets be shared with IRIS they will be transferred via a
password protected link, e.g. FTP or an encrypted archive on a large file
sharing platform to be defined.

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

**Data Storage**

</td>  
<td>

Only a selection of the acquired datasets will be stored on the network
servers.

Most of the datasets will be deleted at the end of the project. The most
peculiar datasets might be maintained as a reference for future product
developments.

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

#  Table 2, Pilz dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

The information and state of the environment will be captured by both safe and
non-safe sensors of T3.1 and T3.3 and transformed into a data set that can be
sent by the bus T3.4 to the system T3.5 and this can be able to understand and
manage.

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

**Provenance of data: sources**

</td>  
<td>

Vision sensors (T3.1). Capacitive, tactile and radar sensor (T3.3)

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

**Nature and formats of data**

</td>  
<td>

Protocol for the bus will be discussed and nature of data too

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

**New data set value**

</td>  
<td>

n/a

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

**Audio-visual material**

</td>  
<td>

No video planed for Sensors of T3.3

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

Partner of the project owner of the device/software producing the data

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

WP3 T3.3, T3.4, T3.5

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

To be defined: In the data documentation will be define the protocol for the
communication between the sensors of T3.1 and T3.3 and the system designed in
T3.5

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

**Methodology for data collection/generation**

</td>  
<td>

To be discussed

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

The data of sensing Layer will be sent to perception layer where a decision
will be made about safety relevant issues

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

**Data ownership**

</td>  
<td>

Who is the owner of the data?

To be discussed

Is another organization contributing to the data development? No Are you re-
using some pre-existing data?

No

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

**Suitability for sharing**

</td>  
<td>

Public/confidential/limited access

All data from Sensors is only relevant for the next Layer.

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

**Data utility**

</td>  
<td>

How will this data shared/made accessible for verification and re-use The data
from sensors have to be check before to be sent to the next Layer. .

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

**Open research data pilot**

</td>  
<td>

Can data be uploaded in an open research data pilot? When?

No

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Please describe the modality of:

  * storage; 

  

  * backup; 

  

  * transmission; 

  

  * data processing in the short and medium term, with references to practices, standards and regulations where applicable. 

  

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

</td>  
<td>

Transmission per Bus to the next Layer

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

**Data Storage**

</td>  
<td>

Please indicate:

  * where data will be stored 

  

  * if the conservation concerns the whole collected data or only part of them, 

  

  * for how long data will be stored 

  

Not relevant for this type of data

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

#  Table 3, Unimore dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Data about position/velocity and about the nature of the objects detected
(e.g. human/object). The data will be quantitative.

The data will be needed for implementing a dynamic controller for the robot.

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

**Provenance of data: sources**

</td>  
<td>

(Processed) Sensor data

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

**Nature and formats of data**

</td>  
<td>

Describe nature and format of data:

  5. structured data (HTML, JSON, TEX, XML, RDF); 

  

  6. tables (CSV, ODS, TSV, XLS, SAS, Stata, SPSS portable); 

  

  

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

**New data set value**

</td>  
<td>

No new data set will be created

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

**Audio-visual material**

</td>  
<td>

Video will be done for dissemination purpose. The duration of the video Is
that of the project.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

Partner of the project owner of the device/software producing the data

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

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

**Methodology for data collection/generation**

</td>  
<td>

The data will be collected by sensors, post-processed and then sent to the
scheduler/planner/controller for deciding the inputs to provide to the robot

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

Use for control of the robot.

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

**Data ownership**

</td>  
<td>

The data will be produced and used in our labs

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

**Suitability for sharing**

</td>  
<td>

Public

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

**Data utility**

</td>  
<td>

Plots in technical documents/scientific publications

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

**Open research data pilot**

</td>  
<td>

No

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Data will be collected by sensors, processed and used for computing the input
to provide to the robot. Data will be transmitted either by cabled or wireless
communication. The processing happens through scheduling/planning/control
algorithms.

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

**Data Storage**

</td>  
<td>

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

#  4, IRIS dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

In the case of our Tasks 4.1 (Semantic Scene Map) the purpose is to merge the
data collected by the sensors in order to build the semantic scene map. The
main purpose of the semantic scene map is to produce a map of the working
environment including the safety areas available from the environment
representation.

The purpose of the data collection is uniquely to process the information
coming from the sensors to build the semantic scene map. Active learning
algorithms can be used to reduce the labelling quantity. Synthetic data can be
generated through simulation software to compensate for the possible lack of
real data. The results may be stored in order to be available for other layers
of the architecture developed by the partners.

In the case of Task 7.2 (Implementation of the design tool) the scope is to
develop a desktop-based design tool starting from existing one, integrating
libraries, tools, algorithms and model specific for the ROSSINI project. The
data used for this task will be mainly generated by the software itself, and
will be used for testing purpose. The size of data depends on the source. A 3D
camera can generate a consistent volume of data, while a proximity sensor
doesn’t produce high data rates. Since the data will be merged, after the
merging process we can expect high volume of data.

The data will be in majority quantitative sensor readings, x,y,z coordinates,
as well as movement measurements (speed, acceleration). The magnitude will be
determined once we have real data but as it will represent coordinates and
movement in the work cell it will be neither very large nor very small.

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

**Provenance of data: sources**

</td>  
<td>

Mainly data from the sensors. Since the sensors implemented can be of
different types, potentially many kinds of data can be produced. In our case
the data are not coming directly from the sensors, but preprocessed and
merged.

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

**Nature and formats of data**

</td>  
<td>

  1. text documents mainly in PDF, ODT DOC, and DOCX 

  

  2. images JPG, SVG, PNG 

  

  3. audio recordings MP3, WAV, OGG 

  

  4. structured data HTML, JSON, TEX, XML 

  

  5. tables CSV, ODS, XLS, XLSX 

  

  6. source codes C, C++, CSS, Python 

  

  7. configuration data CONF 

  

  8. database MySql 

  

  

The expected data formats are types d), e) and h).

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

**New data set value**

</td>  
<td>

We will add semantic labels to the sensor data, especially the “point clouds”
of the LiDAR data, in order to identify the objects with human meaningful
identifiers as well as behaviour identifiers (esp. directional movement) This
will be passed to the “cognitive layer” of the Rossini platform, which will
use this information to plan actions for the robot.

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

**Audio-visual material**

</td>  
<td>

No videos are considered at this stage

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

DATALOGIC

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

**Partner in charge of the data collection**

</td>  
<td>

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

**(if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

The hardware manufacturers (robot, sensors, …) will each have their standards,
especially with respect to safety, and the relevant ones will be established
during the project.

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

**Methodology for data collection/generation**

</td>  
<td>

  1. Who and how it collects data; 

  

  

The sensor data is collected by the sensor owners (Pilz, Datalogic, …) and
will be captured by activating the sensors and storing their streaming data
onto a server.

  2. Who and how it structures and stores them; 

  

  

Each sensor may have different format sothis will be unified into a common
structure.

  3. Who and how he processes them; The WP3 and WP4 partners. N/A 

  

  

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

The data will be used to plan and execute a safety work cell for human robot
collaboration in an industrial working environment.

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

**Data ownership**

</td>  
<td>

Data produced are stored and accessible to the whole consortium. External
access can be granted to third parties upon identification and signature of
NDA.

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

**Suitability for sharing**

</td>  
<td>

Data not marked as confidential, will be public

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

**Data utility**

</td>  
<td>

The data that are not supposed to be used or visible outside of the system,
will be in a specific format to satisfy efficiency and safety requirements.
Data that are supposed to interact with external systems will be easy to
access and saved in standard formats

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

**Open research data pilot**

</td>  
<td>

To be defined.

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Backup of datasets exists in IRIS’ internal repository. Access to those is
restricted only to authorized personnel or to project beneficiaries needing
access rights. The data will be available for indefinite time and curated
until 2 years upon project conclusion.

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

**Data Storage**

</td>  
<td>

Backup of datasets exists in IRIS’ internal repository. Access to those is
restricted only to authorized personnel or to project beneficiaries needing
access rights.

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

#  5, SUPSI dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Project technical documents: CAD files, Data-sheets, Bill Of Materials, Gantt
diagrams, Operating manuals, Software Packages, Source code, Electrical
diagrams, Data logs.

Other documents: Pictures, Videos, Meetings minutes, Contact lists, Posters,
Flyers and Presentations, Papers, Deliverables.

Nature of data: digital.

Order of magnitude: ≥40GB (prediction)

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

**Provenance of data: sources**

</td>  
<td>

Project technical documents sources: engineer’s workstations, machines control
systems, Internet.

Other documents sources: internal realization for documentation or promotional
purposes.

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

**Nature and formats of data**

</td>  
<td>

Describe nature and format of data:

  1. text documents (DOC, PDF, TXT); 

  

  2. images (JPG, GIF, PNG, TIFF); 

  

  3. video (MPEG, AVI, WMV, MP4); 

  

  4. structured data (HTML, XML); 

  

  5. tables (CSV, XLS); 

  

  6. source codes (C, C#, JavaScript, Java); 

  

  7. configuration data (INI, CONF) 

  

  8. database (MySql) 

  

  

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

**New data set value**

</td>  
<td>

\-

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

**Audio-visual material**

</td>  
<td>

Max 5 min each.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

SUPSI

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

\-

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

\-

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

\-

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

**WPs and tasks**

</td>  
<td>

WP5 – Collaborative by Birth Robot Arm

T5.2 – T5.3

WP6 – Human-Robot Mutual Understanding

T6.4-T6.5

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

The data are stored in SUPSI Instory (SUPSI INSTitutional repositORY), the
online institutional archive of publications related to the research and
didactic work conducted by the University of Applied Sciences and Arts of
Southern Switzerland.

All data in Instory are provided with metadata.

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

**Methodology for data collection/generation**

</td>  
<td>

  1. Who and how it collects data: WP responsible, collecting them in local folders 

  

  2. Who and how it structures and stores them: the Project Manager, regularly uploading the collected data in the Insory repository. 

  

  

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

</td>  
<td>

  3. Who and how he processes them: SUPSI researchers and Project Partners, obtaining access to the SUPSI Instory. 

  

  4. Who and how he distributes them: SUPSI researchers, giving external access to Instory. 

  

  

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

SUPSI collected data will be used for:

  * the engineering of a collaborative “by birth” robot arm 

  

  * the development of new technologies for human-robot and robot-human communication 

  

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

**Data ownership**

</td>  
<td>

Data owner is SUPSI.

Project partners can contribute to the data development.

Pre-existing data coming from other projects can be re-used.

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

**Suitability for sharing**

</td>  
<td>

Limited access

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

**Data utility**

</td>  
<td>

Academic researches, Project partners, Scientific community

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

**Open research data pilot**

</td>  
<td>

Data can be uploaded in an open research pilot, normally at the end of the
project.

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Data are encrypted and stored on a server.

Regular backup of data is automatically executed on the server. Data are
transmitted by giving password-protected access to the repository.

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

**Data Storage**

</td>  
<td>

The whole collected data are stored on the SUPSI repository for an unlimited
period.

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

#  6, TNO dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Observational and experimental data from the experimental setup in each Use
Case.

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

**Provenance of data: sources**

</td>  
<td>

Informed consent, questionnaires and objective measurements.

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

**Nature and formats of data**

</td>  
<td>

Observational and experimental data in TXT, CSV, JPEG, AVI

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

**New data set value**

</td>  
<td>

New dataset to be analyzed in WP06 (Human-robot mutual understanding)

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

**Audio-visual material**

</td>  
<td>

In case of video, indicate the duration: <30 min

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

Partner of the project owner of the device/software producing the data

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

n/a

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

**Methodology for data collection/generation**

</td>  
<td>

n/a

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

n/a

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

**Data ownership**

</td>  
<td>

n/a

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

**Suitability for sharing**

</td>  
<td>

n/a

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

**Data utility**

</td>  
<td>

n/a

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

**Open research data pilot**

</td>  
<td>

n/a

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

n/a

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

**Data Storage**

</td>  
<td>

n/a

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

#  Table 7, Fraunhofer IFF dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Fraunhofer IFF expects to gather quantitative data from collision tests with
robots. The tests will be necessary to evaluate the proposed method of
transforming results from collision tests. The amount of data will probably in
the range of 10 to 20 GB that corresponds with data sets from 500 to 1000
particular measurements.

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

**Provenance of data: sources**

</td>  
<td>

The data come from collision tests with robots.

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

**Nature and formats of data**

</td>  
<td>

The test data may include drawings (PDF), images (JPG, PNG), footage (MP4),
tables (MAT, CSV, XLSX), and reports (PDF, DOCX). It is also likely that
source code from robot programs will belong to the test data (depends on the
confidentiality of the data).

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

**New data set value**

</td>  
<td>

Fraunhofer IFF requires the data to evaluate its contribution in the project.
However, the data have also a benefit for the community. To certain extent,
they describe the robot behavior during a collision. This knowledge is
relevant for the development of verified collision models for instance as part
of a simulation environment used to plan and design application featuring
human-robot collaboration.

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

**Audio-visual material**

</td>  
<td>

Fraunhofer IFF cannot estimated the amount and duration of footage at this
point of the project.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

There are not partner when producing the data which do not belong to the
project. For the tests, Fraunhofer IFF will cooperate with Pilz. Hence, it is
very likely that Pilz will also record and gather data from the tests.

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

There are no applicable standards for the data which Fraunhofer IFF will
record in the ROSSINI project.

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

**Methodology for data collection/generation**

</td>  
<td>

Fraunhofer IFF will collect the data from collision tests with collaborative
robot. An investigator will structure and store the data. For data processing,
Fraunhofer IFF will use tools like MATLAB. It does not plan to distribute the
data. There are no applicable regulations for such data.

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

Not applicable

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

**Data ownership**

</td>  
<td>

Fraunhofer IFF will be the owner of the data from tests done in its
laboratory. It has no exclusive ownership for data from tests in which other
partners were involved.

It is planned to re-use data from former experiments with volunteers.
Fraunhofer IFF requires these data when developing the desired method that
transforms results from a collisions test with a fixed measurements device to
such of transient contact.

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

**Suitability for sharing**

</td>  
<td>

Limited access

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

**Data utility**

</th>  
<th>

By making a copy of the files.

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

**Open research data pilot**

</td>  
<td>

Data can be uploaded, if necessary.

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

**Embargo periods (if any)**

</td>  
<td>

No

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Fraunhofer IFF will store the data on a server with fully automated backup
system. Only employees of the business unit Robotic Systems, which are
involved in the ROSSINI project, will have access to the data. There are no
applicable standards or regulations for the data.

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

**Data Storage**

</td>  
<td>

Fraunhofer IFF plan to keep the data after the end of the ROSSINI project an
indefinite period.

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

#  Table 8, Whirpool dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Worker Description. Qualitative dataset

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

**Provenance of data: sources**

</td>  
<td>

Interviews and assessment

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

**Nature and formats of data**

</td>  
<td>

  1. text documents (DOC, ODF, PDF, TXT, etc); 

  

  2. images (JPG, GIF, SVG, PNG, TIFF); 

  

  3. video / film (MPEG, AVI, WMV, MP4); 

  

  

f) tables (CSV, ODS, TSV, XLS, SAS, Stata, SPSS portable);

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

**New data set value**

</td>  
<td>

Accurate description of the worker to enable enhanced human-robot interactions

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

**Audio-visual material**

</td>  
<td>

10’

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

WHR

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

WP8

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

NONE

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

**Methodology for data collection/generation**

</td>  
<td>

Data gathering and collection will be performed by WHR personnel under GDPR
policy. Data will be stored on a specific Team Drive created on Whirlpool
G-Drive cloud and accessed only by ROSSINI project members

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

To implement HRC

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

**Data ownership**

</td>  
<td>

WHR

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

**Suitability for sharing**

</td>  
<td>

Confidential

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

**Data utility**

</td>  
<td>

Access to data will be granted to ROSSINI partners

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

**Open research data pilot**

</td>  
<td>

NO

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

**Embargo periods (if any)**

</td>  
<td>

NO

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

GDPR internal policy

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

**Data Storage**

</td>  
<td>

WHR Team Drive (Private Google Drive)

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

#  9, Schindler dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Data may include: production and internal logistic layout production order
configuration data others to be defined

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

**Provenance of data: sources**

</td>  
<td>

Data come from interviews, archives, databases and / or other projects,
devices, machines.

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

**Nature and formats of data**

</td>  
<td>

All above fomats and, in addition to them, DWG and Visio format are possible.

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

**New data set value**

</td>  
<td>

To be defined.

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

**Audio-visual material**

</td>  
<td>

Duration of each video should be between 1 and 10 minutes.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

To be defined

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

To be defined

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

To be defined

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

\-

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

n/a

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

**Methodology for data collection/generation**

</td>  
<td>

To be defined

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

n/a

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

**Data ownership**

</td>  
<td>

Who is the owner of the data?

Schindler Supply Chain Europe

Is another organization contributing to the data development? No Are you re-
using some pre-existing data? Yes

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

**Suitability for sharing**

</td>  
<td>

Confidential/limited access

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

**Data utility**

</td>  
<td>

How will this data shared/made accessible for verification and re-use

To be defined

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

**Open research data pilot**

</td>  
<td>

Can data be uploaded in an open research data pilot? When?

No, they can’t.

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

Data will be stored and backed up in Schindler servers or in Cloud Schindler
certified services.

Information appears in many various forms such as:

· printed out or (hand-) written on paper

· stored on hard-disks

· transmitted through networks

· spoken in conversation or over the telephone

In any case information will be exchanged according to Schindler ON 0-08001
Information Security Group Policy.

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

**Data Storage**

</td>  
<td>

Data will be stored in a dedicated MS Teams repository called LOC Rossini
Project and they will be stored there for 5 years from the date of project
closure.

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

#  10, IMA dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Data collection:

  * Quantitative coming mainly from the IMA tea bags machines. 

  

  * Quantitative coming from the IMA robotic application already on stage. 

  

  * Qualitative to describe the different tasks the robotic platform has to perform. 

  

Data generation:

  * Quantitative coming from the Rossini sensing system. 

  

  * Quantitative and qualitative for KPI evaluation. 

  

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

**Provenance of data: sources**

</td>  
<td>

IMA tea bags machine C24-E.

IMA robotics projects.

Rossini robotic platform.

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

**Nature and formats of data**

</td>  
<td>

  1. text documents (DOC, ODF, PDF, TXT, etc); 

  

  2. images (JPG, GIF, SVG, PNG, TIFF); 

  

  3. video / film (MPEG, AVI, WMV, MP4); 

  

  4. audio recordings (MP3, WAV, AIFF, OGG, etc); 

  

  5. structured data (HTML, JSON, TEX, XML, RDF); 

  

  6. tables (CSV, ODS, TSV, XLS, SAS, Stata, SPSS portable); 

  

  7. source codes (C, CSS, JavaScript, Java, etc); 

  

  8. configuration data (INI, CONF, etc) 

  

  9. database (MS Access, MySql, Oracle, ect) 

  

  

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

**New data set value**

</td>  
<td>

New data set will come from:

  * The Rossini sensing system. 

  

  * The mobile manipulator. 

  

New data sets will be created about the tasks completion to have a
quantitative evaluation of the Rossini Platform .

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

**Audio-visual material**

</td>  
<td>

The duration of the video (if recordered) will be decided in the future.

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

The owner of the device is the partner that provide it (i.e. Datalogic for the
vision system developed from Datalogic), even if the device is used in the IMA
facility.

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

The hardware manufacturers (robot, sensors, …) will each have their standards,
especially with respect to safety, and the relevant ones will be established
during the project.

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

**Methodology for data collection/generation**

</td>  
<td>

The sensor data will be collected by the sensor owners (Pilz, Datalogic, …)
and from IMA that will use the sensor.

The data will be processed from the WP3 and WP4 partners.

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

</td>  
<td>

The data will probably stored on the Pilz Rossini platform.

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

The data will be used to plan and execute a safety work cell for human robot
collaboration in an industrial working environment.

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

**Data ownership**

</td>  
<td>

Data produced are stored and accessible to the whole consortium.

External access can be granted to third parties upon identification.

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

**Suitability for sharing**

</td>  
<td>

Data not marked as confidential, will be public.

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

**Data utility**

</td>  
<td>

The data that are not supposed to be used or visible outside of the system,
will be in a specific format to satisfy efficiency and safety requirements.
Data that are supposed to interact with external systems will be easy to
access and saved in standard formats.

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

**Open research data pilot**

</td>  
<td>

To be defined.

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

IMA IT procedures are based on best practices to guarantee data security and
integrity: Data is stored in enterprise level storage system locked inside
access-restricted data center rooms. Logical data security procedures define
the authorization level needed to access data, i.e. authentication methods and
access profiling based on the role of the technician, and who is accessing the
data, i.e. logging of activities on file systems where data is stored.
Sensitive data is transferred securely between users and systems using
transfer protocols that include encryption technology. Backup systems are
based on the best technologies available on the market and granted and
certified by enterprise class hardware vendors. The data recoverability is
granted by backup systems based on best-of-breed enterprise backup software as
well as enterprise level backed-up data repository (virtual libraries and
hardware repositories with data deduplication technology enabled).

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

**Data Storage**

</td>  
<td>

Backup systems are locked inside access-restricted backup rooms, IMA backup
policies and procedures define backup data retention and frequency, as well as
periodic copies of backed up data in magnetic tapes stored in offsite vaults
for long term retention. The conservation of collected data and how long the
data is maintained is detailed in IMA backup and retention policies and
depends on the type of data collected and the retention is compliant and
respectful of EU data protection regulation.

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

#  11, IMA Machinebouw dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description Type of data: qualitative or quantitative?**

**Order of magnitude**

</td>  
<td>

Data will be generated by installed sensors. Data will be used to define the
severity of the defect and decide future actions. The generated suggestions by
the RSC component can be sent as notifications (SMS or email) to the addressed
operators, to execute the appropriate actions.

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

**Provenance of data: sources**

</td>  
<td>

Possible sources could be: sensors, cameras, lasers, and other measurement
instruments installed at different points of the production line.

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

**Nature and formats of data**

</td>  
<td>

Depending on the implemented type of sensor/camera this could be:

  1. text documents (DOC, ODF, PDF, TXT, etc); 

  

  2. images (JPG, GIF, SVG, PNG, TIFF); 

  

  3. video / film (MPEG, AVI, WMV, MP4); 

  

  4. audio recordings (MP3, WAV, AIFF, OGG, etc); 

  

  5. structured data (HTML, JSON, TEX, XML, RDF); 

  

  6. tables (CSV, ODS, TSV, XLS, SAS, Stata, SPSS portable); 

  

  7. source codes (C, CSS, JavaScript, Java, etc); 

  

  8. configuration data (INI, CONF, etc) 

  

  9. database (MS Access, MySql, Oracle, ect) 

  

  

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

The device will be owned to the industry, where the data collection is going
to be performed.

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

**Partner in charge of the data**

**collection (if different)**

</td>  
<td>

Multiple partners will be in charge (there are various partners related to the
specific incident and/or operation).

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

Multiple partners will be in charge (there are various partners related to the
specific incident and/or operation).

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

**Partner in charge of the data storage**

**(if different)**

</td>  
<td>

Multiple partners will be in charge (there are various partners related to the
specific incident and/or operation).

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

**WPs and tasks**

</td>  
<td>

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

The dataset might be accompanied with a documentation. Possible metadata
include:

• location, date, etc., and production process that led to the defect
generation.

A defect detection event in the production line, the cause, the origin, the
value of the defect, thresholds, the current production stage.

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

**Methodology for data collection/generation**

</td>  
<td>

The methodologies of data collection and production will be defined during the

research process.(To be defined)

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

**Data exploitation & sharing **

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

**Data exploitation (purpose/use of the data analysis)**

</td>  
<td>

The responsible project partner will use the data to decide whether or not a
defective part/product should return to a previous production stage.

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

**Data ownership**

</td>  
<td>

The dataset is confidential and available only to the members of the
consortium.

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

**Suitability for sharing**

</td>  
<td>

Data sharing is capable through web services and the control platform.

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

**Data utility**

</td>  
<td>

Data sharing is capable through web services and the control platform.

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

**Open research data pilot**

</td>  
<td>

The dataset is confidential and available only to the members of the
consortium.

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

**Embargo periods (if any)**

</td>  
<td>

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data & Data Storage **

</td>  
<td>

Data is going to persisted to relational database system. A regular back up
service will run in the background, and aging algorithm will decide which
records are to old and need to be removed.

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

#  12, CORE dataset overview  
  
<table>  
<tr>  
<th>

**Data Identification**

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

**Data set description**

**Type of data: qualitative or quantitative? Order of magnitude**

</td>  
<td>

Dataset will collect general information about partners and project’s
activities, as well as information about news, events, publications relevant
for the project.

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

**Provenance of data: sources**

</td>  
<td>

The dataset originates from the project’s social media accounts (Twitter &
LinkedIn)

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

**Nature and formats of data**

</td>  
<td>

Data collected should be elaborated by using the formulas in CVC and XLX
format:

Twitter data includes: Name, Location,

Created Date, Number of Favorites, URL,

Profile Image URL, Language, Protected,

Description, Verified, Tweet Count, Time

Zone

Twitter also gives direct access to individual Tweets: Text, URL, Retweet
Count, Date, Source, Favorite Count, Hash

Tags, Mentioned Users, In Reply to Screen

Name, Geo Data

LinkedIn data includes (depending on the profile privacy preferences of the
user): Direct link to LinkedIn profile, Email address, Phone number, Website,
Instant messenger accounts, Birthday, 1st-degree connections

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

**New data set value**

</td>  
<td>

n/a

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

**Audio-visual material**

</td>  
<td>

n/a

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

**Partners Activities & Responsibilities **

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

**Partner owner of the device producing the data**

</td>  
<td>

CORE

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

**Partner in charge of the data collection (if different)**

</td>  
<td>

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

**Partner in charge of the data analysis (if different)**

</td>  
<td>

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

**Partner in charge of the data storage (if different)**

</td>  
<td>

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

**WPs and tasks**

</td>  
<td>

WP9, T9.1

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

**Standards and Metadata**

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

**Metadata standards and data documentation**

</td>  
<td>

n/a

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

**Methodology for data collection/generation**

</td>  
<td>

n/a

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

**Data exploitation & sharing **

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

**Data exploitation**

**(purpose/use of the data analysis)**

</td>  
<td>

Data will be used for the communication and dissemination of the project
activities Moreover, CORE will monitor users’ access to the website and social
network pages to evaluate stakeholders’ interest in the project activities and
KPI definition

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

**Data ownership**

</td>  
<td>

CORE

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

**Suitability for sharing**

</td>  
<td>

Public/limited access

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

**Data utility**

</td>  
<td>

Core Innovation collects this data as a KPI of the Communication Supports and

Channels

The data collected from the project’s social media accounts will only
circulate within the consortium and the Commission Services.

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

**Open research data pilot**

</td>  
<td>

n/a

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

**Embargo periods (if any)**

</td>  
<td>

Yes, for the scientific papers.

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

**Archiving & preservation (including storage and backup) **

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

**Managing, storing and curating data**

</td>  
<td>

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

**Data Storage**

</td>  
<td>

Data is stored on the specific cloud for all time of the project

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

**3**

</td>  
<td>

**Data Summary**

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

It has been already mentioned that the DMP released at M06 of ROSSINI project
will only be a preliminary version of the document, that will be updated and
augmented with new datasets and results during the lifespan of ROSSINI
project. For completing the DMP deliverable, all ROSSINI partners have
provided input following the template Horizon 2020  6  as well as the Data Set
Template. At the proposal phase of the project, an initial DMP plan has been
outlined and its results are summarised and presented in the following Table
13\.

#  Table 13, ROSSINI Expected research data  
  
<table>  
<tr>  
<th>

**Research Data**

</th>  
<th>

**Related Partners**

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

RS4 system specification and performance indicators

</td>  
<td>

DATALOGIC, PILZ

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

Preliminary assessment data for external certification of RS4

</td>  
<td>

DATALOGIC, PILZ

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

Safety Aware Control Architecture algorithms experimentation results

</td>  
<td>

UNIMORE, IRIS

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

Collaborative Robotic Arm simulation and validation outcomes

</td>  
<td>

SUPSI, PLIZ

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

OECD metrics and datasets

</td>  
<td>

TNO

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

Actual collision values algorithms and model

</td>  
<td>

FRAUNHOFER

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

KPIs from use cases

</td>  
<td>

IMA, WHIRPOOL, IMA Machinebouw, SCHINDLER

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

In the next months of the project the following table will be further
implemented as consortium partners will be requested to investigate and
provide more detailed information on their produced data and whether these are
discoverable, accessible, assessable and intelligible, useable (beyond the
original purpose) and interoperable.

##  3.1 The purpose of the data collection/generation and its relation to the
objectives of the project

There are several purposes for data collection within ROSSINI project. In
principle, data will be generated/gathered for:

  * Testing and research purposes: the data collected will help in characterizing form a qualitative and quantitative point of view the results of the experiments carried out within the project, giving the technology providers of ROSSINI project a view on the progress of their research and the needed information to set new tests and build the architecture for ROSSINI collaborative platform. 

  

  * Scientific data analysis collection to define the metrics that will be used to evaluate the job quality in the use cases, before and after the implementation of the Rossini framework. 

  

  * Communication, Dissemination and Exploitation puroposes: to determine the degree to which the dissemination objectives have been reached, and the relationship between the outcomes and the efforts made to reach the goals. The data collected will be also used to support the exploitation activities to maximize the impact of the project. 

  

Each partner has listed his own purpose and they strongly depend on the role
of partner within the project and the workpackage they are involved in:

  * Fraunhofer IFF is responsible for the development of a method that allows for transforming results from collision test with a fixed measurement device into such for a transient contact. For the evaluation of the method, Fraunhofer IFF requires data from collision test with an appropriate measurement device and a collaborative robot. Those data are the only data which Fraunhofer IFF will create during the project. 

  

  * Datalogic, besides the project documentation mainly made of SW source codes, schematics, drawings and MS Office documents, will collect temporary datasets of images and of laser and radar scanner measurements. The datasets will be used exclusively for the development of Datalogic data processing algorithms. 

  

  * IMA Machinebouw, will collect case identifying information, respondent information, technical information, description of actual work situation, information concerning future work information. The data will give insight on the actual work situation and how this will evolve in the future. Both qualitative and quantitative data types will be used. 

  

  * IRIS will merge the data collected by sensors in order to build the semantic scene map, in case of Task 4.1. The main purpose of the semantic scene map is to produce a map of the working environment including the safety areas available from the environment representation. Synthetic data can be generated through simulation software to compensate for the possible lack of real data. In the case of Task 7.2 the scope is to develop a desktop-based design tool starting from an existing one, integrating libraries, tools, algorithms and model specific for the ROSSINI project. The data used for this task will be mainly generated by the software itself and will be used for testing purpose. 

  

  * SUPSI: Purpose of data collection is to share data with project partners data with scientific community and dissemination of project’s results. 

  

  * IMA/WHR/SCHINDLER will collect data to give input for requirements and validation strategy necessary to the Rossini platform development. The data generation is related to demonstration activities and to the verification of the robotic cell. 

  

**3.2 Types and formats, origin and size of data the project will
generate/collect** The project will generate the following types and formats
of data:  
  
<table>  
<tr>  
<th>

−

</th>  
<th>

text documents (DOC, ODF, PDF, TXT, etc);

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

−

</td>  
<td>

images (JPG, GIF, SVG, PNG, TIFF);

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

−

</td>  
<td>

video / film (MPEG, AVI, WMV, MP4);

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

−

</td>  
<td>

audio recordings (MP3, WAV, AIFF, OGG, etc);

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

−

</td>  
<td>

structured data (HTML, JSON, TEX, XML, RDF);

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

−

</td>  
<td>

tables (CSV, ODS, TSV, XLS, SAS, Stata, SPSS portable);

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

−

</td>  
<td>

source codes (C, CSS, JavaScript, Java, etc);

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

−

</td>  
<td>

configuration data (INI, CONF, etc);

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

−

</td>  
<td>

database (MS Access, MySql, Oracle, ect);

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

−

</td>  
<td>

DWG;

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

−

</td>  
<td>

Visio

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

Moreover, SUPSI would generate also CAD files, Data-sheets, Bill Of Materials,
Gantt diagrams, Operating manuals, Software Packages, Source code, Electrical
diagrams, Data logs.

The previous listed formats of data are justified by their origin, some
partners of ROSSINI project have already estimated the origin of the
generated/collected data. Table 14, Origin of the data illustrates the origin
of the data:

#  Table 14, Origin of the data  
  
<table>  
<tr>  
<th>

PARTNER

</th>  
<th>

</th>  
<th>

ORIGIN OF DATA

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

**FFI**

</td>  
<td>

</td>  
<td>

Experimental collision tests

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

**WHR**

</td>  
<td>

</td>  
<td>

from questionnaires and interviews to experts

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

**DATALOGIC**

</td>  
<td>

</td>  
<td>

3D cameras of different types including the Datalogic 3D safety camera,
Datalogic safety Laser Scanners and Pilz radar sensor prototypes

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

**IMA Machinebouw**

</td>  
<td>

</td>  
<td>

interviews, project meetings, field visits, conference calls, net meetings,
emails, shared data platforms (cloud), projects, existing machines

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

**IMA**

</td>  
<td>

</td>  
<td>

tea bags packaging machines, IMA robotics projects, Mobile platform, Rossini
Sensing System

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

**IRIS**

</td>  
<td>

</td>  
<td>

safety and non-safety sensors; software design tool

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

**SUPSI**

</td>  
<td>

</td>  
<td>

Project financial and administration data sources: EU portal, employees
reporting.

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

PARTNER

</td>  
<td>

ORIGIN OF DATA

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

</td>  
<td>

Project technical documents sources: engineer’s workstations, machines control
systems, Internet. Other documents sources: internal realization for
documentation or promotional purposes

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

**CORE**

</td>  
<td>

The dataset originates from the project’s social media accounts (Twitter &
LinkedIn)

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

Some partners have also provided an estimation of the expected size of the
data, this information is outlined in the Table 15 below:

#  Table 15, Size of the data  
  
<table>  
<tr>  
<th>

**PARTNER**

</th>  
<th>

**SIZE OF DATA**

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

**FFI**

</td>  
<td>

From 10 to 20 GB

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

**WHR**

</td>  
<td>

Less than 10GB

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

**DATALOGIC**

</td>  
<td>

Each image will be 1-3 MB; final size of the datasets will probably exceed 1
TB

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

**IMA Machinebouw**

</td>  
<td>

around 5Gbyte

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

**IMA**

</td>  
<td>

Depends on the source

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

**IRIS**

</td>  
<td>

Depends on the source

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

**PILZ**

</td>  
<td>

Not available yet

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

**SCHINDLER**

</td>  
<td>

Not available yet

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

**SUPSI**

</td>  
<td>

≥40GB

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

**3.3 Existing data, re-use and how?**

Some partner will re-use existing data, such as FFI (from a study with
volunteers), IMA (IMA robotics applications already on stage and data from the
IMA tea bags packaging machines), SUPSI (data coming from other projects);
other partners as DATALOGIC, IRIS and PILZ will not re-use existing data.

##  3.4 Data utility

Data from the project will be mostly useful to project partners, for design,
implementation, simulation, and testing purposes within the project. The main
addressees will be requirements engineers, design engineers and system
integrators. In particular, data will be useful for the project consortium for
the design of the use cases, which is performed by IMA Machinebouw (WP2);
Rossini Safe sensing System, which is performed by DATALOGIC (WP3); for the
definition, implementation, simulation, and testing of the semantic scene map,
which is performed by IRIS (WP4), collaborative by Birth Robot Arm, which is
performed by SUPSI (WP5); a system that implements Human Robot mutual
understanding, which is performed by TNO (WP6) and the integration layer,
which is performed by PILZ (WP7). Outside of the project consortium the data
from scientific publications could be useful for academic researchers and the
scientific community to carry out further research.  
  
<table>  
<tr>  
<th>

**4**

</th>  
<th>

**FAIR data**

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

The principles of FAIR data have been established by a set of different
stakeholders like academia, industry, funding agencies, and scholarly
publishers. According to Wilkinson et al1, the FAIR Data Principles are a set
of guiding principles in order to make data findable, accessible,
interoperable and reusable.

7

The FAIR Data Principles clearly provide a concise and measurable set of
parameters that should be respected to ensure the availability and reusability
of the data for further research purposes by third parties that were not part
of the project. Distinct from peer initiatives that focus on the human
scholar, the FAIR Principles put specific emphasis on enhancing the ability of
machines to automatically find and use the data, in addition to supporting its
reuse by individuals. The mentioned principles do not necessarily propose an
explicit technology, standard or implementation solution, forego
implementation choices and promote the maximum usage of data.

7  Association of European Research Libraries, “Implementing FAIR Data
Principles”, Ligue des Bibliothèques Européennes de

Recherche

###  4.1 Making data findable, including provisions for metadata

Data will be made **findable** by means of appropriate metadata and taking
into account internal project conventions.

Given that, they will be made available mainly to project partners for their
use and re-use. The conventions that will be followed will be further
discussed in the upcoming months: some partners already rely on their internal
company system for data identification and their model could be adopted by the
whole consortium as the common project methodology.

For example, SUPSI stores its data (including data deriving from the project)
in SUPSI Instory (SUPSI INSTitutional repositORY), the online institutional
archive of publications related to the research and didactic work conducted by
the University of Applied Sciences and Arts of Southern Switzerland. All data
in Instory are provided with metadata. Instory automatically assigns a DOI
(Digital Object Identifier) to every submitted record and each of its
versions, for research data as well as for publications. Research data may be
linked to the corresponding publications and vice versa via their DOIs.

The data naming convention must be further discussed as well, however the
solution currently proposed by SUPSI and likely to be adopted is the
following:

###  yyyymmdd_ROS_WPx.t_Tyy_Description_Rzz.eee

Where: **yyyy** = year, **mm** = month, **dd** = day **x** = WP number **t** =
task number **zz** = version number **eee** = file extension

Example: 20190228_ROS_WP5.2_RobotJoint_R01.stp

Such solution represents a good option as it provides the user with the main
important information on the data, using the date of creation, the keyword
associated to the ROSSINI project name, the number of the WP and Task that
originated the data, a versioning number and the file extension. If some new
keywords, other than the name of the project, the number of the WP and the
Task will be set the DMP will be updated accordingly.

As previously mentioned, the consortium will make use of metadata to describe
the data collection and to facilitate the finding and re-use of data.
Generally speaking, metadata will have a twofold nature: descriptive,
therefore giving information on the data discovery and identification (titles,
author, keywords) and administrative outlining when and how data was created,
file type and other technical information, and who can access it. Some
standard metadata schema will also be used. The Qualified Dublin Core standard
will be used by SUPSI and may apply to the rest of the consortium. However,
this will be assessed in the next months and the DMP will be updated
accordingly.

####  4.2 Making data openly accessible

Most of data collected during the project are for confidential use and
accessible to project partners only. However, some data will be open and
available for the public, especially those included in scientific papers and
public deliverables of the ROSSINI project..

Most of the non-confidential data will be uploaded on online repositories like
Zenodo or SUPSI Instory (SUPSI INSTitutional repositORY), the online
institutional archive of publications related to the research and didactic
work conducted by the University of Applied Sciences and Arts of Southern
Switzerland. All metadata in Instory are made publicly available in the sense
of Open Access.

The data generated within the project should be easily accessible without the
use of any sophisticated software. Indeed, the data that will made open only
to the partners of the ROSSINI project will be accessible via the ROSSINI
design tool or via standard software. The data valuable for the stakeholders
and the public outside of the project will be made accessible using standard
software and methods. Typical formats may be .csv so Excel would be a typical
tool to read the data, or via a MySQL database interface if the data will be
loaded into a common repository, rather than many

“flat” files. In case it will be needed, clear documentation will be produced,
especially for the ROSSINI design tool. Well known data access tools such as
Excel and MySQL are already well documented however, future provisions could
be undertaken.

At the current stage of the project the data and associated metadata,
documentation and code will be deposited in the servers of each partner’s
organisations, while some data that will be valuable for the whole consortium
will be stored in the Rossini collaborative platform provided by PILZ.

Generally, access to the servers of the organization by which each partner
belongs to, if provided, it will be given only to people directly involved in
the project through an identification process (i.e. username and password).

In the specific case of SUPSI, anyone may access the metadata describing items
in the SUPSI Instory repository free of charge. The metadata may be re-used in
any medium without prior permission for not-for-profit purposes.

####  4.3 Making data interoperable

The data that are not supposed to be used or visible outside of the system,
will be in a specific format to satisfy efficiency and safety requirements.
However, in case of non-common ontologies, they will be explained and mapped.
Generally, data will use a formal, standard, accessible, shared, and broadly
applicable language for knowledge representation, vocabularies that follow
FAIR principles and include qualified references to other data.

Data and metadata vocabularies, standards or methodologies used to make data
interoperable are standard vocabularies or OAI-PMH and SWORD (Simple Web-
service Offering Repository Deposit).

####  4.4 Increase data re-use (through clarifying licences)

In the event that some project data will be licensed to permit their re-use by
the external stakeholders, Creative Commons or GNU licenses will be used. As
previousely mentioned, the data that will be made available for individuals
that are external to the project will be included in the project deliverables
marked as public. Such data will be made public as soon as the project officer
will approve the deliverables in the Funding and Tenders Platform of the EC.

With regards to the access rights to third parties, the consortium will follow
the rules established in the Rossini Consortium Agreement (Chapter 9, par.
9.8)  
  
<table>  
<tr>  
<th>

**5**

</th>  
<th>

**Allocation of resources**

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

The estimation of the costs to be incurred when making the data FAIR according
to the principles of the EC and the proper allocation of the resources to do
that are two topics addressed by the DMP. Moreover, the plan identifies the
responsibilities for data management in project describing the costs and
potential value of long-term preservation. Even if this is an early stage of
the project an not all the points could find an exhaustive description, this
chapter of the DMP will address the costs for making data FAIR in ROSSINI
project, how these costs will be covered, who will be the responsible for the
data management and who will decide and how what data will be kept and for how
long.

####  5.1 Estimation of cost

The costs related to open access to research data are eligible as part of the
Horizon 2020 grant (if compliant with the Grant Agreement conditions). Costs
are eligible for reimbursement during the duration of the project under the
conditions defined in the H2020 Grant Agreement.

####  5.2 Responsibilities for data management

The partner who will be responsible for data management within the ROSSINI
project is CRIT. CRIT will be in charge to periodically update the DMP with
further details and information provided by all project partners that should
provide their contributions.  
  
<table>  
<tr>  
<th>

**6**

</th>  
<th>

**Data security**

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

The ethics deliverables of ROSSINI project released so far outline with high
level of detail the procedures and strategies to ensure the secure storage and
preservation of the data. The project partners will respect the procedures
implemented for data collection, storage, access, sharing policies,
protection, retention and destruction according to the requirements of the
national legislation and EU standards  7  . The ROSSINI consortium will also
be compliant with the European Union (EU) 2016/679 General Data Protection
Regulation (GDPR)  8  on the protection of natural persons with regard to the
processing of personal data and on the free movement of such data.

####  6.1 Data confidentiality and integrity

Generally, provisions for data security include best practices to guarantee
data security, both physical data security (i.e. availability of locked data
rooms accessed only by authorized personnel) and logical data security
(i.e.using firewalls, intrusion detection system, authentication methods and
access profiling based on the role of the technician, logging of activities on
file systems where data is stored). Sensitive data is transferred securely
between users and systems using transfer protocols that include encryption
technology. The data recoverability is granted by backup systems based on
best-of-breed enterprise backup software as well as enterprise level backed-up
data repository (virtual libraries and hardware repositories with data
deduplication technology enabled) which can be accessed only by authorised
personnel to project beneficiaries needing access rights.

####  6.2 Data availability

Usually, data are protected and stored according to the directive for
safeguarding good scientific practice of the organisation.  
  
<table>  
<tr>  
<th>

**7**

</th>  
<th>

**Conclusion and next steps**

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

The initial ROSSINI DMP is presented in this document due M06 describing how
acquired data and knowledge will be shared and/or made open as well as how
data will be maintained and preserved during and after the project lifetime.
Indeed, it describes the updated procedures and the infrastructure implemented
by the project to efficiently manage the produced data. The DMP is identified
as starting point for the discussion with the community about the ROSSINI data
management strategy and reflects the procedures planned by the work plan at
the beginning of the project. Present information has been collected by the
answers provided by the ROSSINI project partners to the H2020 survey template
by the EC. This is only a preliminary version of the plan that will be however
updated regularly by CRIT thanks to the contribution of all partners to ensure
the proper management of the data.