The MC-SUITE project proposes a new generation of ICT enabled process
simulation and optimization tools enhanced by physical measurements and
monitoring that can increase the competence of the European manufacturing
industry, reducing the gap between virtual modelling and real physical
processes. In order to achieve the expected results by the MC-SUITE approach,
the consortium assembled for this 36-month project consists of a unique
combination of skills and expertise including 6 SMEs, 2 universities, 2
research centres and 2 large companies. Hence, this consortium covers all the
value chain of the manufacturing products including software providers,
equipment providers, machine tool builders and end users.

The advances in the Information and Communication Technology (ICT) are
revolutionizing our everyday life. However, the manufacturing industry has not
taken complete advantage of this huge potential yet. The final aim of the MC-
SUITE project is to open the doors of the manufacturing workshops to this new
revolution. Indeed, the MC-SUITE project consortium strongly thinks that the
current ICT can have a tremendous impact in the productivity increasing the
competence and expertise of the European manufacturing companies and
especially the SMEs.

The aim of the project is to develop the MC-SUITE application based on six
different modules ready to reduce the gap between the simulated and the real
process (see Figure 2).

**1.2**

**PROJECT CONTEXT AND**

**DATA ORIGIN**

_Figure 2: MC-SUITE modules_

**_Objective 1:_ ** To develop a virtual model of the machining process.

  * **MC-Virtual** obtains the final path of the tool and the quality of the real part, the cutting force 

  

and process stability, overcoming the limits of the actual Computer Aided
Manufacturing software.

**_Objective 2:_ ** To apply multi objective optimization methods in
manufacturing processes.

  * **MC-Optim** optimizes the milling process considering multiple objectives including 

  

productivity, quality and energy consumption.

**_Objective 3:_ ** To create a complete Cyber Physical System for machine
productivity improvement.

  * **MC-CyPhy** includes three different embedded systems connected to the virtual model and to 

  

the monitoring system to increase the productivity.

**_Objective 4:_ ** To build up a monitoring system based on the cloud.

  * **MC-Monitor** is a cloud-based system able to store heterogeneous data including signal coming 

  

from internal sensors of the machine, from embedded systems and operator
authored data.

**_Objective 5:_ ** To create new services based on Big Data.

  * **MC-Analytics** is a platform to treat the information of the cloud for predictive maintenance 

  

and productivity improvement.

**_Objective 6:_ ** To combine simulated and experimental data in a complete
software suite.

  * **MC-Bridge** compares the results of the virtual model with the real ones obtained from the monitoring system. This way on-line and off-line optimizations are performed both on the simulations and on the machining process. 

  

The project will be generating two types of research data. The first type will
be large sets of numerical arrays from the machine’s sensors which will be
used for the development of the working models behind the MC-SUITE modules.
The second type will be data generated from the predictive and optimization
models in the project. Simulation and programming codes compiled in the
project will be regarded as a research data too.

One of the challenges in preserving data for long term is the choice of file
format. In the MCSuite project whenever possible data will be saved in open
formats or widely popular formats which do not depend on proprietary software.
For text files this can be .txt, for tabular data \- .csv, for image- .tif,
for audio- .mp3 and for video- .avi. Data will be generated continuously
throughout the whole duration of the project but the total amount of data is
expected to be less than 20 GB per partner.

A more detailed description of the data and the equipment which will be used
for its collection/ generation is provided in the following subsections. This
is based on the early stage plans of the project and it will be updated
together with the later versions of the Data Management Plan.

**2.1**

**M**

**ILLING**

**MACHINES**

The main milling machines that will be used in the project are the SORALUCE SV
6000, the LAGUN GVC-1000-HS and the FIDIA DL165 machining centres (see Figure
3). All machines will be equipped with a variety of sensors which will help
analysing the metal cutting processes, build process models and test the
virtual sensors developed in the MC-Suite project. Initially, investigations
will be focused on orthogonal and oblique milling of stainless steel and
aluminium.  
  
<table>  
<tr>  
<th>

</th>  
<th>

**2\. DATA DESCRIPTION**

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

LAGUN GVC-1000-HS machine

SORALUCE

SV 6000 machine

FIDIA DL165

machine

_Figure 3: Machining centres used in the MC-SUITE project._

All sensor data will be presented together with some of the tool and process
characteristics. This will include cutting angles of the tool, cutting edge
radius, substrate material and tool coating (if known). Characteristics as
cutting depth, cutting speed and feed will be also added to the documentation.

**2.2**

**C**

**UTTING FORCES**

Cutting force is one of the most significant parameters in process modelling.
A range of sensors are available in the consortium. The Kistler 9255B multi-
component dynamometer plate, the Kistler 9121 3-component orthogonal
dynamometer and the Kistler rotational 9123 C dynamometer will be used as a
force measurement reference for different cutting tests (see Figure 4).

9255

B

9121

9123

C

_Figure 4: Kistler odynometers used in the project._

Dynamometers are widely used in laboratories but because of their very high
cost they are rarely applied in real production environment. A more cost
effective alternative for an indirect measurement of the forces will be
investigated in the project. It has been demonstrated that a virtual sensor
can be based on the current measured on the drive and the spindle of the
machine. Current sensors on the electric loops of the spindle and driver
motors of the SV 6000 machine have already been installed by the machine
supplier. However, external sensors might be added to verify the reliability
of the internal CNC data and to obtain higher sampling frequencies.

The cutting forces collected directly from the sensors will be saved in ASCII
files which will be structured in 4 columns. Three of the columns will be
dedicated to the force components and the fourth will be representing the
time. The processed cutting forces will be saved in separate ASCII files
together with the cutting test conditions, cutting force average and the
standard deviation of each force component.

**2.3**

**V**

**ELOCITIES AND**

**POSITIONS**

The tests will be carried on the SV 6000 SORALUCE milling machine.
Accelerometers are not integrated in the machine and will be placed on the
horizontal axes of the ram tip. The returned information is an image of the
acceleration that, once processed, provides the velocity and displacement of
the ram tip.

Encoders are electromechanical devices that generate electrical signal
proportional to the position of the measured element. They enable the
collection of accurate information in real time about the motor position and
velocity value to close the control loops.

The following encoder’s data will be used :

  * Three linear encoders, Figure 5, giving information about the position following the XYZ axes of the SV milling machine. 

  

  * A rotary encoder giving information about the spindle velocity. _Figure 5: Linear encoder._

  

To enable a high frequency acquisition and avoid limitation from the CNC, the
encoder signals will be duplicated and processed directly in a real time
acquisition system with a frequency of up to 10 kHz. Results will be directly
exported to Matlab.

**2.4**

**M**

**ACHINE AND TOOL DYNA**

**MICS**

Frequency Response Function (FRF) of the tool tip will also be provided. FRF
is very valuable in vibration analysis to study the behaviour of the machine
and tools. The FRF will be saved in “.uff” format file.

#  2.5 VIDEO AND SOUND ACQUISITION

Video and sound of the machining processes will be recorded. Standard IP
cameras will be used to provide a general view of the machining process and
document the tests. Moreover, sound analysis can reveal information about the
occurrence of vibrations and chatter frequencies. A High Speed Filming device
FASTCAM Ultima APX-RS 250K (Figure 6) will be used to obtain videos and images
from the chip generation. Files will be saved in several formats- AVI, JPEG,
PNG (10bit) or TIFF. _Figure 6: Ultima APX-RS 250K._

**2.6**

**S**

**URFACE MEASUREM**

**E**

**NTS**

When required, surface finish quality will be measured with a non-contact
laser measurement in order to obtain information about the workpiece
roughness. Alternatively, white light interferometry (WLI) or contact probe
profilemetres can be used too. Some complimentary information will be received
from optical microscopy images.

**2.7**

**S**

**IMULATION DATA**

Many of the machining simulations in the project will be performed using the
MACHPpro simulation software. The software has a milling module which enables
prediction of process parameters such as cutting force, tool side load,
workpiece cutting force, spindle torque, spindle power and energy consumption,
bending moment, form error and chip load.

_Figure 7: MACHpro interface._

Results obtained with MACHpro will be used to provide estimation of cutting
forces and cutting process energy consumption. Outputs will be presented in
ASCII files.

#  2.8 OPTIMISATION DATA

The MC-OPTIM module will be receiving input data from a variety of simulations
performed in the MC-VIRTUAL module. Multiobjective process optimisation will
be applied to the simulation results to provide the machine operator with
optimal working conditions. Table 1 summarizes the MC-OPTIM output parameters.

_Table 1: MC-OPTIM output data details (preliminary version)._  
  
<table>  
<tr>  
<th>

**Output data**

</th>  
<th>

**Format**

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

Spindle speed: N value for the best individual

(between a given range: Nmax-Nmin)

</td>  
<td>

Boolean cast to Integer (16 bit) or double (32 bit)

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

Feed Override: F for the best individual

(between a given range: Fmax-Fmin)

</td>  
<td>

Integer (16 bit)

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

Value for the Fitness function for the best individual

</td>  
<td>

double (32 bit)

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

Value for the individual objective functions that conform the Fitness function

</td>  
<td>

double (32 bit)

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

Pareto frontier or the output parameters for the best last 10 solutions

</td>  
<td>

double (32 bit)

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

Time spent to get the solution

</td>  
<td>

double (32 bit)

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

Data for a graphical display in 3D of the solution explored if the Fitness
function is in 2 or 3 dimensions

</td>  
<td>

double (32 bit)

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

**3.**

**DATA STORAGE AND MAI**

**NTENANCE**

**3.1**

**D**

**ATA STORAGE AND BACK**

**UPS**

At least two copies of all data generated in the project will be kept at all
times. To avoid loss of information in the event of fire or any other accident
all copies of the data will be kept at different locations. These can be the
personal computers of work colleagues based in separate offices or if
available institutional back- up servers. When this is not possible, the data
will be backed on external hard drives or DVDs which will be kept at a
different location and can be accessed by at least two different persons. USB
pen drives are not considered as a reliable backup storage media because of
their short life (1 year in average). Commercial cloud storage services may be
used but they will not be considered as a primary back up media.

Backups will be performed by each partner on the first working day of every
month or whenever new significant results are achieved. The functionality of
all data is to be checked at least once a year for any corrupted files or
format updates.

Data from sensor readings and surface measurements will be preserved in its
original raw format and shape. Any further analysis is to be performed on a
copy of the original files.

#  3.2 FILE ORGANIZATION AND NAMING

The following folder structure will be used:

##  <institution>/<researcher name or initials>/<data identifier>/<date>

If necessary the _date_ folder can be broken down into to further subfolders.
When a short phrase cannot be a clear data identifier a reference number will
be used instead. However, in this case a separate _readme_ text document with
a short description of each data set and its reference number will be created
in the _researcher’s name_ folder.

The YYYY-MM-DD date convention will be used for dates in folder and file
names. This is the ISO 8601 standard and when in the beginning of the
folder/file name, items are automatically sorted chronologically. For example
the 1  st  of March 2016 will be written as 2016-03-01. The following naming
system will be used for files:

##  YYYY-MM-DD_project name_institution_researcher intitials_measurement
/simulation _number

For example, if there was a document containing tabular data representing
vibration measurements taken by the author of this DMP on the 1  st  of March
2016, the file name of the first set for the day would be:

##  2016-03-01_UoN_NV_vibr_01.csv

**3.3**

**A**

**DDITIONAL NOTES**

For every data set a separate text document with explanatory notes will be
created and saved in the _date_ folder together with all other files. The
notes will contain full details of how and under what conditions the
information was collected or generated and explanation of the file naming
system.

In the case of experimental data the document will contain information about
the exact experimental set up, name of operators, references to specific
samples, any abbreviations or physical units used in the data set and any
other information which might be required to reproduce the results. When
relevant, notes from personal and lab logs can be added too. In the case of
data generated from simulation models the exact input parameters and
references to the simulation code will be included in the explanatory
document.

**4.**

**DATA ARCHIVING**

**AND SHAR**

**ING**

**4.1**

**D**

**ATA REPOSITORY**

All data collected, generated or processed in the project which has a
significant scientific value or is linked to a published work will be uploaded
to a public data repository. The primary repository for the MC-SUITE project
will be FigShare  ( _https://figshare.com/_ )  which is a very well
established provider for scientific data and is free to use. FigShare is one
of the repositories recommended by the Nature journal and it has been chosen
as an institutional repository for a large number of highly regarded
universities and publishers. They have a very easy to navigate user interface
and unlike many of their competitors they do not impose restrictions on the
file format of the documents deposited. Maximum size of a given dataset is 20
GB and the recommended limit for a single file is 5 GB. According to the
service agreement, files on FigShare are retained for the lifetime of the
repository or at least 10 years after publishing.

MC-SUITE data will be stored under one of the Creative Commons licenses. For
figures, media, posters, papers and file sets CC-BY license will be used. CC-
BY ensures the research will be openly available but it requires that a credit
in the form of citation is given when used or referred to. In the case of
complete databases or structured datasets with highly factual data CC0 license
will be used.

CC0 similarly to CC-BY is an open license but does not legally require users
of the data to cite the source. However, the moral obligation of attribution
remains same as in the case of any research journal paper citation. In the
special case of programming or computer simulation code sharing the MIT
license will be used. MIT provides full open access to the code but also
removes any liability of the authors in the event of any legal claim or damage
caused by the use of the code.

All data with potential commercial value will be embargoed for 12 months after
the termination of the project to allow for patent filing.

MC-SUITE will not be publishing any sensitive data so there is no need of
taking any special anonymization procedures.

Data published on FigShare is automatically assigned with DataCite DOI.
Additionally, there is an option of exporting a reference file to some of the
most common reference managers like RefWorks, BibTeX, Endnote, DataCite, NLM,
DC and RefMan.

**4.2**

**D**

**ATA OWNERSHIP**

Every project partner generating, collecting or processing data in the project
will create their own FigShare account. An MC-SUITE project space which will
link the individual accounts will be created too. Publishing of relevant data
when available is the responsibility of the partner who created the data. It
is important that accounts are managed and regarded as institutional rather
than personal so that any enquiries related to the published data can be
answered even after the end of the project. This means that at least two
persons will have an access to every FigShare account at any time during and
after the project and both of them will have equal administration rights.

Partners will be reviewing their new data and publish it when significant at
least every 6 months starting at M6 of the project.

**4.3**

**M**

**ETADATA FORMAT**

Unless there is an established metadata schema for the type of data published
in the project the Dublin Core simple level schema will be used. This is a
well-established general scheme which can effectively cover a large variety of
data. The elements of the schema are as follow: title, creator (authors),
subject (e.g. Engineering), description, publisher, contributor, date, type
(e.g. sound), format, identifier (DOI), source, language, relation, coverage
(e.g. location), rights, funding. All these elements are covered on opening a
FigShare account so authors do not need to take any special actions when
publishing.  
  
<table>  
<tr>  
<th>

</th>  
<th>

**5\. CLOSING REMARKS**

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

The DMP is a continuously evolving document which will be updated at the mid-
term review and the end of the project. Updates will be reflected in the Open
Research Data deliverable document due in September 2017.

All activities regarding data publishing will be coordinated and supported by
the University of Nottingham (UoN) which is also responsible to ensure that
the current DMP is followed by all partners. UoN will organise a workshop to
familiarise all interested parties with FigShare.