#  2 Introduction

The amount of data generated is continuously increasing while use and re-use
of data to derive new scientific findings is relatively stable. This
information would be useful in the future if the data is well documented
according to accepted and trusted standards which enable the recognition of
suitable data by negotiated agreements on standards, quality level and sharing
practices. For this purpose, DMP defines strategies to preserve and store data
over the defined period of time in order to ensure their availability and re-
usability after the end of Z-Fact0r project.

According to the Guidelines of ORD Pilot in H2020, research data refers to
information, in particular facts or numbers, collected to be examined and
considered and as well as basis for reasoning, discussion, or calculation. The
overall objective of Z-Fact0r project is to develop zerodefect manufacturing
strategies for on-line production. Z-Fact0r aims to contribute to the
eradication of defects in manufacturing, providing better quality of products,
increasing flexibility, and reducing production costs. Thus, research
activities are more focused on the production process and tools than on
production of research or observation of data, so the amount of research data
which will be produced within the project is limited, at least at this stage
of the project.

##  2.1.1 Participation in the pilot on open research data

The EC is running a flexible pilot under H2020 called the ORD pilot. The ORD
pilot aims to improve and maximize access and re-use of research data
generated by H2020 projects and takes into account the need to balance
openness and protection of scientific information, commercialization and IPR,
privacy concerns, security as well as data management and preservation issues.
The 2017 work programme of ORD pilot has been extended to cover all the
thematic areas of Horizon 2020.

Following the recommendation of the EC, Z-Fact0r project is participating in
the ORD Pilot and DMP is D9.4 deliverable (D.9.4) due M6 of the project. The
DMP of Z-Fact0r project has been prepared by taking into account the document
template of the “Guidelines on DMP in H2020”.

This document will be updated and augmented with new datasets and results,
according to the progress of the activities of the Z-Fact0r project. Also, the
DMP will be updated to include possible changes in the consortium composition
and policies over the course of the project.

The procedures that will be implemented for data collection, storage, 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.

##  2.1.2 Building a DMP in the context of H2020

The EC provided a document with guidelines for project participating in the
pilot. The guidelines address aspects like research data quality, sharing and
security. Following these guidelines, DMP will be developed with aim to
provide a consolidated plan for Z-Fact0r partners in the data management plan
policy that the project will follow.

The consortium will comply with the requirements of Directive 95/46/EC of the
European Parliament and of the Council of 24 October 1995 on the protection of
individuals with regard to the processing of personal data and on the free
movement of such data. The consortium will preserve the right to privacy and
confidentiality of data of the survey participants, by providing them two
documents: The Participant Information Sheet and the Consent Form. These
documents will be sent electronically and will provide information about how
the answers will be used and what the purpose of the survey is.

The participants will be assured that their answers will be used only for the
purposes of the specific survey. The voluntary character of participation will
be stated explicitly in the Consent Form. Before conducting the survey, the
consortium will examine and follow the requirements of the national
legislation in line with the EU standards, whether the proposed data
collection requires special local/national ethical/legal permission.

An ethical approach will be adopted and maintained throughout the fieldwork
process. The responsible partners will assure that the EU standards regarding
ethics and Data Management are fulfilled. Each partner will proceed with the
survey according to the provisions of the national legislation that are
adjusted in line with the respective EU Directives for Data Management and
ethics.

The consortium will follow a transparent recruitment process for the
engagement of stakeholders and inclusion/exclusion criteria for all the
surveys will be explained in the Participant Information Sheet.

Each partner will send an invitation (by mail) to participants/third parties
that have neither the role in Z-Fact0r project nor professional relationship
with the consortium to participate in the survey. The consortium will also
examine whether personal data will be collected and how to secure the
confidentiality in such a case.

The Steering Committee of the project will also ensure that EU standards are
followed. The issue of informed consent for all survey procedures, all
participants will be provided with a Participant Information Sheet and Consent
Form to provide informed consent. The default position for all data relating
to residents and staff will be anonymous.

##  2.2 Z-Fact0r Data Management Plan (DMP)

###  2.2.1 General description

This document outlines the first version of the project’s DMP. The DMP is
presented as D9.4 public deliverable (Month 6) of WP9, DCE.

The main purpose of DMP is to provide an analysis of the main elements of data
management policy that will be used by the consortium with regard to all the
datasets that will be generated by the project (e.g. numerical, images, etc.).

This document describes the Research Data with the metadata attached, and
presents an overview of datasets to be produced by the project, their
characteristics and the management processes to make them discoverable,
accessible, assessable, usable beyond the original purpose, and disseminated
between researchers. It also introduces the specifications of the dedicated
Data Management Portal developed by the project in the context of the ORD
Pilot, allowing the efficient management of the project’s datasets and
providing proper OA on them for further analysis and reuse. In addition, the
DMP of Z-Fact0r project reflects the current status of discussion within the
consortium about the data that will be produced.

###  2.2.2 Activities of Data Management Plan

The DMP is a dynamic document, updated throughout the whole project lifecycle.
The final version of this report will be delivered by the end of the project,
reflecting on lessons learnt and describing the plans implemented for
sustainable storage and accessibility of the data, even beyond the project’s
lifetime.

A Knowledge Management system will be developed, which incorporates in a
structured way, the technical and business knowledge created during the
project. The activities of the Z-Fact0r concerning the data management are
planned as follows:

  * Knowledge management – to be led by the DEM, in which the DMP will be delivered. 

  

  * A knowledge management document will be created, based on DMP, describing how the acquired data and knowledge will be shared and/or made open, and how it will be maintained and preserved. The identifiable project data will be provided in a manner to define the relevant knowledge, increase partners’ awareness, validate the result, and timeframe of actions. 

  

  * Technology watch - All partners will be responsible for periodically updating the knowledge management system with outcomes of research work conducted by other groups and any new patents/patent applications, i.e. to ensure that ongoing relevant technological developments and innovations are identified, analysed, and hopefully built upon during the course of the project. 

  

###  2.2.3 Register on numerical datasets generated or collected in Z-Fact0r

The goal of the DMP is to describe numerical model or observation datasets
collected or created by Z-Fact0r during the runtime of the project. The
register on numerical datasets has to be understood as a living document,
which will be updated regularly during the project´s lifetime.

The operational phase of the project started in October 2016, so there is no
dataset generated or collected until delivery date of this DMP (M6). However,
this is not a fixed document so it will be updated and augmented with new
datasets and results during the duration of Z-Fact0r project.

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 the
information detailed in _Annex 1 of the GA document_ :

  * Dataset reference and name: identifier for the dataset to be produced. 

  

  * Dataset description: descriptions of the data that will be generated or collected, its origin or source (in case it is collected), nature and scale and 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 sharing: 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 CCS) or public. In case a dataset cannot be shared, the reasons for this should be mentioned (e.g. ethics, rules of personal data, intellectual property, commercial, privacy-related, 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. 

  

###  2.2.4 Metadata for Data Management

An initial plan of research data has been explored in _Annex 1 of the_ GA. The
dataset list is provided in the table below, while the nature and details of
each dataset are presented in the next section.

_Table 1. Research data that will be collected and generated during Z-Fact0r._  
  
<table>  
<tr>  
<th>

**Research Data**

</th>  
<th>

**Partners**

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

Data structures with production machine signatures (healthy and deteriorated
conditions)

</td>  
<td>

ATLANTIS

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

Machine Deterioration thresholds for predicting production of defected
products

</td>  
<td>

ATLANTIS

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

RCA data structures for identifying the root cause of a defect in upstream
stages

</td>  
<td>

CERTH/ITI

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

Data from the comparative assessment (i.e. with and without Z-Fact0r) in the 3
use cases: difference in production cost/waste/scrap, in detection efficiency,
in singlestage production defect rate, in average multistage production defect
rate, in production output quality (qualified output / total output produced),
in defect propagation to downstream stages

</td>  
<td>

MICROSEMI,

INTERSEALS,

DURIT

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

Defect detection efficiency data: false alarm rate, precision, recall,
F-Measure

</td>  
<td>

ALL PARTNERS

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

Defect prediction efficiency data: positive prediction rate

</td>  
<td>

ALL PARTNERS

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

Discrete Event Modelling – cost function generation to optimize production
with green scheduling

</td>  
<td>

BRUNEL

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

Validation and verification of KPIs to assess the direct impact of system
level to the final cost

</td>  
<td>

BRUNEL, EPFL

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

Context aware models and associated algorithms

</td>  
<td>

EPFL

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

Additive manufacturing methodologies for rework and repair

</td>  
<td>

CETRI

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

Improved functionalities of i-LiKe knowledge management and DSS suite

</td>  
<td>

HOLONIX

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

Partners will characterize their research data and associated software and/or
used in the project whether these are discoverable, accessible, assessable and
intelligible, useable beyond the project’s life and interoperable. In
specific, research data can be discovered by means of an identification
mechanism such as Digital Object Identifier and accessible by defining
modalities, the scope of the action, establish the licenses and define the
IPR.

Otherwise research data will be assessable and intelligible allowing third
parties to make assessments. Also, the dataset will be useable beyond the
original purpose for which it was collected or usable to third parties after
the collection of the data for long periods (repositories, preservation and
curation). Finally, research data will offer interoperability to specific
quality standards and allow data exchange between researchers, institutions,
organizations, countries, re-combinations with different datasets, data
exchange, compliant with available software applications.

###  2.2.5 Data description

In order to collect the information about the research data that will be
generated in different activities of the Z- Fact0r project, we have elaborated
a template to be completed by the consortium partners.

This template includes the following information items:

  * Dataset reference and name: name, homepage, publisher, maintainer 

  

  * Dataset description: description, provenance, usefulness, similar data, re-use and integration 

  

  * Standards and metadata: metadata description, vocabularies and ontologies 

  

  * Data sharing: license, URL dataset description, openness, software necessary, repository 

  

  * Archiving and preservation: preservation, growth, archive, size 

  

_2.2.5.1 Dataset per partner_

All partners have identified the data that will be produced in the different
project activities;  
  
<table>  
<tr>  
<th>

**DS.CETRI.Z-Repair_AM_processing**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Formulation of the inks or paste for additive manufacturing repairing
processes & printing/deposition protocols.

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

Source

</td>  
<td>

Various characterization techniques, e.g. microscopy, viscometer, printing
station.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

CETRI

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

Partner in charge of data collection

</td>  
<td>

CETRI

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

Partner in charge of

data analysis

</td>  
<td>

CETRI

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

Partner in charge of data storage

</td>  
<td>

CETRI

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

WPs and tasks

</td>  
<td>

T2.4 in WP2

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

The metadata include:

  1. The characteristics of the materials to be deposited. 

  

  2. The user requirements as obtained by the end users. 

  

  

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

Standards, Format, Estimated volume of data.

</td>  
<td>

No standards apply. The format will be in the form of spreadsheets and images
(TIFF of JPG). Estimated volume is < 10 MB.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The results of the study have the potential to be exploited by CETRI along
with the Z-Fact0r end users MICROSEMI, DURIT and INTERSEALS, as well as by
SIR, towards the implementation of integrating new processes in their
production lines.

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

Data access policy /

Dissemination level

</td>  
<td>

In general, the data will be confidential with the exception of possible
future publications in the case the consortium permits such activities.

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

Data sharing, re-use and distribution

</td>  
<td>

CETRI will generate 3 sets of data for the 3 Z-Fact0r end-users (MICROSEMI,
DURIT, INTERSEALS). Each set will be shared with the individual partners in
the form of raw data and complete reports in order to receive feedback during
the project implementation.

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

Embargo periods

</td>  
<td>

No

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored into a computer and an external hard disc and will be send
frequently to the individual end-users. The data will be stored permanently in
a computer in CETRI facilities.

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

**DS.CETRI.Z-Repair_laser_processing**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Measurements of the laser source couples to measurements of the processed
surface.

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

Source

</td>  
<td>

Laser source. Laser Power Meter Microscopy.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

CETRI

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

Partner in charge of data collection

</td>  
<td>

CETRI

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

Partner in charge of

data analysis

</td>  
<td>

CETRI

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

Partner in charge of data storage

</td>  
<td>

CETRI

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

WPs and tasks

</td>  
<td>

T2.4 in WP2

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

**Standards**

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

Info about metadata

(Production and

</td>  
<td>

The metadata include:

  1. The type/origin of the processed material. 

  

  2. The conditions of the experiments. 

  

  

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

storage dates, places, and documentation)

</td>  
<td>

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

Standards, Format, Estimated volume of data.

</td>  
<td>

No standards apply. The format will be in the form of spreadsheets and images
(TIFF of JPG). Estimated volume is < 10 MB.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The results of the study have the potential to be exploited by

CETRI along with the Z-Fact0r end users MICROSEMI, DURIT and INTERSEALS, as
well as by SIR, towards the implementation of integrating new processes in
their production lines.

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

Data access policy /

Dissemination level

</td>  
<td>

In general, the data will be confidential with the exception of possible
future publications in the case the consortium permits such activities.

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

Data sharing, re-use and distribution

</td>  
<td>

CETRI will generate 3 sets of data for the 3 Z-Fact0r end-users (MICROSEMI,
DURIT and INTERSEALS). Each set will be shared with the individual partners in
the form of raw data and complete reports in order to receive feedback during
the project implementation.

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

Embargo periods

</td>  
<td>

No

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored into a computer and an external hard disc and will be send
frequently to the individual end-users.

The data will be stored permanently in a computer in CETRI facilities.

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

**DS.DURIT. Production line. Demo 3.**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Data collected:

  * Dimensions/shapes/surface and 3D details 

  

  * Superficial defects like cracks 

  

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

Source

</th>  
<th>

The data will be collected by different sensors and imaging devices such as
cameras. Installed in the production line after green machining and after
finishing operations. Ideally installed in machine for real time inspection
although very difficult to implement at the current time.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DURIT

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

Partner in charge of data collection

</td>  
<td>

DURIT

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

Partner in charge of

data analysis

</td>  
<td>

DURIT

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

Partner in charge of data storage

</td>  
<td>

DURIT

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

WPs and tasks

</td>  
<td>

The data are going to be collected in WP5 and WP6.

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

The dataset will be accompanied by information regarding:

  * Drawings and sequence of operations. 

  

  * Batch of material used. 

  

  * Operators involved. 

  

  * Date, time. 

  

  * Temperature and relative humidity in the metallurgy section. 

  

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Our tests will be in a specific type of pieces. The volume of data depends of
the quantity of order.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Production process recognition and help during the different production
phases, avoiding mistakes. Support of quality checks and production batches
recalls

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

Data access policy /

Dissemination level

</td>  
<td>

The full dataset will be confidential and only the members of the consortium
will have access on it. Furthermore, if the dataset or specific portions of it
(e.g. metadata, statistics, etc.) are to become of widely OA, a data
management portal will be created that should provide a description of the
dataset and link to a download section. Of course, these data will be

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

</td>  
<td>

anonymized, so as not to have any potential ethical issues with their
publication and dissemination.

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

Data sharing, re-use and distribution

</td>  
<td>

Data sharing is dependent of DURIT, DURIT´s customers and partner
requirements.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

All information belongs to the industrial partner that owns the shop floor.
All data will respect the partner policies. All data has to be stored till the
end of life/warranty of the produced component. Probably also stored at DURIT
servers at the cloud.

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

**DS.EPFL.01_KMDSS**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Z-Fact0r Knowledge Management and Decision Support System Dataset.

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

Source

</td>  
<td>

Device Manager, Event Manager, Semantic Context Manager, ZFact0r Repository.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

The device will be owned by Z-Fact0r End-users (MICROSEMI, INTERSEALS, DURIT),
where the data collection will be performed.

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

Partner in charge of data collection

</td>  
<td>

Various partners related to the specific event and/or operation.

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

Partner in charge of

data analysis

</td>  
<td>

Various partners related to the specific event and/or operation.

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

Partner in charge of data storage

</td>  
<td>

EPFL will store data related to KMDSS (various partners can handle the rest of
the data).

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

WPs and tasks

</td>  
<td>

The data will be collected within the activities of WP2, WP3 and WP4.

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Indicative metadata include: Input from the Sensor Network (through the Device
Manager), the overall model of Production activities (through Z-Fact0r
Repository), shop-floor events data from the Event Manager, and context –
aware knowledge stemming from the Semantic Context Manager (Ontology).

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Data can be available in XML or JSON format. Estimation of the volume of data
cannot be predicted in advance of a real use of the technology at the shop
floor level.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The collected data will be used for better understanding of the processes and
activities evolving in the shop-floor which will provide actionable knowledge
in the form of a set of recommendations to (i) supervise and provide feedback
for all the processes executed in the production line, (ii) evaluate
performance parameters and responding to defects, keeping historical data,
(iii) send efficiently alarms to initiate actions, filter out false alarms,
increase confidence levels (through previously acquired knowledge) of early
defect detection and prediction, etc.

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

Data access policy /

Dissemination level

</td>  
<td>

Accessible to Z-Fact0r consortium members including the commission services as
defined in the Z-Fact0r GA.

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

Data sharing, re-use and distribution

</td>  
<td>

The sharing of this data is yet to be decided together with the industrial
partners.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in a dedicated repository.

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

**DS.EPFL.02.SemanticContextManager**

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

**Data Identification**

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

Dataset description

</th>  
<th>

Context-aware shop-floor analysis and semantic model for the annotation and
description of the knowledge to represent manufacturing system performance.

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

Source

</td>  
<td>

Z-Fact0r repository.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

Z-Fact0r End-users (MICROSEMI, INTERSEALS, DURIT)

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

Partner in charge of data collection

</td>  
<td>

EPFL

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

Partner in charge of

data analysis

</td>  
<td>

EPFL

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

Partner in charge of data storage

</td>  
<td>

EPFL

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

WPs and tasks

</td>  
<td>

The data will be collected within the activities of WP3 and in particular
T3.5.

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Data from Z-Fact0r repository (data concerning machines, workers, actors,
activities and processes, production data logs, etc.).

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Generated output will be the semantic enrichment of shop-floor data for
representation of processes, actors, alarms, actions, work-pieces/products,
etc., e.g. as RDF Triplets. Standards:

W3C-OWL, RDF. Less than 2GB.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Data is required for the Z-Fact0r ontology development. Ontology describes
semantic models. The ontology will be used in order to drive the semantic
framework. Furthermore, it will be used for data integration, visualization,
inferencing /reasoning. The ontology will describe the basic entities of the
project and model relevant structures of multi-stage manufacturing processes.

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

Data access policy /

Dissemination level

</td>  
<td>

Accessible to Z-Fact0r consortium members including the commission services as
defined in the Z-Fact0r GA.

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

Data sharing, re-use and distribution

</td>  
<td>

The Ontology will be uploaded in a server where it will be accessible to
Z-Fact0r consortium members including the commission services.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in a dedicated repository. No expiry date – revisions will
be kept.

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

**DS.HOLONIX.ProductionManagement**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Collections of data from industrial partner’s production plant, operators, and
elaborated data from other Z-Modules. These collections of data contain
information about machine conditions, plant conditions, process KPIs of an
Industrial production plant.

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

Source

</td>  
<td>

Industrial partners’ production plant with its operators and other Z-Modules.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

Industrial partners

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

Partner in charge of data collection

</td>  
<td>

Industrial partner with support of HOLONIX presumably

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

Partner in charge of

data analysis

</td>  
<td>

HOLONIX and Z-Modules

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

Partner in charge of data storage

</td>  
<td>

HOLONIX

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

WPs and tasks

</td>  
<td>

T3.2 in WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

A set of RESTful APIs will be released with documentation of how to require
data from datasets.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

No estimation has been done so far.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Support on the monitoring of production machine, production performance and
process both for operators and other monitoring modules.

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

Data access policy /

Dissemination level

</td>  
<td>

Collections of data of Production management module should be accessible only
for Z-Fact0r consortium partners only.

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

Data sharing, re-use and distribution

</td>  
<td>

Data sharing should not be possible with users outside of the project. A set
of RESTFul APIs will be implemented to share data between partners.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Physical place to store production data has still to be decided, data will be
stored at least for all the duration of the project.

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

**DS.HOLONIX.Repository**

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

**Data Identification**

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

Dataset description

</td>  
<td>

The repository is a collection of dataset coming from various sources
including sensors, operator notes, production line installed at industrial
partners of the project as well as data incoming from Z-modules as results of
their calculation.

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

Source

</td>  
<td>

Z-Fact0r industrial partner’s production plant and Z-modules.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

Z-Modules’ responsible partner and industrial partners.

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

Partner in charge of data collection

</td>  
<td>

Z-Modules and industrial partners.

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

Partner in charge of

data analysis

</td>  
<td>

Various Z-modules

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

Partner in charge of data storage

</td>  
<td>

HOLONIX

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

WPs and tasks

</td>  
<td>

T3.2

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

A set of RESTful APIs will be released with documentation of how to require
data from datasets.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

JSON will be data exchange format between Repository and ZModules. No
estimation of data volume has been done so far.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The datasets collected should be used by various modules of the project for
the pursue of Zero defects production objective.

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

Data access policy /

Dissemination level

</td>  
<td>

Still to be clarified, for the nature of the dataset collected, only the
members of consortium should have rights to access to the datasets with
appropriate authorization/authentication policy.

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

Data sharing, re-use and distribution

</td>  
<td>

No discussion about this matter has been done so far, and should not be shared
with entities outside of Z-Fact0r consortium.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Still to be decided where the collected datasets will be stored definitely.

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

**DS.CONFINDUSTRIA.Events &Roadmapping **

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

**Data Identification**

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

Dataset description

</td>  
<td>

Info regarding the demand for Zero Defect production and a global matching
coming from a Desk Research based on technology brokerage system available at
CONFINDUSTRIA.

List of potential tradefairs and events.

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

</th>  
<th>

List of potential customer/visitors of workshop and potential companies
interested in Z-Fact0r technology.

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

Source

</td>  
<td>

Internet, specific DBs (we have not selected anyone).

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

CONFINDUSTRIA

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

Partner in charge of data collection

</td>  
<td>

CONFINDUSTRIA

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

Partner in charge of

data analysis

</td>  
<td>

CONFINDUSTRIA

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

Partner in charge of data storage

</td>  
<td>

CONFINDUSTRIA

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

WPs and tasks

</td>  
<td>

WP 7: **T7.3** Roadmap for wider adoption and take-up

WP 8: **T8.2** Adoption Plan for increasing Awareness

WP 9: **T9.2** To identify the relevant conference or event

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

It will be used the only available and not confidential (public) data and
documentation coming from Z-Fact0r results in order to define our strategy and
desk research

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

Standards, Format, Estimated volume of data.

</td>  
<td>

\--

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

It will be used the only available and not confidential (public) data and
documentation coming from Z-Fact0r results in order to define our strategy and
desk research

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

Data access policy /

Dissemination level

</td>  
<td>

  * It will be respected the project rules about confidentiality, by using and disseminate the only public data 

  

  * Our results will be public 

  

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

Data sharing, re-use and distribution

</td>  
<td>

  * Our results will be public, they could be shared and re-used as a model: 

  

  * Research method structure 

  

  * Roadmap structure 

  

  * Business Network created 

  

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

Embargo periods

</td>  
<td>

None

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

</td>  
<td>

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

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

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

Data storage (including backup)

</td>  
<td>

Original data and results will be kept in our company server at least until
the all project duration and audit period. Results will be also shared with
partners and kept in the project repository.

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

**DS.ATLANTIS.ES-DSS**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Dataset for insufficient glue detection obtained by cameras and lasers at the
glue implementation machine.

The camera images will be processed and not saved anywhere, while the metadata
of insufficient glue placement will be used for analysis and detection.

Data will be used for early detection of failures.

The metadata will be able to send notifications and alarms to the responsible
control operators and glue workers.

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

Source

</td>  
<td>

The dataset will be collected by using cameras and lasers at the glue machine

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

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

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

Partner in charge of data collection

</td>  
<td>

Various partners related to the specific incident and/or operation.

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

Partner in charge of

data analysis

</td>  
<td>

Various partners related to the specific incident and/or operation.

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

Partner in charge of data storage

</td>  
<td>

ATLANTIS will store data related to ES-DSS (various partners can handle the
rest of the data).

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

WPs and tasks

</td>  
<td>

The data are going to be collected within activities of WP3 and more
specifically within activities of T3.1, T3.2, T3.3 and T3.4.

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

**Standards**

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

Info about metadata

(Production and

</td>  
<td>

The dataset will be accompanied with a detailed documentation of its contents.
Indicative metadata include:

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

storage dates, places, and documentation)

</td>  
<td>

  1. description of the experimental setup (e.g. location, date, etc.) and procedure that led to the generation of the dataset, 

  

  2. annotated detection of insufficient glue, activity, business process, state of the monitored activity. 

  

  

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

Standards, Format, Estimated volume of data.

</td>  
<td>

The data will be stored at XML format and are estimated to be 1GB per day.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The collected data will be used for the development of the activities analysis
and incident detection methods of the Z – Fact0r project and all the tasks,
activities and methods that are related to it.

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

Data access policy /

Dissemination level

</td>  
<td>

The full dataset will be confidential and only the members of the consortium
will have access on it.

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

Data sharing, re-use and distribution

</td>  
<td>

The sharing of this data is yet to be decided along with the industrial
partners.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in a DB. RAID and other common backup mechanism will be
utilized to ensure data reliability and performance improvement and to avoid
data losses.

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

**DS.ATLANTIS.Evaluation**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Values of the KPIs for:

  1. Technical indicators. 

  

  2. User/Stakeholders acceptance. 

  

  3. Indicators for accessing the impact of the project on the factories. 

  

  

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

Source

</td>  
<td>

The dataset will be collected from Z-Fact0r industrial partners, technology
providing partners and User/Stakeholders - the tool/solution beneficiaries.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

The device will be owned by the consortium.

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

Partner in charge of data collection

</td>  
<td>

ATLANTIS with the respective and responsible partners per toolkit/task/plant.

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

Partner in charge of

data analysis

</td>  
<td>

ATLANTIS.

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

Partner in charge of data storage

</td>  
<td>

ATLANTIS will store analysed data related to Solution Evaluation.

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

WPs and tasks

</td>  
<td>

The data are going to be collected through demonstrations in relevant
environment, specifically within T5.3 activity in collaboration with WP6.

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Collected data from the execution of the demonstrations at the operational
environment of the pilot sites (WP6) as well as the users’ acceptance and
overall impact will be analysed and documented - Report on Solution
Validation.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Alphanumeric

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Solution validation will be synthesised and documented in the form of report -
deliverable.

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

Data access policy /

Dissemination level

</td>  
<td>

The full dataset will be confidential, the reports will be public.

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

Data sharing, re-use and distribution

</td>  
<td>

Data will be shared among involved partners.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

To avoid data losses during the project and to ensure data reliability
analysed data will be stored for up to two years after the project life by
ATLANTIS.

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

**DS.ATLANTIS.ReverseSupplyChain**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Dataset for gathered data during the manufacturing process, obtained by
cameras, lasers and other measurement sensors. The camera images will be
processed and not saved anywhere while the metadata for all the other sensors
will be used for analysis in order to activate the Reverse – flow process in
the Reverse Supply Chain.

Data will be used for defect detection in the reverse supply chain. The
metadata will be able to send notifications and alarms to the responsible
machine operators for removal the defected parts, special inspection, return
to previous internal tier (upstream stage) or external tier (other production
line or external supplier). Standards and prototypes shall be included in the
data for comparison with the defected parts and setting acceptance levels.

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

Source

</td>  
<td>

Cameras, lasers and measurement instruments at different points of the
production lines

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

**Partners activities and responsibilities**

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

Partner owner device

</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 data collection

</td>  
<td>

Various partners related to the specific incident and/or operation.

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

Partner in charge of

data analysis

</td>  
<td>

ATLANTIS will analyse the data in order to provide answers and reliable use of
the Reverse Supply Chain.

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

Partner in charge of data storage

</td>  
<td>

ATLANTIS will store data related to Reverse Supply Chain (various partners can
handle the rest of the data).

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

WPs and tasks

</td>  
<td>

The data are going to be collected within activities of WP2 and more
specifically within activities of T2.5.

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

The dataset will be accompanied with a detailed documentation of its contents.
Indicative metadata include:

(a) description of the experimental setup (e.g. location, date, etc.) and
procedure that led to the generation of the dataset,

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

</td>  
<td>

(b) annotated detection of a defective part in the production line, the cause
of the defect, the acceptable standards and limits of the part, as well as
return point in the production process.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

The data will be stored at XML format and are estimated to be 100ΜΒ per day.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The collected data will be used for the development of the activities analysis
and defect detection methods in the production lines of the Z – Fact0r project
plants and all the tasks, activities and methods that are related to it. The
Reverse Supply Chain shall be able to use the data in order to decide whether
or not a defective part should return to a previous tier.

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

Data access policy /

Dissemination level

</td>  
<td>

The full dataset will be confidential and only the members of the consortium
will have access on it.

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

Data sharing, re-use and distribution

</td>  
<td>

The sharing of this data is yet to be decided along with the industrial
partners

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in a DB. RAID and other common backup mechanism will be
utilized to ensure data reliability and performance improvement and to avoid
data losses.

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

**DS.DATAPIXEL.3DPointcloud**

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

**Data Identification**

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

Dataset description

</td>  
<td>

High accuracy and high resolution 3D Pointclouds of scanned parts. The
Pointcloud is a list of 3D points, and can be structured and unstructured

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

Source

</td>  
<td>

DATAPIXEL 3D Scanner

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DATAPIXEL

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

Partner in charge of data collection

</td>  
<td>

DATAPIXEL

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

Partner in charge of

data analysis

</td>  
<td>

DATAPIXEL

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

Partner in charge of data storage

</td>  
<td>

DATAPIXEL and Z-Fact0r repository

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

WPs and tasks

</td>  
<td>

WP2 and WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Metadata includes part identification, date and time of data collection,
equipment. Pointcloud is part of the information associated with the
manufactured parts.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

ASCII list of X Y Z is the most common format. Typically, Pointclouds have a
size between 100 K to 10M points, or 3Mbytes to 300 Mbytes.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Main use will be the automatic detection of defects by two methods: CAD based
inspection and GD&T analysis.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential, except parts authorized by the industrial partners.

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

Data sharing, re-use and distribution

</td>  
<td>

The data will be shared using the Sensor network manager, and stored in the
repository for further future analysis.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

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

**DS.DATAPIXEL.CADModel**

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

**Data Identification**

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

Dataset description

</th>  
<th>

The CADModel is the description of the surfaces and geometries of the designed
part. It is representing the 3D information of the manufactured part model,
and will be utilized for CAD based inspection.

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

Source (e.g. which

device?)

</td>  
<td>

Industrial partner’s CAD modelling software and DATAPIXEL 3D Pointcloud
Analysis software.

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

**Partners activities and responsibilities**

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

Partner owner of the device

</td>  
<td>

Industrial partners (MICROSEMI, INTERSEALS, DURIT) and DATAPIXEL.

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

Partner in charge of the data collection (if different)

</td>  
<td>

Same

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

Partner in charge of the data analysis (if different)

</td>  
<td>

DATAPIXEL

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

Partner in charge of the data storage (if different)

</td>  
<td>

DATAPIXEL and Z-Fact0r repository

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

WPs and tasks

</td>  
<td>

WP2 and WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places) and documentation?

</td>  
<td>

Metadata includes part identification, date and time of data generation. CAD
Model is part of the information associated with the manufactured parts.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

STEP format

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

**Data exploitation and sharing**

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

Data exploitation

(purpose/use of the

data analysis)

</td>  
<td>

Main use will be the automatic detection of deviations based in local regions
and the extraction of nominal values for GD&T analysis.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential, except parts authorized by the industrial partners.

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

(Confidential, only for members of the _CCS_ ) /

Public

</td>  
<td>

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

Data sharing, re-use and distribution

(How?)

</td>  
<td>

The data will be shared by the 3D Pointcloud Analysis module, and stored in
the repository for further future analysis.

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

Embargo periods

(if any)

</td>  
<td>

None

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

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

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

Data storage (including backup): where? For how long?

</td>  
<td>

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

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

**DS.DATAPIXEL.DeviationMaps**

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

**Data Identification**

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

Dataset description

</td>  
<td>

The deviation map is a 3D representation of surface deviations calculated
between a captured Pointcloud and the reference CAD model. The deviation map
is represented as a list of regions with their corresponding deviation.
Typically, the regions are polygonal regions with their associated deviation.

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

Source

</td>  
<td>

DATAPIXEL 3D Pointcloud Analysis software.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DATAPIXEL

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

Partner in charge of data collection

</td>  
<td>

DATAPIXEL

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

Partner in charge of

data analysis

</td>  
<td>

DATAPIXEL

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

Partner in charge of data storage

</td>  
<td>

DATAPIXEL and Z-Fact0r repository.

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

WPs and tasks

</td>  
<td>

WP2 and WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Metadata includes part identification, date and time of data generation.
Deviation Map is part of the information associated with the manufactured
parts.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

A polygonal mesh with an associated deviation number in mm. Most common
formats are STL with annotated deviations and PLY. Typically, deviation maps
have a size between 100 K to 1M polygons, or 10Mbytes to 100 Mbytes.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Main use will be the automatic detection of defects based in local deviations.
A deviation threshold can be defined to identify defects.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential, except parts authorized by the industrial partners.

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

Data sharing, re-use and distribution

</td>  
<td>

The data will be shared by the 3D Pointcloud Analysis module, and stored in
the repository for further future analysis.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

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

**DS.DATAPIXEL.MeasurementPlan**

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

**Data Identification**

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

Dataset description

</td>  
<td>

The MP is a definition of the GD& to be measured in the Pointcloud. The MP
contains a detailed definition of geometrical elements and the tolerances
associated to them. This information is the input to the Geometrical Feature
Extraction module of the

3D Pointcloud Analysis software

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

Source

</td>  
<td>

DATAPIXEL 3D Pointcloud Analysis software. Normally the MP is extracted from
the geometrical information contained in the CAD model

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DATAPIXEL

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

Partner in charge of data collection

</td>  
<td>

DATAPIXEL

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

Partner in charge of

data analysis

</td>  
<td>

DATAPIXEL

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

Partner in charge of data storage

</td>  
<td>

DATAPIXEL and Z-Fact0r repository

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

WPs and tasks

</td>  
<td>

WP2 and WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Metadata includes project identification, date and time of data generation. MP
is part of the project information.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

The standard format for MP can be QIF or DMO.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Main use will be automatic measurement of dimensions and geometries based in
nominal values and tolerances. This information will be used for defect
detection and process analysis.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential, except parts authorized by the industrial partners.

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

Data sharing, re-use and distribution

</td>  
<td>

The data will be shared by the 3D Pointcloud Analysis module, and stored in
the repository for further future analysis.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

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

**DS.DATAPIXEL.MeasurementResults**

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

**Data Identification**

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

Dataset description

</th>  
<th>

The Measurement Results are the set of measurement values extracted from the
Pointcloud based in the MP.

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

Source

</td>  
<td>

DATAPIXEL 3D Pointcloud Analysis software.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DATAPIXEL

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

Partner in charge of data collection

</td>  
<td>

DATAPIXEL

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

Partner in charge of

data analysis

</td>  
<td>

DATAPIXEL

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

Partner in charge of data storage

</td>  
<td>

DATAPIXEL and Z-Fact0r repository.

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

WPs and tasks

</td>  
<td>

WP2 and WP3

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Metadata includes part identification, date and time of data generation.
Measurement Results is part of the information associated with the
manufactured parts.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

The standard format for MP can be QIF or DMO.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Main use will be the automatic detection of based in geometrical deviations.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential, except parts authorized by the industrial partners.

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

Data sharing, re-use and distribution

</td>  
<td>

The data will be shared by the 3D Pointcloud Analysis module, and stored in
the repository for further future analysis.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

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

**DS.CERTH/IRETETH.DataConditioning**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Data collected by DATAPIXEL’s laser system or other complementary data sources
for defect detection.

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

Source

</td>  
<td>

Should be defined by DATAPIXEL.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

DATAPIXEL

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

Partner in charge of data collection

</td>  
<td>

DATAPIXEL + the relevant end user (manufacturer) depending on the use case.

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

Partner in charge of

data analysis

</td>  
<td>

IRETETH/CERTH

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

Partner in charge of data storage

</td>  
<td>

TO BE DEFINED

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

WPs and tasks

</td>  
<td>

WP2 / T2.1 - T2.2

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

Should be discussed between DATAPIXEL and IRETETH/CERTH.

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Should be determined by DATAPIXEL. In IRETETH/CERTH we are open to use
different data formats with a preference in raw data formats. As far as the
volume, the more the better. Ideally, we would like to have hundreds of
measurements per product (e.g. 500 per case including defected and non-
defected).

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

This should be discussed within the relevant partners.

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

Data access policy /

Dissemination level

</td>  
<td>

This should be discussed within the consortium and approved by the DEM.

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

</td>  
<td>

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

Data sharing, re-use and distribution

</td>  
<td>

This should be discussed within the relevant partners.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

We need to see who is responsible for the data storage task.

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

**DS.SIR.RoboticCellData**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Collections of data from SIR robotic deburring cell. These collections of data
contain information about machine conditions, algorithms, machine data, plant
conditions, process KPIs.

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

Source

</td>  
<td>

SIR robotic deburring cell.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

SIR

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

Partner in charge of data collection

</td>  
<td>

SIR with support of technological partners involved in the task.

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

Partner in charge of

data analysis

</td>  
<td>

SIR with support of technological partners involved in the task.

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

Partner in charge of data storage

</td>  
<td>

SIR

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

WPs and tasks

</td>  
<td>

T2.3 in WP2

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

\--

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Mainly consisting in MS documents released using the following formats (.doc,
.pptx and .xls files, images for visualizing and conceptualizing the use cases
will be released as PDF files), UML

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

</td>  
<td>

documents, machine algorithms (various type of informatics languages C#,
RAPID, etc).

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

The datasets collected should be used by SIR to achieve the objectives of
T2.3.

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

Data access policy /

Dissemination level

</td>  
<td>

Confidential

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

Data sharing, re-use and distribution

</td>  
<td>

No discussion about this matter has been done so far, and should not be shared
with entities outside of Z-Fact0r consortium.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Documents will be store in FREEDCAMP document management system. Machine data,
algorithms and machines backups will be store in the SIR internal repository.

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

**DS.SIR.IndustrialPartnersData**

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

**Data Identification**

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

Dataset description

</td>  
<td>

Collections of data from industrial partners. These collections of data
contain information about machine conditions, plant conditions, process KPIs
of an Industrial production plant.

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

Source

</td>  
<td>

Industrial partners’ production plant, internal reports, operators.

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

**Partners activities and responsibilities**

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

Partner owner device

</td>  
<td>

Industrial partners.

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

Partner in charge of data collection

</td>  
<td>

Industrial partner with support of SIR.

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

Partner in charge of

data analysis

</td>  
<td>

Task leader

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

Partner in charge of data storage

</td>  
<td>

Task leader and SIR

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

WPs and tasks

</td>  
<td>

WP1

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

**Standards**

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

Info about metadata (Production and storage dates, places, and documentation)

</td>  
<td>

\--

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

Standards, Format, Estimated volume of data.

</td>  
<td>

Mainly consisting in MS documents released using the following formats (.doc,
.pptx and .xls files, images for visualizing and conceptualizing the use cases
will be released as PDF files) and

UML documents. The metadata standard proposed is the CERIF.

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

**Data exploitation and sharing**

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

Data exploitation (purpose/use of the

data analysis)

</td>  
<td>

Only for members of the CCS.

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

Data access policy /

Dissemination level

</td>  
<td>

The information leading to the preparation of the following deliverable might
be confidential as the following deliverables are marked as confidential:

  * D1.1 Z-Fact0r User requirements DURIT M3 

  

  * D.1.3 Z-Fact0r system architecture EPFL M5 

  

  * D1.5 Report on Z-Fact0r strategy implementation and risk analysis EPFL M18 

  

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

Data sharing, re-use and distribution

</td>  
<td>

For the time being data are expected to be used internally as input by the
other WPs. However, D1.2 Report on the analysis of SoA, existing and past
projects initiatives due by CERTH at M2 and D1.4 Z-Fact0r Use Cases due by
INTERSEALS at M6 are expected to be released publicly.

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

Embargo periods

</td>  
<td>

None

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

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

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

Data storage (including backup)

</td>  
<td>

Documents are stored in FREEDCAMP document management system. Data and
documents will be up to five years after the project completion. Revisions
will be stored in the FREEDCAMP document management system.

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

_2.2.5.2 Dataset per task_

In addition, data information that will be generated in the different tasks,
has been identified by the different partners;  
  
<table>  
<tr>  
<th>

Task: **T1.1- T1.5, T2.1-T2.5, T6.1-T6.3**

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

WP: WP1 + WP2 + WP6

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

WP Leader: SIR

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

Author: G. Tinker (MICROSEMI)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Main aims for MICROSEMI are for the improvement of the dispense process and
its analysis. Other opportunities for the system and the data might be
learning how much glue might be needed for a new size die (prediction) and
checking LCP panels for surface defects prior to dispensing.

  * Explain the relation to the objectives of the project/WP/Task 

  

The data being collected will enable the KPIs to be monitored and to generate
history for prediction and correction of the process.

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)
MICROSEMI preference for data would be:

  * xls for sensor history data 

  

  * xls for a volumetric measurement of the glue dispensed o jpeg images of the surface 

  

  * Is the data generated or collected from other sources under certain terms and conditions? TBC – not believed to be a requirement at this stage 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

TBC – Possibilities of either Pointcloud clouds from DATAPIXEL or micro –
profilometry data generated by CERTH or both may need to be utilised

  * State the expected size of the data (if known) 

  

Currently unknown but Good IT infrastructure at MICROSEMI means Data size
should not be a constraint

  * Standards None 

  

####  3) Ownership

  * Is another organization contributing to the data development? 

  

TBC – If the answer does end up being yes, it will be a member of the Z-Fact0r
project **4) Reuse of existing data**

  * Specify if existing data is being re-used (if any) 

  

No Data is currently being collected other than the process improvement
project that has already been completed. **5) Data use**

  * How will this data be exploited and/or shared/made accessible for verification and re-use? Outline the data utility: to whom will it be useful Much depends on: 

  

Who wants access?

How often they want access?

How big the files are?

MICROSEMI does have an FTP site – terms of access to this will have to be
agreed by MICROSEMI and the members of the Z-Fact0r project. **6)
Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

TBC – this depends a little on the data being collected and if it is deemed
sensitive.

####  7) Storage and disposal

  * How will this data be stored? 

  

Probably on a local PC with the option to back up data (depending on size) to
the MICROSEMI servers at Caldicot.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

</th>  
<th>

Task: **T1.1 -T1.5**

</th>  
<th>

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

WP: 1 USER REQUIREMENTS – SPECIFICATIONS – USE CASE ANALYSIS

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

WP Leader: SIR

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

Author: Marcello Pellicciari (SIR)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Qualitative and quantitative data will be produced:

  1. WP1 data generated and collected are aimed at defining both the user and system requirements and use cases (T.1.1 and T.1.4) 

  

  2. Bibliographic and data-based information (e.g. Cordis) for T.1.2 State of the art to analyse new, live and past projects, initiatives in the field. 

  

  3. Workflow and UML diagrams, blue prints will be generated to design the ZFact0r architecture (T.1.3) 

  

  4. Report on Z-Fact0r strategy and risk analysis (T.1.5) to monitor the status of the manufacturing process in real time. 

  

  

  * Explain the relation to the objectives of the project/WP/Task Data are related to all tasks WP1. (See above) 

  

####  2) Types

  * Are the data digital/hard copies or both? 

  

Digital data and documents will be produced.

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

Data are preserved in their incoming format, Files generated and used will be
mainly consisting in MS documents released using the following formats (.doc,
.pptx and .xls files, images for visualizing and conceptualizing the use cases
will be released as PDF files).

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

No

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Unified Modelling Language will be used

  * State the expected size of the data (if known) Not yet a clear idea. 

  

  * Standards Not at the moment. 

  

####  3) Ownership

 Is another organization contributing to the data development?

To date no other external organization is contributing to the data development
activities of WP1.

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

For the time being data are expected to be used internally as input by the
other WPs. However, D1.2 Report on the analysis of SoA, existing and past
projects initiatives due by CERTH at M2 and D1.4 Z-Fact0r Use Cases due by
INTERSEALS at M6 are expected to be released publicly.

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use? Outline the data utility: to whom will it be useful

D1.2 Report on the analysis of SoA, existing and past projects initiatives due
by CERTH at M2 and D1.4 Z-Fact0r Use Cases due by INTERSEALS at M6 are
expected to be released publicly.

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

The information leading to the preparation of the following deliverable might
be confidential as the following deliverables are marked as confidential:

  * D1.1 Z-Fact0r User requirements DURIT M3 o D.1.3 Z-Fact0r system architecture EPFL M5 

  

  * D1.5 Report on Z-Fact0r strategy implementation and risk analysis EPFL M18 

  

####  7) Storage and disposal

  * How will this data be stored? 

  

Documents are stored in FREEDCAMP document management system. Content creator
upload the relevant file.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Data and documents will be up to five years after the project completion.
Revisions will be stored in the FREEDCAMP document management system.  
  
<table>  
<tr>  
<th>

Task: T.1-USER REQUIREMENTS

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

WP: WP1 + WP6

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

WP Leader: SIR

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

Author: E. Soares (DURIT)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Automated quality control, with high accuracy level and predictive system for
defect generation based on online continuous monitoring.

  * Explain the relation to the objectives of the project/WP/Task 

  

The data collected will enable to detect probability or trends that lead to
defects that normally result in scrapping the parts.

####  2) Types

  * Are the data digital/hard copies or both? 

  

Both

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files) o xls for sensor history data o jpeg images of the defects 

  

  * Is the data generated or collected from other sources under certain terms and conditions? Possibly collected by sensors at an bench top apparatus. 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Optical and physical sensors to be studied.

  * State the expected size of the data (if known) A few MB per type of part. Perhaps 1 GB per day. 

  

  * Standards 

  

####  3) Ownership

  * Is another organization contributing to the data development? Only partners from Z-Fact0r **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) No Data is currently being collected 

  

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? Outline the data utility: to whom will it be useful 

  

System software, cloud where DURIT servers are stored and some local pc. data
will be used mainly by Quality Department **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

Partners from Z-Fact0r can have access during the project. In our premises
access is limited to quality operators.

####  7) Storage and disposal

  * How will this data be stored? 

  

Probably on a local PC + DURIT servers at the cloud.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

five years minimum  
  
<table>  
<tr>  
<th>

Task: **T1.4, T6.2**

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

WP: WP1 (User Requirements), WP6 (Demonstration activities)

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

WP Leader: SIR, INTERSEALS

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

Author: Pierino Izzo (INTERSEALS)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

  * Explain the relation to the objectives of the project/WP/Task 

  

The INTERSEALS actual data are generated and exploited to plan and manage the
Customer orders, to planning the production, getting feedback by the
production phase, managing of the maintenance.

The Z-Fact0r will useful for all the objectives of the software itself:
Z-DETECT, ZPREDICT, Z-PREVENT, (Z-REPAIR), Z-MANAGER.

This data could then be connected to the INTERSEALS ERP and Quality Data
Management.

####  2) Types

  * Are the data digital/hard copies or both? The data are digital. 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files). They could be of two kinds: .xls, SQL formats, emails. 

  

  * Is the data generated or collected from other sources under certain terms and conditions? For Z-Fact0r, there isn’t this possibility. 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

The data for Z-Fact0r will be generate by:

  * FT-IR (Infrared spectroscopy): for material checking. 

  

  * System control (CoMo by Kistler) that concentrate the data from the sensor cavities pressure. 

  

  * Injection moulding machine parameters: these data can be achieved by the connection to the PLC of the injection Machine (the PLC can be Siemens, Omron, Moog). 

  

  * Data from visual and dimensional checking machine (DATAPIXEL will be involved in this) 

  

  * Data from the worker that work beside the production cell and will communicate with the software using Augmented Reality. 

  

  * State the expected size of the data (if known) At the moment, our servers are of about 150Gbyte. 

  

  * Standards 

  

SQL server

####  3) Ownership

  * Is another organization contributing to the data development? 

  

No, we have all the competence to generate and manage the data. **4) Reuse of
existing data**

  * Specify if existing data is being re-used (if any) The existing data are re-used as really useful: 

  

  * for making quotations 

  

  * for process study 

  

  * quality control 

  

  * traceability 

  

  * claim answer 

  

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use?

Outline the data utility: to whom will it be useful See point 4

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

The data could be accessible after signing the INTERSEALS NDA.

####  7) Storage and disposal

  * How will this data be stored? 

  

Workstation server, SQL server

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

At least for 6 months for the dynamic production data and five years for the
static data.  
  
<table>  
<tr>  
<th>

Task: **Task 1.3**

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

WP: WP 1

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

WP Leader: SIR

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/collection 

  

Development of the architecture of the Z-Fact0r system (i.e. functional view,
information view, deployment view, etc.) & the definition and description of
the main components

  * Explain the relation to the objectives of the project/WP/Task 

  

A complete description of the modules included in the detailed view is
provided in order to point out the responsibilities of each module and their
interactions with the global System Architecture

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files) Emails, doc files, .vpp files etc. 

  

  * Is the data generated or collected from other sources under certain terms and conditions? No 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Visual Paradigm V14.0 for component diagrams

  * State the expected size of the data (if known) 

  

Not known

  * Standards 

  

UML for component diagrams

**3) Ownership**

 Is another organization contributing to the data development?

####  ALL Z-Fact0r partners 4) Reuse of existing data

 Specify if existing data is being re-used (if any)

No

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? Outline the data utility: to whom will it be useful 

  

As described in GA document. **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

As described in GA document. Accessible to Z-Fact0r consortium members
including the commission services. Based on further discussions and agreement
between partners, part of data (e.g. overall approach and architecture etc.)
could be published in the form of an article or conference proceedings for
dissemination purposes.

####  7) Storage and disposal

  * How will this data be stored? 

  

All the collected info/data will be delivered in the deliverable D1.3

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project for further research; but it will be with consent of the
consortium members in case the data is to be accessed and used for the purpose
of academic exercise (e.g. teaching and publications)  
  
<table>  
<tr>  
<th>

Task: **Task 1.5**

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

WP: WP 1

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

WP Leader: SIR

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Monitoring the application of the various Z-Fact0r strategies and risk
analysis will determine how well & successful the implementation of the
strategies will be in the use cases, aligned with the project objectives.

  * Explain the relation to the objectives of the project/WP/Task 

  

Data collected and generated will support part, machine and process level
itself continuous monitoring in real time. Actions of correctness will be
suggested in case of error occurrence. Re-evaluations of the deployed
strategies will be conducted. Also, manufacturing equipment, part and process
status measurement analysis will be adapted to provide the means for process
validation. Z-Fact0r strategies developed according to objectives.

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

Data types could be: .doc files, emails, SQL DB programs, .XML files etc.

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Machine sensors, network infrastructure /middleware (device manager)/ shop-
floor (Z-

Fact0r repository for machine processes, part condition and worker’s actions)

  * State the expected size of the data (if known) 

  

Not known

  * Standards 

  

####  3) Ownership

 Is another organization contributing to the data development?

ALL Z-Fact0r partners

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

Data will be reused for corrective actions on the deployed strategies and
actions will be suggested based on correlations by the automatic decision
support mechanism.

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? 

  

Outline the data utility: to whom will it be useful As described in GA
document. **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

Confidential, only for members of the consortium, Commission Services

####  7) Storage and disposal

  * How will this data be stored? 

  

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **Task 2.2**

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

WP: 2

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

WP Leader: EPFL

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

Author: IRETETH/CERTH

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

####  1) Scope

  * State the purpose of the data generation/ collection Data needed for formulation of data driven model. 

  

  * Explain the relation to the objectives of the project/WP/Task 

  

Defect prediction from process inputs, correlated to Z-DETECT Module. **2)
Types**

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

Can accept data in any format (*.csv, *.xls, etc). Data output will be in the
form of matlab files, (*.mat, *.m, etc).

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

Data are collected from the manufacturing processes (end users’ collection
systems)

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

State the expected size of the data (if known)

Standards

####  3) Ownership

 Is another organization contributing to the data development? No

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

No

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? 

  

Outline the data utility: to whom will it be useful As described on GA
document. **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

Confidential, only for members of the consortium, CCS.

####  7) Storage and disposal

 How will this data be stored?

How long is it required to keep the data? Expire date. Will revisions be kept?

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **Task 2.5**

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

WP: WP 2

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

WP Leader: EPFL

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Supervise and provide feedback for all the processes executed in the
production line, evaluating performance parameters and responding to defects,
keeping historical data. Send efficiently alarms to initiate actions, filter
out false alarms, increase confidence levels (through previously acquired
knowledge) of early defect detection and prediction.

  * Explain the relation to the objectives of the project/WP/Task 

  

KMS refers to an information and communication technology system for managing
knowledge in organizations for supporting creation, capture, storage and
dissemination of information. Facilitate the adoption of risk-based thinking
(in line with ISO 9001:2015) at enterprise level by supporting faster and
better decision making at shop-floor. Link the 5 intertwined zero-defect
strategies (i.e. Z-PREDICT, Z-PREVENT, Z-DETECT, ZREPAIR and Z-MANAGE).
Implement the designed Z-MANAGE strategy and interface with MES and/or other
high level manufacturing systems in-place.

  * Provide the inference engine a second layer of autonomous decision support in relation to the 5 Z-Fact0r strategies. 

  

  * Update the monitoring and inspection conditions and constraints of the ES-DSS. 

  

  * Define rights for data sharing and exchanging internally with various enterprise systems and decision making units, as well as externally with customers and suppliers 

  

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)
Data should be available at XML or JSON format.

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

It needs inputs from the Sensor Network (through the Device Manager), the
overall model of Production activities (through Z-Fact0r Repository) and
context – aware knowledge stemming from the Semantic Context Manager
(Ontology)

  * State the expected size of the data (if known) 

  

Estimation of the volume of data can be done only by the source.

  * Standards 

  

####  3) Ownership

 Is another organization contributing to the data development? Yes

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

No

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use? Outline the data utility: to whom will it be useful

Reaction to Incident detection, re-adaptation of the production processes and
notifying components of Z-Fact0r which has subscribed for these events.

####  6) Dissemination Level of Data

Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access? As described on GA document.

####  7) Storage and disposal

  * How will this data be stored? 

  

In a main KM server and also into local terminals when appropriate indications
have been disseminated.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **T2.5 / T3.4**

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

WP: WP2 / WP3

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

WP Leader: CERTH / EPFL

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

Author: Ziazios Konstantinos (ATLANTIS)

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

####  1) Scope

  * State the purpose of the data generation/ collection o Early stage decision support system o Reverse supply chain system 

  

  * Explain the relation to the objectives of the project/WP/Task o Data will be used to model the early stage DSS. 

  

o Models for the supply chain

####  2) Types

  * Are the data digital/hard copies or both? Digital. 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files) o Images o CSV o JSON o Binary 

  

  * Is the data generated or collected from other sources under certain terms and conditions? Collected from sensors. 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

o From laser scanning o From user input o Batch files

  * State the expected size of the data (if known) Several GBs per day. 

  

  * Standards 

  

Not known at this stage.

####  3) Ownership

  * Is another organization contributing to the data development? Only partners of the consortium **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) 

  

No

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use?

Outline the data utility: to whom will it be useful o Used for modelling o To
visualise processes o Create visual KPI’s

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

  * Avoiding storage of sensitive data. Stored encrypted always. 

  

  * Limited access to confidentiality data. 

  

####  7) Storage and disposal

 How will this data be stored?

  * On cloud only for the training / modelling period. 

  

  * No production data will store outside the shop floor. 

  

How long is it required to keep the data? Expire date. Will revisions be kept?

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **T2.1, T2.2, T3.1**

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

WP: WP2 / WP3

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

WP Leader: CERTH / EPFL

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

Author: Toni Ventura (DATAPIXEL)

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

####  1) Scope

  * State the purpose of the data generation/ collection o High accuracy and high resolution 3D Pointcloud of scanned parts. o CAD Model by description of the surfaces and geometries of the designed part. 

    * Deviation map of a 3D representation of surface deviations calculated between a captured Pointcloud and the reference CAD model. 

  

    * MP, definition of the GD&T to be measured in the Pointcloud. 

  

  

  * Explain the relation to the objectives of the project/WP/Task 

  

Data generation of WP2 and WP3 will be connected with Z-DETECT activities, in
particular with T2.1, T2.2 and T3.1.

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

ASCII list of X Y Z, STEP format, STL with annotated deviations and PLY and
QIF or

DMO.

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

DATAPIXEL 3D Scanner, 3D Pointcloud Analysis software and Industrial partner’s
CAD modelling software.

  * State the expected size of the data (if known) 

  

Typically, Pointcloud have a size between 100 K to 10M points, or 3Mbytes to
300 Mbytes and deviation maps have a size between 100 K to 1M polygons, or
10Mbytes to 100 MBytes.

  * Standards 

  

Metadata includes part identification, date and time of data generation,
collection, equipment. Pointcloud, CAD model, deviation map and measurement
results are part of the information associated with the manufactured parts.
Also, MP is part of the project information.

####  3) Ownership

 Is another organization contributing to the data development? Only partners
of the consortium

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

No

####  5) Data use

How will this data be exploited and/or shared/made accessible for verification
and re-use? Outline the data utility: to whom will it be useful

Main use will be the automatic detection of defects by two methods: CAD based
inspection and G&T analysis. Also, for automatic measurement of dimensions and
geometries based in nominal values and tolerances and local deviations. This
information will be used for defect detection and process analysis. The data
will be shared using the Sensor network manager,

3D Pointcloud Analysis module and stored in the repository for further future
analysis **6) Dissemination Level of Data**

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

Confidential, except parts authorized by the industrial partners.

####  7) Storage and disposal

  * How will this data be stored? 

  

Data will be stored in the Z-Fact0r repository and by the 3D Pointcloud
analysis software.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **T3.2**

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

WP: WP3

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

WP Leader: CERTH

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

Author: Simone Parrotta (HOLONIX)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Within this task data from sensors will be integrated and stored in Z-Fact0r.
Retrieved data will came from sensors and systems from industrial partners.

  * Explain the relation to the objectives of the project/WP/Task 

  

The task will define and develop the middleware and related tools for the
Z-Fact0r sensor data integrations.

####  2) Types

  * Are the data digital/hard copies or both? 

  

Digital data will be stored in Cloud Based DB.

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files) 

  

XML, JSON, CSV

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

Proper term and conditions will be defined later during the project

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Data will be collected from: new sensors placed in the shop floor to support
the processes monitoring; PLC; legacy systems.

  * State the expected size of the data (if known) 

  

  * Standards 

  

XML, JSON, CSV

####  3) Ownership

Is another organization contributing to the data development?

Z-Fact0r industrial partners will provide confidential data regarding their
processes. **4) Reuse of existing data**

 Specify if existing data is being re-used (if any)

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? They will be used internally for system testing and validation. 

  

  * Outline the data utility: to whom will it be useful **6) Dissemination Level of Data**

  

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

Data confidentiality/ sensitive have been already mentioned in the GA.
Processes data from industrial consortium partners should be kept confidential
based on internal company policies.

####  7) Storage and disposal

  * How will this data be stored? 

  

Data will be stored within Z-Fact0r repository.

  * How long is it required to keep the data? Expire date. Will revisions be kept? At least five years after the project ends. 

  

  
<table>  
<tr>  
<th>

Task: **Task 3.5**

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

WP: WP 3

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

WP Leader: CERTH

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/collection 

  

Data is required for the Z-Fact0r ontology development. Ontology describes
semantic models. The ontology will be used in order to drive the semantic
framework. Furthermore, it will be used for data integration, visualization,
inferencing/reasoning.

  * Explain the relation to the objectives of the project/WP/Task 

  

Context-aware shop-floor analysis and semantic model for the annotation and
description of the knowledge to represent manufacturing system performance.
The ontology will describe the basic entities of the project and model
relevant structures of multi-stage manufacturing processes.

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

Required input will be data from Z-Fact0r repository (data concerning
machines, workers, actors, activities and processes, production data logs,
etc.), e.g. in XML, CSV, etc.

Generated output will be the semantic enrichment of shop-floor data for
representation of processes, actors, alarms, actions, work-pieces/products,
etc., e.g. as RDF Triplets

  * Is the data generated or collected from other sources under certain terms and conditions? Data from Z-Fact0r repository (data concerning machines, workers, actors, activities and processes, production data logs, etc.) 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Data will be stored in a dedicated repository

  * State the expected size of the data (if known) 

  

Less than 1GB

  * Standards 

  

W3C-OWL, RDF

####  3) Ownership

  * Is another organization contributing to the data development? Z-Fact0r End-users (MICROSEMI, INTERSEALS, DURIT) **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) 

  

No

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? Outline the data utility: to whom will it be useful 

  

The ontology will be used in order to drive the semantic framework.
Furthermore, it will be used for data integration, visualization,
inferencing/reasoning. **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

Accessible to Z-Fact0r consortium members including the commission services

####  7) Storage and disposal

  * How will this data be stored? 

  

The Ontology will be uploaded in a server where it will be accessible to
Z-Fact0r consortium members including the commission services

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **T4.1 - T4.3**

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

WP: 4

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

WP Leader: Brunel University London

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

Author: Brunel

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

The purpose of the data collection and generation is to facilitate the
building of the eventbased model, green scheduler using the KPIs,
implementation of the scheduler and extracting cost functions. The raw data
will be collected from plants and the output will provide the metrics for
process and control optimisation to minimise defect.

  * Explain the relation to the objectives of the project/WP/Task 

  

The fulfilment of the tasks will lead to achieving: An event-base modelling
platform and green scheduler to identify the key parameters that influence and
have the largest effect of creation of defects in the productions process as
well as energy consumption and carbon emissions. They will assist in
customisation of the measurement of the KPIs for each industrial partner in
the consortium, and build the framework for implementing control and
optimisation solutions to minimise defect.

####  2) Types

  * Are the data digital/hard copies or both? 

  

Mainly digital

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

Mainly DB driven files that can be converted to CSV, JSON, TXT, HTML, and SML

  * Is the data generated or collected from other sources under certain terms and conditions? The agreed T&C of the consortium 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

PLC, SCADA, Production Management Systems, Internet, and project Intranet.

  * State the expected size of the data (if known) Large but not known at this stage. 

  

  * Standards 

  

Control Area Network, TCP/IP.

####  3) Ownership

  * Is another organization contributing to the data development? Members of the consortium. **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) 

  

N/A

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use? Outline the data utility: to whom will it be useful

Members of the consortium, in addition the results of the R&D project will be
disseminated according to the consortium agreement in the form of conference,
journal, specialist magazine/website outlets.

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

N/A within the sensitive and project oriented data will remain within the
boundaries of the consortium

####  7) Storage and disposal

  * How will this data be stored? 

  

In local data storages defined and design specifically for the project. Brunel
University SERG Laboratories will have a dedicated storage and computing
facility for the project. The data will then be stored and utilised in
accordance with the T&C of the consortium agreement.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project for further research; but it will be with consent of the
consortium members in case the data is to be accessed and used for the purpose
of academic exercise (e.g. teaching and publications)  
  
<table>  
<tr>  
<th>

Task: **Task 4.2**

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

WP: WP 4

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

WP Leader: BRUNEL

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

For the validation and verification of the KPI models, i.e. Productivity,
Efficiency, Quality (Customer Satisfaction), Environmental Impact, and
Inventory levels.

  * Explain the relation to the objectives of the project/WP/Task 

  

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)

.docs & formats for discrete event simulation (descriptive) models using off-
the-shelf simulation packages

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Already installed actuators and sensors will be used for monitoring and
evaluating the KPIs.

  * State the expected size of the data (if known) 

  

N/A

  * Standards 

  

####  3) Ownership

  * Is another organization contributing to the data development? **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) 

  

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? 

  

Outline the data utility: to whom will it be useful

Based on the prediction of the expected results and depending on the
measurements received for the evaluation of the KPIs through the use-cases
utilization they will be finetuned in order for afterwards on-line & real-time
application of them. Corrective actions will be considered for the production
line based on the results received. **6) Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

The final deliverable report associated with this task will be public.

All the other data will be Accessible to Z-Fact0r consortium members.

####  7) Storage and disposal

  * How will this data be stored? 

  

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project  
  
<table>  
<tr>  
<th>

Task: **Task 4.4**

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

WP: WP 4

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

WP Leader: BRUNEL

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

Author: EPFL

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Design and development of the cost functions for each of the KPIs.

  * Explain the relation to the objectives of the project/WP/Task 

  

Models will be industry specific and will be defined as monetary loss
functions due to loss of Productivity (OEE, OLE, Resource Utilisation),
Efficiency (energy consumption per produced unit), Quality (process and
product quality loss models), Environmental Loss (emissions of pollutants per
produced unit), and Inventory (storage, and work-in-process).

####  2) Types

  * Are the data digital/hard copies or both? Digital 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected (for example .xls files, .ppt files, emails, .doc files) .xls , .doc files 

  

  * Is the data generated or collected from other sources under certain terms and conditions? 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Financial data from end-users.

  * State the expected size of the data (if known) 

  

  * Standards 

  

####  3) Ownership

 Is another organization contributing to the data development? Z-Fact0r end-
users.

####  4) Reuse of existing data

 Specify if existing data is being re-used (if any)

No

####  5) Data use

  * How will this data be exploited and/or shared/made accessible for verification and re-use? 

  

Outline the data utility: to whom will it be useful

At a second stage, a validation and verification process of the direct
observations and experiments on the Shop-floor and direct measurement of costs
against system state and contrastively with the simulated ones. **6)
Dissemination Level of Data**

  * Confidentiality/ Sensitive data. If data cannot be made available, explain why. Who will have access? 

  

####  7) Storage and disposal

  * How will this data be stored? 

  

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **T7.3, T8.2, T9.2**

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

WP: 7-8-9

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

WP Leader: INOVA+, CETRI

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

Author: CONFINDUSTRIA

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

####  1) Scope

  * State the purpose of the data generation/ collection 

  

Regularly, Data generation and Collection is an important requirement aimed to
develop activities/tasks, to allow Analysis, to measure performances and to
measure the achievement of own objectives.

  * Explain the relation to the objectives of the project/WP/Task 

  

Data generation, and, in particular, data collection will be useful in order
to develop market analysis and Customer Adoption Plan. We also recognize the
importance of these options, generate and collecting data, by thinking to the
planned workshops, in which results achieved will be shared (in respect to the
privacy needed).

####  2) Types

  * Are the data digital/hard copies or both? Mainly digital. 

  

  * What types of data will the WP generate/collect? Specify the types and formats of data generated/collected 

  

.xls files, .ppt files, emails, .doc files

  * Is the data generated or collected from other sources under certain terms and conditions? Since we will have to use available info and results from other WP we will respect the required IP protection, confidentiality of data. 

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Data will be collected from website, available DB and we will use the only not
confidential results/information that we could share in order to develop our
tasks (Roadmapping, Customer Adoption plan and DCE).

  * State the expected size of the data (if known) 

  

Unknown

  * Standards 

  

####  3) Ownership

  * Is another organization contributing to the data development? **4) Reuse of existing data**

  

  * Specify if existing data is being re-used (if any) 

  

We will use existing data coming from web, available surveys or other WPs.

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use?

Outline the data utility: to whom will it be useful

For their definitions and objective, our tasks and results will be useful for
the all project partners and some of them for some potential customers, since
our tasks imply Partners and customers sharing.

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?

No confidentiality.

####  7) Storage and disposal

  * How will this data be stored? 

  

Z fact0r Shared digital folders.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.  
  
<table>  
<tr>  
<th>

Task: **8.1-8.5 & 9.1-9.6 **

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

WP:8,9

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

WP Leader: CETRI

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

Author: Dr Souzanna Sofou (CETRI)

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

####  1) Scope

  * State the purpose of the data generation/ collection 

    1. Website: project dissemination and product innovation delivery. 

  

    2. Innovation Management Strategy: Form the IM strategy for the ultimate use and dissemination of project Results. 

  

    3. Innovation Management Roadmap: Design and implement WPs 8 and 9\. 

  

    4. DMP Questionnaire: Manage Research Data, MetaData, before and after project duration. 

  

    5. Deliverables: [D.8.1-D.8.5], [D9.1-D9.5]: as explained in the vi) W. vii) Publications: dissemination and communication activities. viii) Z-Fact0r leaflet: communication activity for project wider acceptance. 

  
  

  

ix) Z-Fact0r poster: communication activity for project wider acceptance.

  * Explain the relation to the objectives of the project/WP/Task As explained above 

  

####  2) Types

  * Are the data digital/hard copies or both? 

  

_Digital:_

i) Website ii) Innovation Management Strategy iii) Innovation Management
Roadmap iv) DMP Questionnaire

  5. Deliverables: [D.8.1-D.8.5], [D9.1-D9.5] 

  

  6. Publications (hard copies may also be sent for journal & conference publications) _Hard Copies:_

  

  7. Z-Fact0r leaflet viii) Z-Fact0r poster 

  

  

  * What types of data will the WP generate/collect? Specify the types and formats of data 

  

generated/collected (for example .xls files, .ppt files, emails, .doc files)  
  
<table>  
<tr>  
<th>

_i)_ Website

</th>  
<th>

developed by wordpress

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

_ii)_ Innovation Management Strategy

</td>  
<td>

.ppt and .pdf file

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

_iii)_ Innovation Management Roadmap:

</td>  
<td>

.xls file

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

_iv)_ DMP Questionnaire:

</td>  
<td>

.doc file

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

_v)_ Deliverables: [D.8.1-D.8.5], [D9.2-D9.5]

</td>  
<td>

doc files, .pdf files website

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

_vi)_ Publications

</td>  
<td>

.doc files, .pdf files

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

_vii)_ Z-Fact0r leaflet

</td>  
<td>

.cdr file, .ppt file, .pdf file

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

_viii)_ Z-Fact0r poster

</td>  
<td>

.cdr file, .ppt file, .pdf file

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

  * Is the data generated or collected from other sources under certain terms and conditions? i), iii), Data taken also from the GA. iv) Data collected from participants. 

    5. Data generated during project duration, data from other deliverables will be used. 

  

    6. Research Data generated. 

  

    7. Data taken also from the GA. 

  
  

  

  * How is generated/collected? Specify the origin of the data and instruments/tools that will be used. 

  

Not applicable for WP8 and WP9.

  * State the expected size of the data (if known) For digital files: less than 100Mb. 

  

For Hard Copies:

Z-Fact0r leaflet: print on both sides A4 size,

Z-Fact0r poster: print on one side, according to conference restrictions.

  * Standards 

  

####  3) Ownership

According to the ownership model.

  * Is another organization contributing to the data development? 

  

According to the ownership model. **4) Reuse of existing data**

  * Specify if existing data is being re-used (if any) 

  

Data from other WP´s might be used in dissemination and communication files.

####  5) Data use

 How will this data be exploited and/or shared/made accessible for
verification and re-use? Outline the data utility: to whom will it be useful

All WP8 and 9 data will be useful to the consortium for the ultimate use and
dissemination of project results.

####  6) Dissemination Level of Data

 Confidentiality/ Sensitive data. If data cannot be made available, explain
why. Who will have access?  
  
<table>  
<tr>  
<th>

Website

</th>  
<th>

Public

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

Innovation Management

Strategy

</td>  
<td>

Private, the DEM has created the file, only the project partners have access

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

Innovation Management Roadmap:

</td>  
<td>

Private, the DEM has created the file, only the project partners have access

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

DMP Questionnaire:

</td>  
<td>

Private, Only the project partners have access

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

Deliverables: [D.8.1D.8.5], [D9.1-D9.5]:

</td>  
<td>

D8.1, D8.2, D8.3, D8.5, D9.2, D9.3, D9.5: Confidential D8.4, D9.1, D9.4:
Public

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

Publications

</td>  
<td>

Public, dissemination rules apply

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

Z-Fact0r leaflet

</td>  
<td>

Public, dissemination rules apply

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

Z-Fact0r poster

</td>  
<td>

Public, dissemination rules apply

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

####  7) Storage and disposal

  * How will this data be stored? 

  

All digital files will be stored in FREEDCAMP All hard copy files will be
stored by the DEM as well as all consortium parties.

  * How long is it required to keep the data? Expire date. Will revisions be kept? 

  

Duration of the project, and potentially five years after the completion of
the project.

_2.2.5.3 Dataset per WP_

Data information of the partners has been used to define the complete RDI that
will be generated in each WP;  
  
<table>  
<tr>  
<th>

**WP1**

</th>  
<th>

**User requirements, specifications, use case analysis**

</th>  
<th>

WP leader: **SIR**

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

**Objective** : Development of the architecture of the Z-Fact0r system and the
definition and description of the main components. A complete description of
the modules included in the detailed view in order to point out the
responsibilities of each module and their interactions with the global System
Architecture. Qualitative and quantitative data generated and collected are
aimed at defining both the user and system requirements and use, prepare the
bibliographic and databased information, design the workflow and UML diagrams
and report on Z-Fact0r strategy and risk analysis to monitor the status of the
manufacturing process in real time.

**Data description:** The data being collected will enable the KPI’s to be
monitored and to generate history for prediction and correction of the
process. Digital data and documents will be preserved in their incoming
format, files generated and used will be mainly consisting in MS documents
released using the following formats (.doc, .pptx, .vpp and .xls files,
emails, SQL DB programs, images for visualizing and conceptualizing the use
cases will be released as PDF files).

**Instrument and tools:** Unified Modelling Language, TBC for either
Pointclouds or micro– profilometry data. Machine sensors, network
infrastructure /middleware (device manager)/ shopfloor (Z-Fact0r repository
for machine processes, part condition and worker’s actions).  
  
<table>  
<tr>  
<th>

**WP2**

</th>  
<th>

**Production-process monitoring, detect life-cycle management and
remanufacturing**

</th>  
<th>

WP

**EPFL**

</th>  
<th>

leader:

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

**Objective** : Data generation will be needed for formulation of data driven
model for the defect prediction from process inputs, correlated to Z-DETECT
Module. Supervise and provide feedback for all the processes executed in the
production line, evaluating performance parameters and responding to defects,
keeping historical data. Send efficiently alarms to initiate actions, filter

out false alarms, increase confidence levels (through previously acquired
knowledge) of early defect detection and prediction.

**Data description:** Data generated will be digital and any format data can
be accepted (.CSV, .XLS, etc). However, data output will be in the form of
matlab files, (.XLM, .JSON, .MAT, .M, etc).

**Instrument and tools:** Inputs from the Sensor Network (through the Device
Manager), the overall model of Production activities (through Z-Fact0r
Repository) and context – aware knowledge stemming from the Semantic Context
Manager (Ontology) will be necessary.

**Terms & Conditions of data generated: ** Data are collected from the
manufacturing processes (end users’ collection systems).  
  
<table>  
<tr>  
<th>

**WP3**

</th>  
<th>

**Data management and early stage DSS for inspection and control**

</th>  
<th>

WP leader: **CERTH**

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

**Objective** : Data is required for the Z-Fact0r ontology development.
Ontology describes semantic models for the annotation and description of the
knowledge to represent manufacturing system performance. The ontology will be
used in order to drive the semantic framework. Furthermore, it will be used
for data integration, visualization, inferencing/reasoning. Data from sensors
will be integrated and stored in Z-Fact0r. Retrieved data will came from
sensors and systems from industrial partners.

**Data description:** Digital data will be stored in Cloud Based DB and
required input will be data from Z-Fact0r repository (data concerning
machines, workers, actors, activities and processes, production data logs,
etc.). Generated output will be the semantic enrichment of shop-floor data for
representation of processes, actors, alarms, actions, work-pieces/products,
etc., e.g. RDF Triplets, .CSV, .XML, .JSON.

**Instrument and tools:** Data will be collected from new sensors placed in
the shop floor to support the processes monitoring; PLC; legacy systems.

**Data re-use:** The ontology will be re-used in order to drive the semantic
framework. Furthermore, it will be used for data integration, visualization,
inferencing/reasoning.  
  
<table>  
<tr>  
<th>

**WP4**

</th>  
<th>

**System modelling for fast forward cost functions**

</th>  
<th>

WP leader: **BRUNEL**

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

**Objective** : The purpose of the data collection and generation is to
facilitate the building, validation and verification of the KPI models,
implementation of the scheduler and extracting cost functions.

The raw data will be collected from plants and the output will provide the
metrics for process and control optimisation to minimise defect.

**Data description:** Data generate will be mainly digital and DB driven files
can be converted to CSV, XLS, TXT, HTML and XML.

**Instrument and tools:** Data and instruments that will be used are PLC,
SCADA, Production Management Systems, Internet, and project Intranet. Already
installed actuators, sensors and financial data from end-users will be used
for monitoring and evaluating the KPIs.

**Data re-use:** Data reutilization will be fine-tuned in order for afterwards
on-line & real-time application of them and corrective actions will be
considered for the production line based on the results received.  
  
<table>  
<tr>  
<th>

**WP5**

</th>  
<th>

**Integration & Testing Validation **

</th>  
<th>

WP leader: **ATLANTIS**

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

**Objective** : Diverse set of technologies will be developed and all s/w and
h/w components and platforms will be integrated throughout a predefined
integration methodology. The technology validation plan is to be defined and
executed while applying corrective design and reimplementation on all detected
errors. Furthermore, the methodology validation throughout the demonstration
in relevant environments will be used as well as the evaluation data and
feedback that are going to be collected, analyzed and documented.

**Data description:** Data generated will be made available from the Z-Fact0r
components that will be integrated into the complete system. Multiple formats
will be available, however, all compatible to commonly agreed standards, most
probably Business to Manufacturing Markup Language (B2MML) in XML form.
Moreover, from the evaluation part of the WP data will come out in XLS format.

**Instrument and tools:** Data will be provided by the Z-Fact0r components
that form the 5 strategies. For this WP, primary, non-analysed data are not
considered, rather than the results of their analysis by the Z-Fact0r tools
and components. Data related to end user evaluation will be most probably
collected using online forms and questionnaires, that will allow transfer into
XLS files.

**Data re-use:** The collected data will be evaluated and considered in order
to reach a better understanding of the processes and activities evolved in the
shop-floors. Combined with the input from the technical validation plan this
will lead to fine-tuning of the Z-Fact0r components and the lessons learned
could be transformed into actionable knowledge.  
  
<table>  
<tr>  
<th>

**WP6**

</th>  
<th>

**Demonstration activities**

</th>  
<th>

WP leader: **INTERSEALS**

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

**Objective** : Automated quality control, with high accuracy level and
predictive system for defect generation based on online continuous monitoring.
The data collected will enable to detect probability or trends that lead to
defects that normally result in scrapping the parts.

**Data description:** Data generate will be digital and hard copies and data
format will be .xls for sensor history data and volumetric measurement and
.jpeg images of the defects, and also SQL formats, emails, etc.

**Instrument and tools:** Possibly collected by sensors at a bench top
apparatus and optical and physical sensors to be studied. FT-IR (Infrared
spectroscopy): for material checking. System control (CoMo by Kistler) that
concentrate the data from the sensor cavities pressure. Injection moulding
machine parameters: achieved by the connection to the PLC of the injection
Machine (the PLC can be Siemens, Omron, Moog). Data from visual and
dimensional checking machine. Data from the worker that work beside the
production cell and will communicate with the software using Augmented
Reality.

**Data re-use:** The existing data are re-used as really useful for making
quotations, for process study, quality control, traceability and claim answer.  
  
<table>  
<tr>  
<th>

**WP 7,**

**8 & 9 **

</th>  
<th>

**Valorization, market replication,**

**dissemination/ communication/exploitation**

</th>  
<th>

WP leader **: INNOVA, CETRI**

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

**Objective** Data generation and collection is an important requirement to
develop activities/tasks, allow analysis, measure performances and measure the
achievement of WP objectives as: Website (dissemination and innovation
delivery), DMP Questionnaire (Manage Research Data, MetaData, before, during
and after project duration), Innovation Management Strategy (for the ultimate
use and dissemination of results) and Roadmap (planning WP7, design and
implement WPs 8 and 9), Publications (dissemination and communication
activities), Z-Fact0r leaflet and poster (communication activity wider
acceptance) and Market analysis and Customer Adoption Plan.

**Data description:** Data generated will be digital for Website, Innovation
Management Strategy, Innovation Management Roadmap, DMP Questionnaire,
Deliverables and Publications (hard copies may also be sent for journal &
conference publications), and hard copies in the case of ZFact0r leaflet and
poster. Format of data generated will be .xls, .ppt, .pdf, .doc and .cdr files
and emails.

**Instrument and tools:** Data will be collected from website and available
DB, with only nonconfidential results/information that could be shared for the
development of WP activities (Roadmapping, Customer Adoption plan and DCE).

In conclusion, data and data management-related challenges under Z-Fact0r are
identified and addressed mainly within WP1 (T1.1, T1.4), WP2 and WP3. As
described in the proposal, data to be used in the project will include: on-
line (nearly) real-time and historical data related to (i) the product
(desired specifications; quality inspection results, etc.); (ii) the
production equipment and environment (e.g. temperature, pressure, vibrations,
etc.); (iii) manufacturing/ production and maintenance (e.g. capacity,
planning, etc.). Sources of these data will be: existing sensors and actuators
(such as sensors embedded in production machinery, quality inspection
equipment, etc.), as well as new novel sensors and actuators (such as laser
scanning, visual and/or IR cameras, noncontact profilometers, etc.), and
enterprise systems. The type of sensors/ actuators and data to be used will be
defined and finalized per Z-Fact0r use case on the basis of the required
metrics at product and workstation level at single manufacturing stage, and
also at multiple stage. Additionally, non-research data collected related to
Innovation Management like the IPR registry that includes the IP strategy per
Result are confidential and are only stored in the FREEDCAMP repository and
the website private area, with no access rights for members outside the
consortium.

###  2.2.6 Policies for access, sharing and re-use

Data generated during Z-Fact0r project will be confidential. Ownership and
management of intellectual property and access will be limited to the project
consortium partners. For this purpose, policies for access, sharing, and re-
use have been established:

_2.2.6.1 Partners Background_

Partners have identified their background for the action (data, know-how or
information generated before they acceded to the Agreement), which will be
accessible to each other partners to implement their own tasks (under to legal
restrictions or limits previously defined in the CA). The partners should be
able to access, mine, exploit, reproduce and disseminate the data. This should
also help to validate the results presented in scientific publications. The
partner´s background, acquired prior to the starting date of the project, will
remain the sole property of the originating partner, provided that it was
presented in the CA.

_2.2.6.2 Data Ownership and Access_

The full dataset will be confidential and only the members of the consortium
will have access on it.

Special consideration will be taken for the project dissemination dataset
(e.g. leaflet, brochures, posters, etc.) that will be considered as public
information. As described in GA, data generated are expected to be used
internally as input by the other WPs. All the partners will have free-access
to the results generated during the project, the information needed for
implementing their own tasks under the action and for exploiting their own
results. Also, this information will be available to EU institutions, bodies,
offices or agencies, for developing, implementing or monitoring EU policies,
however such access rights are limited to non-commercial and non-competitive
use.

Regarding ORD Pilot, data that will be generated in the OA will be decided
during the course of the project and can include; final peer-reviewed
scientific research articles that will be published in the online repository
after the publication, research data including data underlying publications,
curated data and/or raw data and public deliverables of the project (described
in GA). If any document or dataset are decided to become of OA, a special
section into the data management portal (FREEDCAMP) will be created that
should provide a description of the item and link to a download section. Of
course, these data will be anonymized, so as not to have any potential ethical
issues with their publication and dissemination.

_2.2.6.3 Naming rules_

All data files will be saved using a standardized, consistent file naming
protocol agreed by the project partners, which will include relevant metadata
to ensure their accessibility. The metadata standard proposed is the CERIF.

_2.2.6.4 Storage Information_

Documents of the dataset will be stored at the data management portal (
**FREEDCAMP** ) created and maintained by CERTH/ITI, while links to the portal
will exist at the Z-Fact0r website. The Data Management Portal developed by
the project ( **FREEDCAMP** ) in the context of the ORD Pilot, allows the
efficient management of the project’s datasets and provides the proper OA of
them for further analysis and reuse.

The dataset will remain at the data management portal for the whole project
duration, as well as for at least 2 years after the end of the project.

Finally, after the end of the project, the portal is going to be accommodated
with other portals at the same server, so as to minimize the needed costs for
its maintenance.

_2.2.6.5 Data sharing and dissemination_

Data will be reused for corrective actions on the deployed strategies and
actions will be suggested based on correlations by the automatic decision
support mechanism. Research data results will be disseminated according to the
CA in the form of conference, articles in a journal, specialist
magazine/website outlets or conference proceedings for dissemination purposes.

All patent applications and all other publications will require prior
agreement in respect to content and the publication media. To this end, each
partner should notify the consortium members about the content and material
they wish to publish/disseminate and a 21 days’ evaluation period will be
provided as stated in the CA.

_2.2.6.6 IPR management and security_

As an innovation action close to the market, Z-Fact0r project covers high-TRL
technologies and aims at developing marketable solutions. The project
consortium includes nine industrial partners from the private sector, in
particular, CETRI, ATLANTIS (Technical Management), HOLONIX, DATAPIXEL, SIR,
INOVA, MICROSEMI (demonstrator/end user), INTERSEALS

(demonstrator), and DURIT (demonstrator). Those partners obviously have
Intellectual Property Rights on their technologies and data, on which their
economic sustainability is at stake. Consequently, the Z-Fact0r consortium
will protect that data and get approval of concerned partners before every
data publication.

The data management portal will be equipped with authentication mechanisms, so
as to handle the identification of the persons/organizations that download
them, as well as the purpose and the use of the downloaded dataset.

_2.2.6.7 Data expire date_

Copyright statements of the Z-Fact0r project will protect any written material
produced during its lifetime. As described in GA, the information and data
supplied by all project partners and documents produced during the project
will be protected for a period of five years after the project completion
unless there are agreements between the partners.

After the end of the project, the partners should keep for five years the
original documents, digital and digitalized documents, records and other
supporting documentation in order to prove the proper implementation of the
action and the costs they declare as eligible.

##  2.3 Data currently being produced in Z-Fact0r

This version of the DMP does not include the actual metadata about the data
being produced in ZFact0r because there is no dataset generated or collected
until delivery date of this deliverable (M6).

Further details will be provided in the next updated version.

#  3 Data Management related to Zero-defects Manufacturing

The quality and performance data of the Manufacturing enterprises will be
considered private and will only be available after granting permission. On
the other hand, the research data about modelling procedures, KPI validation,
event modelling, inspection and real-time quality control, as well as the
system optimization, which will be collected/generated during Z-Fact0r will be
distributed freely.

#  4 Data Management Portal (FREEDCAMP)

The Data Management Portal, a web based portal name as “FREEDCAMP”, is being
used within the Z-Fact0r project for the purposes of the management of the
various datasets that will be produced by the project, as well as, for
supporting the exploitation perspectives for each of those datasets. FREEDCAMP
Portal will need to be flexible in terms of the parts of datasets that are
made publicly available. Special attention is going to be given on ensuring
that the data made publicly available violates neither IPR issues related to
the project partners, nor the regulations and good practices around personal
data protection.

##  4.1 FREEDCAMP portal functionalities

The FREEDCAMP Portal is accessed through a web based platform which enables
its users to easily access and effectively manage the various datasets created
throughout the development of the project.

Regarding the user authentication, as well as the respective permissions and
access rights, the following three user categories are foreseen:

  * **Admin;** the Admin has access to all of the datasets and the functionalities offered by the DMP and is able to determine and adjust the editing/access rights of the registered members and users (OA area). Finally, the Admin is able to access and extract the analytics, concerning the visitors of the portal. 

  

  * **Member;** when someone successfully registers to the portal and is given access permission by the Admin, she/he is then considered as a “registered Member”. All the registered members will have access to and be able to manage most of the collected datasets. 

  

Knowledge sharing and public documents, apart from the admin and the
registered members, as **OA** area will be available for users who will not
need to register and they will have access to some specific datasets, as well
as to project outcomes.

Figure 1 shows the Login page of the FREEDCAMP portal.

Figure

1\.

Login Page of the

FREEDCAMP

Portal

FREEDCAMP portal will be easily and effectively managed by the members. A
variety of graphs, pie charts etc. is going to be employed for helping members
to easily understand and elaborate the data. In particular, the architecture
of the portal presents special interfaces organized to comply the information.

All tasks and datasets available in the DMP will be accompanied by a short
description of the item (Figure 2 and 3).

Figure 2. Data access page of the FREEDCAMP portal.

Figure

3\.

F

ile access of the

FREEDCAMP

P

ortal.

Dataset will be structured in three different folders into FREEDCAMP portal;
Tasks, Discussion, Files. Draft documents and deliverables, and other data
will be uploaded on specific tasks folders, and final version documents will
be uploaded into the file section of appropriate folder.

In addition, technical and progress meetings will be scheduled in the
FREEDCAMP portal calendar (Figure 4).

Figure 4. Calendar access of the FREEDCAMP Portal.

##  4.2 Data Backup: Private Area of the Project Website

As described in Deliverable 9.1, the website private area can be used by all
the partners:

i) for storage of files and confidential deliverables ii) for providing
feedback on work in progress iii) for exchanging information about upcoming
events, conferences, etc.

The website Private Area is only accessible by the consortium partners using a
username and password, and will be used as a backup repository to store data
that are either confidential or data that will be made public after a release
date that has been identified by the data owner.

##  4.3 Open Access Section

A special free access section into the data management portal (FREEDCAMP) will
be created to upload the documents, data and datasets and other information
that are decided to become of OA. The description of the item and the link to
a download section will be available into this section. Of course, these data
will be anonymized, so as not to have any potential ethical issues with their
publication and dissemination.

#  5 Future Work

A spreadsheet has been created that will be used throughout the project for
the continuous logging of data and datasets, as well as the related
information that has been previously presented. Figure 5 shows the spreadsheet
of Z-Fact0r data and datasets.

Figure 5. Spreadsheet of Z-Fact0r data and datasets.

Additionally, the release date of the datasets that will be available in the
open research data pilot will be defined in this xls.

More specifically, after the IP protection route has been defined for each
“result” in the IPR registry currently being developed, dissemination actions
will take place for some of them (for example for those for which a patent
application has been submitted). As soon as a dissemination action is
complete, data can be uploaded in the open research data pilot.

##  5.1 Roadmap of actions to update the DMP

This deliverable is a dynamic document and will be updated and augmented
throughout the whole project lifecycle with new datasets and results according
to the progress of the activities of the ZFact0r project. Also, the DMP will
be updated to include possible changes in the consortium composition and
policies over the course of the project.

For that purpose, the final version of this report will be delivered 6 month
before the end of the project (M36), reflecting on lessons learnt and
describing the plans implemented for sustainable storage and accessibility of
the data, even beyond the project’s duration.

#  6 Conclusions

This report includes the DMP and describes the RDI that will be generated
during Z- Factor project and the challenges and constraints that need to be
taken into account for managing it. In addition, it describes the updated
procedures and the infrastructure used in the project to efficiently manage
the produced data, named as FREEDCAMP Portal. The DMP is identified as
starting point for the discussion with the community about the Z-Fact0r data
management strategy and reflects the procedures planned by the work packages
at the beginning of the project.

An elaborated questionnaire has been distributed between the consortium
partners, asking them what kind of data they were expecting to produce and
collect during the project. From this information, it has become clear that
currently only work packages 1, 2 and 3, are planning to generate or collect
data that can be classified as relevant information according to the
definition of the European Commission. Nonetheless, DMP is not a fixed
document and it can be the case that this situation evolves during the
lifespan of the project. Thus, the DMP will be updated and augmented with new
datasets and results twice during project lifetime with the Project Periodic
Reports.

Regarding storage information, documents generated during the project will be
stored in FREEDCAMP Portal which is the document management system of the
project. This information, data and documents produced during the project will
be protected for a period of two years after the project completion, as it is
described in GA.

#  7 Glossary

##  Participant Information Sheet

The information sheet is an important part of recruiting research
participants. It ensures that the potential participants have sufficient
information to make an informed decision about whether to take part in your
research or not

(
_http://www.kcl.ac.uk/innovation/research/support/ethics/training/infosheet.aspx_
).

##  Consent Form

A form signed by a participant to confirm that he or she agrees to participate
in the research and is aware of any risks that might be involved.

##  Metadata

Metadata is data that describes other data. Meta is a prefix that in most
information technology usages means "an underlying definition or description."
Metadata summarizes basic information about data, which can make finding and
working with particular instances of data easier.

( _http://whatis.techtarget.com/definition/metadata_ )  or _http://www.data-_

_archive.ac.uk/media/54776/ukda062-dps-preservationpolicy.pdf_

##  Repository

A digital repository is a mechanism for managing and storing digital content.
Repositories can be subject or institutional in their focus. (
_http://www.rsp.ac.uk/start/before-youstart/_ _what-is-arepository/)_

#  8 Bibliography

  * Guidelines on Data Management in Horizon 2020, Version 2.0, 30 October 2015: 

  

_http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-
oapilotguide_en.pdf_

  * Guidelines on OA to Scientific Publications and Research Data in Horizon 2020, Version 

  

2.0, 30 October 2015:

_http://ec.europa.eu/research/participants/data/ref/h2020/grants_manual/hi/oa_pilot/h2020-hi-
oapilotguide_en.pdf_

  * Webpage of European Commission regarding OA: 

  

_http://ec.europa.eu/research/science-society/open_access_