#  Executive Summary

**The PreCoM project**

Cheaper and more powerful sensors, predictive cognitive CBM system, together
with big data analytics, offer an unprecedented opportunity to track machine-
tool performance and health condition. However, manufacturers only spend 15%
of their total maintenance costs on predictive (vs reactive or preventative)
maintenance.

The PreCoM project will deploy and test a predictive cognitive maintenance
decision-support system able to identify and localize damage, assess damage
severity, predict damage evolution, assess remaining asset life, reduce the
probability of false alarms, provide more accurate failure detection, issue
notices to conduct preventive maintenance actions and ultimately increase in-
service efficiency of machines by at least 10%.

The platform includes 4 modules: 1) a data acquisition module leveraging
external sensors as well as sensors directly embedded in the machine tool
components, 2) an artificial intelligence module combining physical models,
statistical models and machine-learning algorithms able to track individual
health condition and supporting a large range of assets and dynamic operating
conditions, 3) a secure integration module connecting the platform to
production planning and maintenance systems via a private cloud and providing
additional safety, self-healing and self-learning capabilities and 4) a human
interface module including production dashboards and augmented reality
interfaces for facilitating maintenance tasks.

The consortium includes 3 end-user factories, 3 machine-tool suppliers, 1
leading component supplier, 4 innovative SMEs, 3 research organizations and 3
academic institutions. Together, we will validate the platform in a broad
spectrum of real-life industrial scenarios (low volume, high volume and
continuous manufacturing). We will also demonstrate the direct impact of the
platform on maintainability, availability, work safety and costs in order to
document the results in detailed business cases for widespread industry
dissemination and exploitation.

**Goal and structure of deliverable**

The present document _D9.5: Open Data Management Plan_ is a public deliverable
of the PreCoM project, developed within _WP9: Dissemination, Communication &
Ecosystem Development _ at month 6 (April 2018).

This deliverable is based on the Template for the Open Research Data
Management Plan (DMP)  1  recommended by the European Commission. The
following sections describe how PreCoM plans to make the project data
Findable, Accessible, Interoperable and Reusable (FAIR). This DMP constitutes
a preliminary version produced at month 6 which will be updated progressively
during the project course, when the specific types of data and open data will
be defined in detail, selected and planned for eventual publications. Partners
will check throughout the project whether the publication of some or all types
of data could be incompatible with the obligation and will to protect emerging
results that can reasonably be expected to be commercially or industrially
exploited.

**PreCoM Open Research Data Management Plan (DMP)**

#  SUMMARY

_(dataset_ 2  _reference and name; origin and expected size of the data
generated/collected; data types and formats)_  
  
<table>  
<tr>  
<th>

**Purpose of the data collection/generation**

  * Analysing the condition monitoring, maintenance, production, quality and production cost information coming from the three use-cases 

  

  * Sharing information between partners 

  

  * External dissemination and communication (through e.g. publications and reports) 

  

**Relation to the objectives of the project**

  * The prediction models will be based on historical data as well as data sets recorded during the project 

  

  * To support the maintenance technicians and manager with information 

  

  * To continuously improve the accuracy of the models/modules included by the system 

  

**Types and formats of data generated/collected**

  * Office files (.docx, .pptx, .xlsx) 

  

  * Pdf-files 

  

  * 3D-Model-file (.vrml, .fbx) 

  

  * Image- and video-files (.png, .jpg, .mp4) 

  

  * Matlab files (.mat) 

  

  * csv-files 

  

  * Text files (.txt) 

  

  * Sensor (raw) data in time and frequency domain 

  

  * NC data 

  

  * Python script file (.py) 

  

  * R software files: R script file (.r), R objects file (.rds, .rda, .RData) 

  

  * Open document: text documents (.odt), spreadsheet documents (.ods), database documents (.odb), graphics documents (.odg) and formula documents (.odf). 

  

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

  * Compressed Files (.zip, .rar, .tar.gz) 

  

  * Database Files: SQL file (.sql), JSON file (.json) 

  

  * TeX files: LaTeX file (.tex), R Markdown file (.rmd) and R Knitr file (.rnw) 

  

  * XML viewer (.xml) 

  

**Re-use of existing data:**

**Yes, it will be done, in particular:**

  * Historical data from the Condition Monitoring Systems as well as other production software (also including excel-sheets) is re-used 

  

  * (Maintenance) documentation of the production machines 

  

  * Economic data concerning, for example production losses per time unit, maintenance and production costs. 

  

  * Quality data, for example defectives, quality rate and causes behind that. 

  

  * Existing images, manuals and video files to guide workers through maintenance processes 

  

  * Exiting 3D-Model files for worker guidance and machine status overview 

  

**Origin of the data**

  * Condition Monitoring Systems of the production machines including sensor platform, NC 

  

Data, and external controllers

  * Production Software (MES, PPS, etc.) 

  

  * Economic and quality systems 

  

  * Documentations/Manuals of Production Machines 

  

**Expected size of the data**

  * For each machine (on average): 

  

− 600MB per month (information from CNC)

− 4MB per file diagnosis cycle (high sampling rate files).

  * Internal Repository for sharing information between partners, publication and reports: < 1TB 

  

  * For each publicly-available file (e.g., publications, open dataset): <10Mb 

  

**Data Utility: to whom will it be useful?**

  * all the partners involved in the project and the scientific community 

  

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

#  MAKING DATA FINDABLE

_(dataset description: metadata, persistent and unique identifiers e.g., DOI)_  
  
<table>  
<tr>  
<th>

**Discoverability of data (metadata provision)**

  * The data from the Condition Monitoring Systems are stored in a cloud database (so-called SAVVY Cloud) for internal use, which includes metadata; all office documents include metadata as well. 

  

  * DOI when published (scientific articles) 

  

**Identifiability of data and standard identification mechanisms. Do you make
use of persistent and unique identifiers such as Digital Object Identifiers?**

  * Yes, in publications and data appearing in journals, magazines and other collections 

  

(assigned by publisher)

**Naming conventions used**

  * Date, purpose of the document, editors and version number 

  

**Approach towards search keyword**

  * A limited and appropriate set of keywords will be selected for each publication/dataset, as well as each deliverable. Publications should integrate the terms "European Union 

  

(EU)", "Horizon 2020", "PreCoM" and the Grant agreement number

  * No keywords in internal documents or condition monitoring data 

  

**Approach for clear versioning**

  * Office documents are named with the version number and the name of the editors 

  

  * Deliverables include a table, which lists the different versions together with the editors 

  

  * Condition Monitoring Data, such as vibration measurements, does not need a versioning as there only exists one version and the data is distinguished by data measuring date and time) 

  

**Standards for metadata creation (if any). If there are no standards in your
discipline describe what metadata will be created and how.**

  * Descriptive and structural Metadata 

  

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

#  MAKING DATA OPENLY ACCESSIBLE

_(which data will be made openly available and if some datasets remain closed,
the reasons for not giving access; where the data and associated metadata,
documentation and code are deposited (repository?); how the data can be
accessed (are relevant software tools/methods provided?)_  
  
<table>  
<tr>  
<th>

**Specify which data will be made openly available? If some data is kept
closed provide rationale for doing so**

  * The publicly-available data will be published in public deliverables within the PreCoM project and scientific journals. 

  

  * The selection of open data will be done progressively during the project as far as the consortium defines and agrees in this respect. 

  

  * The potential exploitation of production and documentation data (data from the condition monitoring systems), as well as of other types of data, may lead to keep closed some data, as they might contain intellectual property (e.g. NC Code, CADModels) from partners or third parties. 

  

**Specify how the data will be made available**

  * PreCoM website 

  

  * Open Access journal publications 

  

  * Data repository (Zenodo) 

  

**Specify what methods or software tools are needed to access the data? Is
documentation about the software needed to access the data included? Is it
possible to include the relevant software (e.g. in open source code)?**

  * Depending on the data disclosed, they might need specific software to be opened, like the following ones: o Matlab o Microsoft Office 

    * Statistical Software R (Open Source) o Statistical Software SPSS 

  

    * SAVVY Cloud REST API (described in D2.3) 

  

    * Savvy interoperability modules (data accessible in the shopfloor) o Documentation of the Software is provided through the Software provider o Python software (Open Source) 

  

  

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

**Specify where the data and associated metadata, documentation and code are
deposited**

  * Internal project repository (LRZ Sync&Share hosted by TUM) for Office documents 

  

  * SAVVY Cloud for Condition Monitoring data 

  

  * Data repository (Zenodo) for public deliverables and open access publications and data 

  

**Specify how access will be provided in case there are any restrictions**

  * A formal request should be sent via e-mail to the project coordinator (Basim Al- 

  

Najjar, _basim.al-najjar@lnu.se_ ; Francesco Barbabella,
_francesco.barbabella@lnu.se_ ), which will evaluate the request together with
the relevant other partners and will eventually grant (partial or total)
access to restricted data.

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

#  MAKING DATA INTEROPERABLE

_(which standard or field-specific data and metadata vocabularies and methods
will be used)_  
  
<table>  
<tr>  
<th>

**Assess the interoperability of your data. Specify what data and metadata
vocabularies, standards or methodologies you will follow to facilitate
interoperability.**

  * Use of common and standard file formats (.txt, .mat, .docx, .pptx, .csv, .xlsx) 

  

  * Further specific formats and eventual conversions have to be defined 

  

**Specify whether you will be using standard vocabulary for all data types
present in your data set, to allow inter-disciplinary interoperability? If
not, will you provide mapping to more commonly used ontologies?**

  * Explicit and interoperable vocabulary can be used and eventually definitions can be provided to clearly define terms 

  

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

#  INCREASE DATA RE-USE

_(what data will remain re-usable and for how long, is embargo foreseen; how
the data is licensed; data quality assurance procedures)_  
  
<table>  
<tr>  
<th>

**Specify how the data will be licensed to permit the widest reuse possible**

  * Open publications and data will be licensed under CC Attribution-NonCommercial 4.0 International license or similar ones (to be agreed on a case-by-case by the consortium). 

  

  * Further restrictions might be possible depending on the type of data and eventual emerging IPRs. 

  

**Specify when the data will be made available for re-use. If applicable,
specify why and for what period a data embargo is needed**

  * Anonymized Condition Monitoring data used for validation in publications and public deliverables might be made available for re-use directly after the publication, if no issue emerges from IPR protection or other industrial needs 

  

  * In addition, specific sets of condition monitoring data can be anonymized and made available for re-use on request 

  

  * Methodologies and codes generated during the project might be disclosed only after eventual patents or other IPR protection measures will be fully granted in relevant countries 

  

**Specify whether the data produced and/or used in the project is useable by
third parties, in particular after the end of the project? If the re-use of
some data is restricted, explain why**

  * Re-use of the processed data published in journals are restricted according to abovementioned conditions for granting open access data. 

  

  * In addition, specific sets of condition monitoring data can be anonymized and made available for re-use on request 

  

**Describe data quality assurance processes**

  * Data quality assurance processes will be defined in detail when the types of data produced during the project will be clarified. 

  

**Specify the length of time for which the data will remain re-usable**

  * For at least 3 years after the end of the project, open data could be re-used. 

  

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

#  ALLOCATION OF RESOURCES and DATA SECURITY

_(estimated costs for making the project data open access and potential value
of long-term data preservation; procedures for data backup and recovery;
transfer of sensitive data and secure storage in repositories for long term
preservation and curation)_  
  
<table>  
<tr>  
<th>

**Estimate the costs for making your data FAIR. Describe how you intend to
cover these costs**

  * Open access publication costs (including open access data) in journals may vary from 1,000 to 3,000 € 

  

  * A publication budget of 33,000 Euros has been split between Linnaeus University (Coordinator), eMaintenance, Paragon, ITMATI, Technical University Munich, Technical University Chemnitz for open (gold) access publication costs. 

  

  * The data repository (Zenodo) is free. 

  

**Clearly identify responsibilities for data management in your project**

  * Open Data Manager: to be appointed (TUM, WP9 Leader). He/she will coordinates the open data management activities, makes proposals to the Executive Board on the definition of data produced during the project and the selection of open data and their publication. 

  

  * Executive Board: 1 representative per WP leader, including: Linnaeus University (Coordinator and Chair), CEA, ITMATI, Technical University Munich, Technical University Chemnitz, eMaintenance, Ideko, Vertech Group. The Executive Board evaluates the proposals by the Open Data Manager and discuss eventual issues and implications on publications and data access, making binding decisions when relevant. Further project partners and/or third parties might be involved in the discussion when data are produced or relates to other organizations. 

  

  * Responsible of internal data repository (LRZ Sync&Share): Simon Zhai (TUM). He maintains the project intranet accessible and updated at a secure address. 

  

  * Responsible of SAVVY Cloud for Condition Monitoring Data (information from machines): to be appointed (SAVVY). He/she will manage the cloud infrastructure enabling the collection and analysis of data from demonstration companies. 

  

  * Responsible of Data Repository (Zenodo): to be appointed (TUM). He/she will manage the publication of open access publications and data in online repositories. 

  

**Describe costs and potential value of long term preservation**

  * Data storage is managed at company scale. Therefore, storage for R&D projects is not really limited and represents negligible costs. 

  

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

**Address data recovery as well as secure storage and transfer of sensitive
data**

  * Internal Repository (LRZ Sync&Share): For each file, the last five Versions are stored and can be restored 

  

  * SAVVY Cloud: 

  

− Incremental backup is performed for machine information.

− Daily backup for management information (metadata).

  * sensitive data is transferred through the password secured internal repository (LRZ Sync&Share), SAVVY Cloud provides password secured access to project partners (and TLS communication), who need to work with the Condition Monitoring Data 

  

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