Cloud-based Rapid Elastic MAnufacturing...involves two industry partners, namely FAGOR and GOIZ. In...

Cloud-based Rapid Elastic MAnufacturing

WP7 – Piloting & Validation: Use Case I: Machinery Maintenance

D7.2: Use Case I Machinery Maintenance Definition

Deliverable Lead: FAGOR

Contributing Partners: ALL except TCO

Delivery Date: 12/2015

Dissemination Level: Public

Version 1.0

This document provides a holistic view of the Machinery Maintenance use case regarding topics on CREMA possible implementation and evaluation scenarios. The Machinery Maintenance use case is defined as well as related user stories that will be used to validate the condition-based machinery maintenance scenario within the CREMA project. Furthermore, this document gives the projects stakeholders a detailed view of the use case and evaluation metrics.

CREMA WP7 Public Use Case I: Machinery Maintenance Definition

D7.2 – Use Case I Machinery Maintenance Definition v1.0

Document Version: 1.0

Date: 2015-12-31 Status: For Approval Page:

2 / 41 http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066

Document Status

Deliverable Lead David Chico, Fagor

Internal Reviewer 1 Gash Bhullar, TANet

Internal Reviewer 2 Mikel Mondragon, Mikel Anasagasti, GOIZ

Type Deliverable

Work Package WP7: Piloting & Validation: Use Case I: Machinery Maintenance

ID D7.2: Use Case I Machinery Maintenance Definition

Due Date 12/2015

Delivery Date 12/2015

Status For Approval

Note This deliverable is subject to final acceptance by the European Commission.

Disclaimer The views represented in this document only reflect the views of the authors and not the views of the European Union. The European Union is not liable for any use that may be made of the information contained in this document.

Furthermore, the information is provided “as is” and no guarantee or warranty is given that the information is fit for any particular purpose. The user of the information uses it at its sole risk and liability.






Project Partners

Ascora GmbH, Germany

Dot NET IT, United Kingdom

Technische Universität Wien, Austria

Technology Application Network Limited,

United Kingdom

German Research Center for Artificial

Intelligence, Germany

IKERLAN S. Coop., Spain

Ubisense, United Kingdom

Tenneco-Walker (U.K.) Limited, United Kingdom

FAGOR ARRASATE S. Coop., Spain

Goizper, Spain

ICE, United Kingdom






Executive Summary The purpose of this deliverable Use Case I Machinery Maintenance Definition (T7.1, D7.1) is to describe the Machinery Maintenance use case and evaluation scenario, which involves two industry partners, namely FAGOR and GOIZ. In the further course of the project, this document will be used as a guideline to implement and test the CREMA Platform including use case definition, six use stories (friction disk wear control, springs fatigue control, slipping control, pressure control, cooling control and braking angle control of a press machine), technical specification and configurations to adequate the Machinery Maintenance use case, as well as testbeds.

This document is organised as follows:

• Machinery Maintenance Use Case Definition: This section describes the generic storyline and user stories for the Machinery Maintenance scenario. Moreover, it describes the data schemas and process models that will be used as a baseline within the use case implementation phase.

• Machinery Maintenance Use Case Evaluation: This section specifies the evaluation scenario, testbeds and evaluation metrics that will be used in the scope of the Machinery Maintenance use case.

These sections will be used to guide the implementation (T7.2) and evaluation (T7.3) phases in the upcoming months.






Table of Contents 1 Introduction ..................................................................................................................... 7

1.1 CREMA Project Overview ...................................................................................... 71.2 Deliverable Purpose, Scope and Context .............................................................. 71.3 Document Status and Target Audience ................................................................. 81.4 Abbreviations and Glossary ................................................................................... 81.5 Document Structure ............................................................................................... 8

2 Machinery Maintenance Use Case Definition ................................................................. 92.1 Machinery Maintenance Use Case Overview ........................................................ 92.2 Towards Machinery Maintenance User Stories ................................................... 102.3 Detailed User Stories ........................................................................................... 11

2.3.1 Generic Storyline ...................................................................................... 112.3.2 User Story A: Friction Disc Wear Control of the Press's Clutch-brake ..... 122.3.3 User Story B: Springs Fatigue Control of the Press's Clutch-brake .......... 172.3.4 User Story C: Slipping Control of the Press's Clutch-brake ...................... 202.3.5 User Story D: Pressure Control of the Press's Clutch-brake .................... 222.3.6 User Story E: Cooling Control of the Press's Clutch-brake ....................... 232.3.7 User Story F: Braking Angle Control of the Press's Clutch-brake ............. 25

2.4 Data Sources and Models .................................................................................... 262.4.1 Data Sources ............................................................................................ 262.4.2 Press Machine Related Data .................................................................... 262.4.3 TAS Teams and Suppliers Related Data .................................................. 26

2.5 Process Definitions .............................................................................................. 302.5.1 Data Acquisition (monitoring) Process ...................................................... 302.5.2 Maintenance (KPI comparison) Process ................................................... 31

3 Machinery Maintenance Use Case Evaluation ............................................................. 343.1.1 Condition-based Monitoring Scenarios for User Story A-F ....................... 35

3.1.1.1 Scenario A: Clutch-brake’s friction disc wear simulation ........... 353.1.1.2 Scenario B: Clutch-brake’s spring fatigue simulation ................ 363.1.1.3 Scenario C: Clutch-brake’s slipping simulation .......................... 363.1.1.4 Scenario D: Pressure loss at the clutch-brake ........................... 363.1.1.5 Scenario E: Clutch-brake overheating ....................................... 373.1.1.6 Scenario F: Overshooting on the press machine braking angle 37

3.1.2 Maintenance Process Execution Scenario Depending on Press Machine Conditions (User Story F) .................................................................................... 37

3.2 Evaluation Equipment and Testbeds ................................................................... 383.3 Evaluation Metrics ................................................................................................ 39

4 Conclusion .................................................................................................................... 41






List of Figures, Tables and Listings

Figures Figure 1: FAGOR/GOIZ Machinery Maintenance Use Case Outline ................................. 12Figure 2: Friction Disk Wear Example ................................................................................ 13Figure 3: Mechanical Clutching Time Example .................................................................. 16Figure 5: Cooling Control Example .................................................................................... 23Figure 7: Data Acquisition Process .................................................................................... 32Figure 8: Maintenance Process .......................................................................................... 32Figure 9: Machine-level and Component-level Data Acquisition ........................................ 34Figure 10: (a) FAGOR Press Machine and (b) GOIZ Clutch-brake Sensors Installation in the Press Machine .............................................................................................................. 39

Tables Table 1: Clutch-brake Signals for Friction Disc Wear Control ............................................ 13Table 2: GOIZ Algorithm Results for Friction Disc Wear Control ....................................... 15Table 3: Clutch-brake Signals for Spring Fatigue Control .................................................. 18Table 4: GOIZ Algorithm Results for Spring Fatigue Control ............................................. 19Table 5: Clutch-brake Signals for Slipping Control ............................................................. 20Table 6: GOIZ Algorithm Results for Slipping Control ........................................................ 21Table 7: Clutch-brake Signals for Pressure Control ........................................................... 22Table 8: GOIZ Algorithm Results for Pressure Control ...................................................... 22Table 9: Clutch-brake Signals for Cooling Control ............................................................. 24Table 10: Press Machine Variables .................................................................................... 27

Listings Listing 1: JSON Example – Listing showing press machine related variables ................... 28Listing 2: JSON Example – Listing showing TAS related data ........................................... 28Listing 3: JSON Example – Listing showing maintenance contract related data ............... 29Listing 4: JSON Example – Listing showing spare-part suppliers related metadata .......... 30






1 Introduction CREMA – Cloud-based Rapid Elastic MAnufacturing – is a project funded by the Horizon 2020 Programme of the European Commission under Grant Agreement No. 637066. Within this deliverable, with help of Use Case I Machinery Maintenance Definition (T7.1, D7.1), Requirements Analysis and User Stories (T2.4, D2.9) and Global Architecture Definition (T3.1, D3.1), the details and evaluation metrics of the Machinery Maintenance use case are specified. For this purpose, use case overview, definition, and evaluation are defined to facilitate the common understanding of the Machinery Maintenance use case and target CREMA application for industry partners FAGOR ARRASATE (FAGOR for short) and GOIZPER (GOIZ for short).

1.1 CREMA Project Overview

CREMA aims at simplifying the establishment, management, adaptation, and monitoring of dynamic, cross-organisational manufacturing processes following Cloud manufacturing principles. CREMA will also provide the means to integrate data from distributed locations as if the complete manufacturing was carried out on the same shop floor, by integrating extra- and inter-plant manufacturing assets and making them “mobile”. CREMA will be built upon concepts and methods from the fields of Virtual Factories, Service-oriented Computing, Ubiquitous Computing, Cyber-Physical Systems, the Internet of Things and the Internet of Services, and naturally and most importantly Cloud computing. To achieve its goals, the project will define tools and approaches in these areas:

• Manufacturing Virtualisation & Interoperability • Cloud Manufacturing Process and Optimisation Framework • Cloud Manufacturing Collaboration, Knowledge and Stakeholder Interaction

Framework Thus, to achieve its goals, CREMA conducts original research and applies technologies from the fields of full end-to-end integration of Cloud manufacturing, integration of manufacturing assets and corresponding data sources, the design and execution of manufacturing processes, to the end user support via collaboration and interaction tools. For more information, please refer to the project Website1.

1.2 Deliverable Purpose, Scope and Context

The purpose of this deliverable is to provide a detailed guidance on use case implementation (T7.2) and help with evaluation phase (T7.3), so we can have a clear picture of the full scope of the machinery condition-based maintenance scenario and position for evaluation period. To achieve this goal, this Use Case I Machinery Maintenance Definition (T7.1, D7.1) document provides information about the use case definition and evaluation. The former includes detailed user stories, data sources and process models that will be used within this scenario. The latter specifies evaluation scenario, equipment, testbeds, and metrics. 1 http://www.crema-project.eu/






Overall, the Use Case I Machinery Maintenance Definition scope is to have more details surrounding the presented use case for applying CREMA.

1.3 Document Status and Target Audience

This document is listed in the Description of Action (DoA) as “public”, since it validates the real applicability of CREMA in industrial, real-life scenario and can therefore be used as a reference for future adoption in Cloud Manufacturing and Industrial Internet settings. While the document is primarily aimed at the project partners, this public deliverable can also be useful for the wider scientific and industrial community. This includes other publicly funded projects, which may be interested in collaboration activities.

1.4 Abbreviations and Glossary

A glossary of common terms and roles related to the realisation of CREMA as well as a list of abbreviations is provided as an online glossary2 / abbreviations list3.

1.5 Document Structure

This deliverable is broken down into the following sections:

• Section 1 (Introduction): Presents a general overview to the Machinery Maintenance use case, describing the industrial partners involved in the use case and their roles, and describing on the other hand the purpose of the deliverable as well as its scope and context.

• Section 2 (Use Case Definition): Describes the user stories for the Machinery Maintenance scenario. Moreover, data schemas and processes that will be used in the new Machinery Maintenance process based on Cloud Manufacturing services offered by CREMA will also be depicted.

• Section 3 (Use Case Evaluation): Describes the scenario, testbeds and metrics that will be used for the evaluation of the Machinery Maintenance use case.

2 http://crema-project.eu/glossary 3 http://crema-project.eu/abbreviations






2 Machinery Maintenance Use Case Definition The CREMA approach is exactly the kind of Cloud Manufacturing approach that FAGOR and GOIZ are planning for their next generation Cloud Manufacturing Platform. For instance, resource virtualization, data processing, and workflow-based elastic collaboration would allow FAGOR to implement the whole Machinery Maintenance Platform, following a predefined workflow and using highly integrated tools.

2.1 Machinery Maintenance Use Case Overview

The Machinery Maintenance use case involves two main industrial partners: FAGOR ARRASATE and GOIZPER:

• FAGOR ARRASATE4 is a company specialized in custom design, manufacturing and servicing forming machine tools, form presses and complete stamping systems for worldwide customers such as Gestamp, Volkswagen or Audi. These automated machines include sophisticated production technologies and high-level quality standards for all components.

• GOIZPER5 is a company specialized in engineering, designing, manufacturing and supplying power transmission components from metal forming machines such as clutch-brakes, cams and intermittent rotary units for different types of applications. As the leading clutch-brake manufacturer in Spain, it is the common partner for all FAGOR form presses.

Nowadays, the machinery monitoring and maintenance process is quite reactive and manual. After installing a press machine, FAGOR and GOIZ do not continuously collect machine/component data or monitor communications from multiple sources, customers and equipment types. In case of machine-level (i.e. press machine) or component-level (i.e. clutch-brake) error, the customer telephones the FAGOR TAS (Technical Assistance Service) member with instructions to commence answering. The TAS team maintains a spreadsheet to track customer issues requiring on-site intervention and minor remote checking (around 89% in 2014), or doubts clarification (11% in 2014) (see previous version of Use Case Machinery Maintenance Definition - T7.1, D7.1). At this point, it is possible to transfer the issue from the TAS team to the specialized developer team. If necessary, the responsible for resolving the issue can also make a team viewer remote connection to see online status or even can ask for a video record. Through remote connection, the developer or TAS member responsible for collecting and repairing the error cause can access machine-level and component-level logs, accessing the SCADA HMI (Human Machine Interface) and Programmable Logic Controller (PLC). In the current scenario, some errors can be fixed remotely, however, most of them require an onsite intervention. In case of clutch-brake errors, which can be indeed supported by GOIZ, FAGOR TAS operators collaborate with other GOIZ TAS operators to fix the error before the replacement moves on. If the installed clutch-brake cannot be fixed for any reason, GOIZ will manufacture a new clutch-break for the customer free of charge.

4 http://www.fagorarrasate.com 5 http://www.goizper.com





10 / 41

http://www.crema-project.eu Copyright © CREMA Project Consortium. All Rights Reserved. Grant Agreement No.: 637066

After assigning the TAS team commissioned to perform the intervention, both companies, i.e., FAGOR and GOIZ, review the maintenance plan to schedule the required clutch-brake delivery and TAS staff to perform the work at the right time. Once the clutch-brake is installed and tested, the maintenance action is marked as fixed in the event log (spreadsheet) and prevents this instance of the error from being listed again. By incorporating the Cloud Manufacturing services offered by CREMA within the machinery monitoring and maintenance process, FAGOR and GOIZ aims to minimize the production downtimes of a press machine and surrounding components by an efficient condition-based maintenance management based on a continuous real-time monitoring of its most critical components (e.g., GOIZ clutch-brakes) along with an efficient management of spare-part suppliers and Technical Assistance Service (TAS) teams. Concretely, the potential impact of CREMA is:

• Up to 60% reduction of unscheduled machine downtimes on customers due to a better tracking of critical machine components performance.

• 15% reduction of machine downtime on customers because of the increased visibility of machines behaviour in customers by means of a better management of expected future needs.

• Up to 50% reduction of intervention time on customers because GOIZ can manufacture in advance critical components sub-assemblies to simplify substitution operations on customers.

• 25% reduction of intervention costs by a better coordination between customers, spare parts suppliers (GOIZ) and TAS companies avoiding additional costs and time due to a non-presence of spare parts on the client or non-scheduled machine downtime to perform the intervention

2.2 Towards Machinery Maintenance User Stories

The Machinery Maintenance Use Case is focused on the reduction of breakdowns of FAGOR press machines by the implementation of an efficient and flexible condition-based monitoring service and maintenance process applying the solutions provided by the CREMA Platform. Using the CREMA Platform, FAGOR aims to create a network of interconnected companies along its supply chain, from customers where their machines are installed, to spare parts suppliers and certified TAS companies which perform different intervention tasks such as periodic maintenance, component replacements or breakdown repairs. This includes two main goals:

1. The first goal of the Machinery Maintenance Use Case in CREMA is to early detect malfunctions on the press machine or its components that may lead to a breakdown. For this purpose, a press machine will be monitored remotely and real-time data will be collected. Concretely, this data will be processed, stored in the CREMA Platform, and analysed according to a set of predefined indicators (KPIs) and process instances. As a result of this condition-based monitoring, the CREMA Platform will be able to trigger an alarm when an error occurs, i.e. when a KPI is exceeded or reached.





11 / 41


2. The second goal of the Machinery Maintenance Use Case is to search for suitable

spare part suppliers and TAS companies when the machine maintenance is needed. In the context of CREMA, spare part suppliers and TAS companies will be managed and offered by the CREMA Platform. Therefore, the maintenance process will have to select the TAS team that best suits to the needs derived of the triggered alarm, as well as the proper spare part supplier according to pre-established requirements (e.g. maintenance contract, location, prices).

FAGOR press machines are composed by a large number of components. One of the most critical one is the clutch-brake (from GOIZ). Due to this reason and besides the FAGOR press machine, GOIZ clutch-brake will be particularly monitored in CREMA. In this way, machine-level (e.g. press-machine data) and component-level (e.g. clutch-brake data) data will be collected and analysed. The use case is further explained in detail in the following sections.

2.3 Detailed User Stories

This section describes the user stories with regard to Maintenance Machinery use case. A generic storyline is described first in order to introduce detailed user stories for different clutch-brake control operations.

2.3.1 Generic Storyline

The generic storyline centers around the FAGOR press machine and GOIZ clutch-brake condition-based monitoring and maintenance process, including several steps:

1. While a FAGOR press machine is on, the CREMA Platform will collect a predefined set of press machine-level and clutch-brake component-level raw data, as well as customer/machine related metadata and location-aware data.

2. Clutch-brake related raw data collected by the CREMA Platform is processed by the GOIZ algorithm to get derived or computed information about the status of the clutch-brake.

3. Raw data coming from the press machines as well as the computed information, associated to clutch-brake data, is stored in the CREMA Platform.

4. The CREMA Platform will hold machine data. In addition to this machine-level and component-level data from the press machines, customer and location-related data will also be stored.

5. The stored data will be used by the CREMA Platform to detect unexpected operation conditions on monitored presses and alert users when KPI conditions are not met (see #1 in Figure 1: FAGOR/GOIZ Machinery Maintenance Use Case Outline).

• Regarding the clutch-brake component, the CREMA Platform will monitor five user stories, which are described in detail in the following sections, and are aimed at identifying symptoms that can help to detect in advance





12 / 41


a set of errors that can occur in a particular clutch brake, concretely: friction disc wear control, spring fatigue control, slipping control, pressure control, and cooling control.

(4)(4)

(5)

(3)

CREMACloudPlatform

FAGORARRASATEGOIZPER

CUSTOMER

Clutch-Brakewear

KPIsDashboard

TASCompanySelection

SupplierSelection

KPIMonitoring

KPIMonitoring KPIMonitoring

Clutch-BrakewearRealtimedatacollection

MessageMessage

TASTeam

Clucth-Brake

CUSTOMER

TASCOMPANY SparePartSUPPLIER

(1)(2) (2)

(3)

Clutch-BrakewearRealtimedatacollection

SelectedTASCOMPANY

Figure 1: FAGOR/GOIZ Machinery Maintenance Use Case Outline

• Regarding to the press machine, generic data from the PLC will be captured in order to know if the clutch-brake component is working fine or not. This knowledge will allow FAGOR to know which of the clutch-brakes are working according to a set of KPIs and will help on issue solving.

6. Once an alarm is triggered, users are able to decide if a maintenance process should be started. This process involves to main tasks: a spare-part supplier selection and a TAS team selection (see #2-4 in Figure 1: FAGOR/GOIZ Machinery Maintenance Use Case Outline). After maintenance process is finished, the press machine will start again working as expected (see #5).

Aside this generic storyline, six user stories (five related to the clutch-brake component itself and one for the press machine) have been identified as a way of capturing requirements and detail each specific case for FAGOR and GOIZ.

2.3.2 User Story A: Friction Disc Wear Control of the Press's Clutch-brake

When the friction disc of a clutch-brake wears, the time required to carry out braking and clutching operations in a press machine significantly increases. This is partially because the piston needs to perform a longer displacement. Thus, the time required since the piston starts to move until it reaches the clutching position or the braking position becomes longer. As depicted by Figure 2: Friction Disk Wear Example, when the friction discs (in orange) are worn out the distance (indicated as d in Figure 2: Friction Disk Wear Example) of the piston displacement increases (i.e. from d1 to d1+X).





13 / 41


d1+Xd1

Figure 2: Friction Disk Wear Example This is not a critical problem while the wear of the friction discs is within some values, but it becomes critical when this wear exceeds a particular threshold. In this case, a friction discs replacement is needed. Therefore, monitoring the time required for the clutching operation and braking operation can help to predict problems arising from excessive wear of the friction discs. As mentioned, the early detection of wear in a friction disc allows identifying the problem before it becomes critical. In consequence, a proper maintenance plan can be executed scheduling error-proofing activities on the press machine, minimizing machine downtimes as well as maintenance costs. One of the key points in this user story is the control process. Such control process should be considered during the transition periods of commutation; in other words, while clutching or braking operations are performed: during the first 500ms of the clutching operation and during the first 500ms of the braking operation. It has no sense to monitor the signals out of these two operations, as the information can be irrelevant. This control process has to monitor two different variables during the operation of a clutch-brake: clutching and braking transition operations. Both operations monitor the same clutch-brake signals in a different time period. The clutch-brake signals involved in this process are specified in Table 1: Clutch-brake Signals for Friction Disc Wear Control.





14 / 41


Table 1: Clutch-brake Signals for Friction Disc Wear Control

Variable Description Data type Data source type Frequency

Pressure_Safety_Valve signal (trigger, time = 0ms)

Position of the valve that commands the clutching and braking operations. The rising edge of this signal triggers the clutching operation.

The falling edge of the signal triggers braking operation.

Boolean Electrovalve signal / 0-10volts

1ms

Application_Pressure Pressure on the hydraulic circuit that actuates on the piston that moves the clutch-brake for clutching operation.

Float Pressure transducer/0-10volts

1ms

Flywheel_Speed Speed on the flywheel of the press machine.

Float Linear encoder 1ms

Crankshaft_Speed Speed of the crankshaft (in RPM).

Float Rotary encoder /tachogenerator

1ms

The control process should start (time = 0ms) with the rising or falling edge of Pressure_Safety_Valve signal. The CREMA Platform will start collecting data from the clutch brake. Four calculated variables are involved in this process. They will be calculated by processing the raw data coming from the clutch-brake during the clutching and braking operations. The data collection during the clutching operation starts with the rising edge of Pressure_Safety_Valve signal and ends 500ms later. In the same way, data collection during the braking operation starts with the falling edge of Pressure_Safety_Valve signal and finishes 500ms later. During these 500ms the parameters in Table 2: GOIZ Algorithm Results for Friction Disc Wear Control must be captured. Two types of alarms are triggered from the KPIs: a warning and an error: (i) Friction_Disc_Wear_Warning, and (ii) Excessive_Friction_Disc_Wear_Error. The Displacement_Time_Clutching and/or Displacement_Time_Braking values will involve the activation of a warning.





15 / 41


Table 2: GOIZ Algorithm Results for Friction Disc Wear Control

Value Description Data type Signal Init time End time

Displacement_Time_Clutching

Time required during clutching operation by the piston to reach the clutching position since it starts moving.

Float Application Pressure in time axis

(Application Pressure = 20) & (Pressure Safety Valve = 1 )

(Application Pressure = 35) & (Pressure Safety Valve = 1 )

Displacement_Time_Braking

Time required during braking operation by the piston to reach the braking position since it starts moving.

Float Application Pressure in time

(Application Pressure = 35) & (Pressure Safety Valve = 0)

(Application Pressure = 20) & (Pressure Safety Valve = 0)

Mechanical_Clutching_Time

Total time required for performing clutching operation. Clutching operation starts when crankshaft speed goes over 0rpm and ends when crankshaft speed is the same as flywheel speed. (electrical and hydraulic delays are not taken into account).

Float Crankshaft speed

Flywheel speed

(Crankshaft speed = 0,1) & (Pressure Safety Valve = 1)

(Flywheel speed = Crankshaft speed) & (Pressure Safety Valve = 1 )

Mechanical_Braking_Time

Total time required to perform braking operation. Braking operation starts when crankshaft speed goes below flywheel speed and ends when crankshaft stops. (electrical and hydraulic delays are not taken into account).


Flywheel speed

(Flywheel speed < Crankshaft speed) & (Pressure Safety Valve = 0)

(Crankshaft speed = 0) & (Pressure Safety Valve = 0)

Displacement time clutching During the clutching operation, the piston displacement starts when Application_Pressure reaches 20-bar value. The piston continues displacing until Application_Pressure reaches 35-bar value. The value of Displacement_Time_Clutching variable is calculated by the time interval between these two points along the time line. After calculating the value of Displacement_Time_Clutching, this variable must be then compared to a threshold value (CLUTCH_DISP_Nominal) in order to decide if the warning has to be triggered.





16 / 41


Figure 3: Mechanical Clutching Time Example

Displacement time braking During the braking operation, the piston displacement stars when Application_Pressure signal goes below 35-bar and continues until it reaches 20-bar. Displacement_Time_Braking will be the time interval between these two points. In the same way as for clutching operation, the value of Displacement_Time_Braking must be compared with a threshold value (BRAKE_DISP_Nominal) in order to trigger a warning if it exceeds. A second KPI must be checked when a warning is triggered. This KPI will keep into account not only the piston displacement time, but also the total mechanical time required for performing the clutching or braking operation. Mechanical clutching time On the one hand, the mechanical clutching time comprises since the crankshaft starts moving until it reaches flywheel speed. In Figure 3: Mechanical Clutching Time Example, this variable corresponds to 100ms, namely the acceleration ramp. Mechanical braking time The mechanical braking time comprises since the crankshaft goes below the flywheel speed until the crankshaft stops. This variable in the last figure is 60ms, the deceleration ramp. KPIs and alarms Friction_Disc_Wear_Warning must be triggered when one of the following conditions (KPI) is met:

• [Displacement_Time_Clutching] > CLUTCH_DISP_Nominal

• [Displacement_Time_Braking] > BRAKE_DISP_Nominal

Excessive_Friction_Disc_Wear_Error must be triggered when Friction_Disc_Wear_Warning has been triggered and the following two conditions are met:

• [Mechanical_Clutching_Time] > CLUTCH_MEC_Nominal

• [Mechanical_Braking_Time] > BRAKE_MEC_Nominal





17 / 41


Triggered maintenance process The maintenance activity that must be carried out in the press machine when friction disc wear is detected is to dismount the clutch brake and replace the friction discs. Therefore, when Friction_Disc_Wear_Warning or Excessive_Friction_Disc_Wear_Error is triggered, the CREMA Platform should select a suitable friction disc supplier as well as a TAS team that has mechanical skills, and plans the date to carry out the maintenance activity. The Excessive_Friction_Disc_Wear_Error will require a much faster reaction than the Friction_Disc_Wear_Warning.

2.3.3 User Story B: Springs Fatigue Control of the Press's Clutch-brake

For carrying out the clutching operation, the clutch-brake must counteract the force of the springs that maintains it disengaged. For this purpose, hydraulic pressure is applied to the piston. If the force of the clutch-brake spring becomes lower, the hydraulic pressure needed to overcome this resistance, also gets lower. In conclusion, the decrease of the pressure needed to overcome the springs force is a symptom of fatigue of the springs. When this symptom is detected, it means that despite the clutch-brake can continue working; it is convenient to replace the springs set of the clutch-brake. Hence, when the CREMA Platform detects excessive fatigue of the springs, it should start a maintenance process for the mentioned replacement. In the same way as for the process at the user story A, springs fatigue control only makes sense when clutch-brake is in operation (transition). Besides, springs fatigue also affects at both operations: clutching and braking. So two different springs fatigue values must be calculated in this process, the first one during the clutching and the second during the braking operation. Signals coming from the sensing of the clutch-brake to monitor the fatigue of the springs are collected in Table 3: Clutch-brake Signals for Spring Fatigue Control.

F(hidrpressure)F(springs)

Figure 4: Springs Fatigue Control Example





18 / 41


Table 3: Clutch-brake Signals for Spring Fatigue Control


Pressure_Safety_Valve signal (trigger,

time =0ms)

Position of the valve that commands the clutching and braking operations.

The rising edge of this signal triggers the clutching operation.

The falling edge of the signal triggers the braking operation.

Boolean Electrovalve signal / 0-10volts

1ms

Application_Pressure Pressure on the hydraulic circuit that moves the piston.

Float Pressure transducer

1ms

Crankshaft_Speed Speed on the crankshaft that moves the piston.

Float Rotary encoder 1ms

Flywheel _Speed Speed on the flywheel of the press machine.

Float Linear encoder 1ms

Clutching Pressure and Braking Pressure As mentioned above, Pressure_Safety_Valve signal, is used to trigger the clutching operation (raising edge) and the braking operation (falling edge). Apart from this signal, there are two other key points in the application pressure signal for this process: in the clutching operation when the crankshaft speed starts to increase (from 0 rpm); and in the braking operation, when the crankshaft speed starts to decrease. The value of Application_Pressure signal in those two time points is the pressure required to overcome the spring force. Clutching_Pressure when clutching operation is performed and Braking_Pressure when braking operation is carried out. As spring fatigue grows, the pressure required to overcome this force also gets lower. Therefore, measuring Clutching_Pressure and Braking_Pressure values and comparing them to predefined thresholds (CLUTCH_PRESS_Nominal and BRAKE_PRESS_Nominal) will determine when the fatigue of the springs requires a springs set replacement. In other words, when the clutch-brake is performing the clutching operation, when crankshaft speed goes above 0, that time indicates the pressure required to overcome the spring force (Clutching_Pressure). On the other hand, during braking operation, when





19 / 41


crankshaft speed goes under Flywheel speed the value of the pressure at that time indicates the pressure required to overcome the spring force (Braking_Pressure).

Therefore, there are the two pressure values that must be calculated in this process.

Table 4: GOIZ Algorithm Results for Spring Fatigue Control

Value Description Data type Signal Init time End time

Clutching_Pressure

Value of Application_Pressure signal when the crankshaft speed gets over 0 rpm during clutching operation.

Float Application pressure

Crankshaft speed > 0

Braking_Pressure

Value of Application_Pressure signal when the crankshaft speed gets lower than the flywheel speed during braking operation.


Crankshaft speed < Flywheel speed

Mechanical_Clutching_Time

Mechanical time required for performing clutching operation. (electrical and hydraulic delays are not taken into account).


Flywheel speed

(Crankshaft speed > 0) & (Pressure Safety Valve = 1)

(Flywheel speed = Crankshaft speed) & (Pressure Safety Valve = 1 )

Mechanical_Braking_Time

Mechanical time required to perform braking operation. (electrical and hydraulic delays are not taken into account).


Flywheel speed

(Flywheel speed > Crankshaft speed) & (Pressure Safety Valve = 0)

(Crankshaft speed = 0) & (Pressure Safety Valve = 0)

Following nominal values will define the thresholds for clutching and braking pressure:

• CLUTCH_PRESS_Nominal: pressure required to overcome the spring force on clutching operation.

• BRAKE_PRESS_Nominal: pressure required to overcome the spring force on braking operation.

• CLUTCH_MEC_Nominal: threshold for clutching operation time.

• BRAKE_MEC_Nominal: threshold for braking operation time.





20 / 41


The CREMA Platform triggers two alarms when spring fatigue exceeds the predefined thresholds: a warning and an error. KPIs and alarms Excessive_Spring_Fatigue_Warning, will be triggered when any of these two conditions is met:

• [Clutching_Pressure] > CLUTCH_PRESS_Nominal

• [Braking_Pressure] > BRAKE_DISP_Nominal

Excessive_Spring_Fatigue_Error, will be triggered when in addition to the warning conditions the following two conditions are met:

• [Mechanical_Clutching_Time] < CLUTCH_MEC_Nominal

• [Mechanical_Braking_Time] > BRAKE_MEC_Nominal

Triggered maintenance process The maintenance activity that must be carried out in the press machine when this problem is detected is to dismount clutch brake and to replace the springs. So when any of two alarms is triggered, CREMA Platform should select a suitable spring supplier as well as a TAS team which has mechanical skills and plan the date to carry out the maintenance activity.

2.3.4 User Story C: Slipping Control of the Press's Clutch-brake

When a clutch-brake is engaged (clutch position), the rotating part of the clutch-brake should rotate together with the flywheel of the press machine. Nevertheless, sometimes due to overload, the clutch slips and it is not able to rotate synchronously the crankshaft and the flywheel. Slipping control aims to detect this lack of synchronization when the component is clutched. To control the slipping during the clutch, the signal values in Table 5: Clutch-brake Signals for Slipping Control must be monitored. When the flywheel speed and the crankshaft speed get synchronized, it means that they are rotating at the same speed. The slipping control must then check that both axis continue rotating together until the braking operation starts. For this purpose, crankshaft speed and flywheel speed must be compared and triggered an alarm when values for both speeds are different. Therefore, this process must detect, while clutched, two points during time line and monitor if during this time interval flywheel speed is not higher than the crankshaft speed.

Table 5: Clutch-brake Signals for Slipping Control


Flywheel_Speed Motor axis speed, in RPM Float Linear encoder 1ms

Crankshaft_Speed Speed of crankshaft, in RPM Float Rotary encoder 1ms





21 / 41


Table 6: GOIZ Algorithm Results for Slipping Control

Value Description Data type [Signal] Condition

Synchonized_Time

Point in time when crankshaft reaches flywheel speed

Timestamp Time Crankshaft speed = Flywheel speed- 100 rpm) & (Pressure Safety Valve = 0)

Brake_Starting_Time

Value of Application_Pressure signal when the piston displacement starts (in braking operation)

Timestamp Time (Crankshaft speed < Flywheel speed) & (Pressure Safety Valve = 0)

These two points in time are:

• Synchonized_Time: Time instant when flywheel and crankshaft speeds are synchronized, it means that crankshaft reaches flywheel speed.

• Brake_Starting_Time: Time instant when braking starts.

KPIs and alarms The condition for triggering Clutch_Slipping alarm is:

• Flywheel_Speed (while clutching operation ends and braking operation starts) > Crankshaft_Speed (while clutching operation ends and braking operation starts)

This condition must be monitored during the entire interval between Synchonized_Time and Brake_Starting_Time.

Triggered maintenance process The maintenance task that must be carried out in the press machine when this problem is detected cannot be specified a priori. When Clutch_Slipping alarm is triggered, the origin of the problem must be identified. Thus, the CREMA Platform should select a suitable TAS team with hydraulic and mechanics systems skills and plan the date to carry out the maintenance activity to analyse the origin of the problem.





22 / 41


2.3.5 User Story D: Pressure Control of the Press's Clutch-brake

When a clutch-brake is performing the clutching operation pressure on the hydraulic circuit that moves the piston must not fall below a threshold. The aim of the pressure control process is to check that pressure on the hydraulic circuit throughout the clutching and braking operations (first 500ms) is correct and is held over a preset value. On one hand, it will check that pressure during clutching operation (in position 90 degrees of the crankshaft) is not below the nominal pressure and on the other hand, it will check that once the pressure becomes stable, pressure does not fall too low. Signals monitored in the clutch-brake to control the pressure during the clutching operation are collected in Table 7: Clutch-brake Signals for Pressure Control.

Table 7: Clutch-brake Signals for Pressure Control


Line_Pressure Pressure on the hydraulic circuit (before the electro valve)


1ms

Application_Pressure Pressure on the hydraulic circuit (after the electro valve)


1ms

Crankshaft_Position Position of the crankshaft, in 90 degrees position

Float Rotary encoder 1ms

Several values must be calculated processing data collected from the clutch-brake during clutching operation:

• Pressure_90: pressure in Application pressure signal when the crankshaft position is 90 degrees

• Pressure_Clutch: pressure in Application pressure signal when the application pressure is stabilized in clutching operation

Table 8: GOIZ Algorithm Results for Pressure Control shows values calculated by pressure control process:

Table 8: GOIZ Algorithm Results for Pressure Control

Value Description Data type Signal Condition

Pressure_90 Value of Application pressure signal when the position of the Crankshaft reaches 90 degrees.


Crankshaft = 90

Pressure_Clutch Value of Application pressure signal when, in clutching operation, application pressure becomes stable


(Line pressure = Application pressure) & (Pressure Safety Valve = 1)





23 / 41


Therefore, when Crankshaft_Position signals value is 90º the Application_Pressure signal value must be the nominal value for the pressure. KPIs and alarms The CREMA Platform must trigger two different alarms when pressure related issues are detected: a warning and an error.

• Pressure_Alarm_Low_Warning will be triggered when the first condition is met.

• Pressure_Alarm_Criticly_Low_Error will be triggered when both conditions are met

o Condition 1: [Pressure_90] < PRESS_Nominal

o Condition 2: [Pressure_Clutch] < PRESS_Nominal * 0.8

Triggered maintenance process The maintenance task that must be carried out in the press machine when this problem is detected cannot be specified a priori. When any of those two alarms are triggered, the origin of the problem must be identified. Therefore, the CREMA Platform should select a suitable TAS team with hydraulic systems skills and plan the date to carry out the maintenance activity to analyse the origin of the problem.

2.3.6 User Story E: Cooling Control of the Press's Clutch-brake

When a clutch-brake is operating properly, the temperature of the clutch-brake is held within pre-set limits, without overheating. When it is not working properly instead, it may tend to overheat. So one symptom that the clutch-brake is not operating as it should is the overheating. The reasons for the overheating can be diverse: insufficient cooling oil flow, clutch is not properly engaged, etc. A refrigeration hydraulic circuit goes through the clutch brake circulating cold fluid (oil in this case) reducing the internal temperature of the clutch brake. This circuit contains two sensors: one of them at the entrance of the clutch brake and the other one at the exit point of it.

OiltemperatureinOiltemperatureout

Figure 5: Cooling Control Example





24 / 41


The aim of this cooling control process is to check the temperature of the clutch-brake in order to identify when it exceeds a predefined maximum temperature (threshold). To check the temperature of the clutch-brake, the temperature of the refrigeration oil will be monitored.: cooling oil inlet and outlet temperatures; the difference between those two temperatures should not exceed the mentioned predefined maximum temperature limit.. Thus, to control the cooling of the clutch brake, the following signals must be considered:

Table 9: Clutch-brake Signals for Cooling Control


Oil_Temperature_In Cooling oil inlet temperature Float Temperature sensor 1ms

Oil_Temperature_Out Cooling oil outlet temperature Float Temperature sensor 1ms

Oil_Flow Cooling oil flow Float Flow meter 1ms

KPIs and alarms This process may trigger two different alarms: clutch-brake over temperature warning, and insufficient cooling oil flow warning. The clutch-brake over temperature warning will be triggered when the following condition is met:

• Oil_Temperature_Out – Oil_Temperature_In < 30ºC (maximum oil temperature difference)

On the other hand, the insufficient cooling oil flow warning will be triggered when following condition is met:

• Oil_Flow < 40l/min (Nominal oil flow) * 0.8

Unlike the previous user stories where data collected from the clutch-brake must be first processed in order to get calculated values or data related to a specific time point of the clutching or braking operation must only be considered, over temperature and underflow checking can be a continuous process throughout the operations of clutching and braking. Triggered maintenance process The maintenance activity that must be carried out in the press machine when this problem is detected cannot be specified a priori. The origin of overheating or low flow can be diverse. So, when one of these alarms is triggered, the origin of the problem must be identified first. In this sense, CREMA Platform should select a suitable TAS team with hydraulic and mechanical systems skills and plan the date to carry out the maintenance activity to analyse the origin of the problem.





25 / 41


2.3.7 User Story F: Braking Angle Control of the Press's Clutch-brake

In a press machine with each die stroke, the eccentric makes a 360º turn. In each turn, there can be seen the Top_Dead_Centre or TDC, 0º, and the Bottom_Dead_Centre or BDC, 180º. When the die is going up, a stop signal is ordered. The angle in which de eccentric stops after the truck is stopped is called the braking angle.

Figure 6: E2 Braking Overshooting Angle Example

If the eccentric overruns its normal stopping position by an amount specified by the manufacturer, maximum 15º and preferably 10º, a stopping signal shall be immediately initiated and no new cycle initiation shall be possible. If this happens, the machine will only be possible to restore further operation by a restricted means such as by tool, key or electronic password. For the development of this User Story, different dies are going to be 0considered. One press machine can use multiple dies in its lifecycle, and depending on the used die, the braking angle might vary. That is the reason of considering different dies. In order to obtain that information, a number of variables will be used (see Table 10: Press Machine Variables). Note that almost all the variables can dynamically change if the die changes. With this user story, FAGOR will get insight on: (i) performance of the clutch-brake, (ii) braking angle on the time, and (iii) braking angle suddenly increase. When this overshooting on the braking angle happens, an alarm related will be triggered and two situations can arise:

a) If it’s a braking angle overshooting on the time, a suitable TAS Team should be coordinated to try to know the origin of the problem.

b) Otherwise if it’s a suddenly increase of the braking angle, the CREMA Platform should found a suitable spare part supplier specialized on that component to solve the issue or to realease a new component.

Both alarms can be detected as follows: c) Overshoot_Angle < 15º -> KPI1 (Normal)





26 / 41


d) Overshoot Angle >= 15º -> KPI2 (Critical)

2.4 Data Sources and Models

The data sources and models for Machinery Maintenance use case are briefly described with references to their original user story.

2.4.1 Data Sources

As in the afore-mentioned user stories, machine-level and component-level data will be collected from the FAGOR's press machine. Machine-level data is managed by a machine-level PLC that controls the press machine, while component-level data will be provided by a bunch of clutch-brake component's sensors. Despite holding two different logical data sources for a FAGOR press machine (one PLC for machine-level data and sensors for component-level data), all data to CREMA will be accessed from a single gateway, i.e. the press machine will include a data logger that will connect to a second PLC, i.e. a wrapper PLC, that collects data from all sensors and machine-level PLC. According to the Global Architecture Definition (T3.1, D3.1), the T4.4 component will handle multiple data source connections through a message broker (e.g. ActiveMQ). For the Machinery Maintenance use case, the FAGOR data logger will be connected to the CREMA Platform. This means that the data logger should push continuously raw data collected from the press machine to this sink (e.g. implementing a producer). In case of bidirectional communication between the data logger and CREMA component is needed, FAGOR data logger should provide a REST API for that purpose, i.e., to start or stop the data stream.6

2.4.2 Press Machine Related Data

The FAGOR data logger will allow the access to all the required machine information. Table 10: 7 resumes some of the variables that will be potentially collected within the Machinery Maintenance use case (all variables have already been referred and explained in the user stories above). Bearing in mind these variables, Listing 1 exemplifies a JSON data schema that can be collected from the press machine.

2.4.3 TAS Teams and Suppliers Related Data

Nowadays, when a machine breakdown occurs FAGOR must arrange TAS teams and spare-part suppliers in a quite manual fashion. In both cases, the availability of spare parts in the location where the machine is settled must also be arranged. To make these decisions and orchestrate a proper maintenance process in an automated way, detailed information about the spare part suppliers and TAS teams for FAGOR press machines, as well as for GOIZ clutch-brake component will be required by CREMA.

6 The latter will be developed in a later stage of this project (T7.2). 7 Note that frequency column indicates the frequency at which each variable value must be collected from the press machine, i.e. how often each variable's value must be read from the data source.





27 / 41


Table 10: Press Machine Variables

Variable Description Data type Data source Frequency

Press machine data

Die Reference Reference of actual die String Press machine PLC 1 s

Cylinders and rods efforts Force supported by the press Integer Press machine PLC 1 s

Die total Strokes Strokes of press with that die Integer Press machine PLC 1 s

MachineSpeed/Cycle time Speed completing cycle Float Press machine PLC 1 s

Height regulation Truck regulation Float Press machine PLC 1 s

Truck inclination Inclination of the truck/roads Float Press machine PLC 1 s

Overshoot angle Braking angle Float Press machine PLC 1 s

Machine Total Strokes Historic strokes made Integer Press machine PLC 1 s

Clutch-brake data

Pressure Safety Valve trigger

Position of the valve that commands the clutching and braking operation

Boolean Electrovalve signal + opto-coupler + resistor/0-10volts

1 ms

Line pressure Pressure on the hydraulic circuit before the valve.

Float Pressure transducer 1 ms

Application pressure Pressure on the hydraulic circuit. Float Pressure transducer 1 ms

Crankshaft position Position of the crankshaft, in degrees Float Rotary encoder 1 ms

Crankshaft speed Speed on the crankshaft Float Rotary encoder / tachogenerator 1 ms

Flywheel speed Motor axis speed, in RPM Float Linear encoder 1 ms

Oil temperature in Cooling oil inlet temperature Float Temperature sensor 1 ms

Oil temperature out Cooling oil outlet temperature Float Temperature sensor 1 ms

Oil flow Cooling oil flow Float Flow meter 1 ms





28 / 41


Listing 1: JSON Example – Listing showing press machine related variables

press_machine: { “id”: “String”, “customer”: “String”, "location": { "country": “String”, "latitude": “Float”, "longitude": “Float” } “variables”: [{ “id”: “String”, “description”: “String”, “data”: “String”, “type”: data_types, “unit”: “String”, “frequency”: “Integer” }], “components”: [{ “id”: “String”, “variables”: [{ “id”: “String”, “description”: “String”, “data”: “String”, “type”: data_types, “unit”: “String”, “frequency”: “Integer” }] } ] }

Listing 2: JSON Example – Listing showing TAS related data

TAS_team: { “id”: “String”, “company_name”: “String”, “location”: { “country”: “String”, “latitude”: “Float”, “longitude”: “Float” }, “geographical_area”: areas “components”: [ { “component”: component_types, “time”: “Integer”, “skills”: skill_types, “commissioning_cost”: “Float” } ]





29 / 41


Unlike the information collected from the press machine, which information is dynamic and is changing while the machine is working, the information about TAS teams and suppliers will be mainly static. Anyway this set of information will also have a dynamic subset of information as the availability, response time, etc. that may change over the time or depending on when the service is required. CREMA Platform must manage this kind of information although the press machine itself will not provide it. Thus, CREMA Platform should provide some interface to add this information on one hand and to maintain it updated on the other. The data model that will describe the information about a TAS team is depicted below. As noted for previous data models, this and other data models explained in this section are just examples and should not be taken as the ultimate data structures. On one hand, this data model shows that a TAS team can work on one or more components (although in this use case a single component of the press machine is only considered). For each component a TAS team can have different skills, as well as different response time or cost. On the other hand, besides the information described above for each TAS team, the CREMA Platform must also manage the availability of each TAS team. This information will be necessary for CREMA to schedule the maintenance activities in a coordinated way. The CREMA Platform should also manage information of the maintenance contracts because it may be relevant to make the best decision about the most suitable maintenance process to be carried out by the platform.

Listing 3: JSON Example – Listing showing maintenance contract related data

maintenance_contract: { “machine_id”: “String”, “company_name”: “String”, “start_date”: “Date”, “end_date”: “Date”, “contract_type”: contract_types, <Add any other relevant information can go here> }

Finally, the CREMA Platform will also manage information about spare part suppliers, as for maintenance processes orchestration will be needed. The data model that will describe the information about a spare-part supplier is depicted below.





30 / 41


Listing 4: JSON Example – Listing showing spare-part suppliers related metadata

supplier: { “id: “String”, “company_name”: “String”, “location”: { “country”: “String”, “latitude”: “Float”, “longitude”: “Float” } }, “components”: [ { “component”: component_types, “lead_time”: “String”, “quality”: quality_levels, “price”: “Integer” } ] }

2.5 Process Definitions

Within the Use Case I Machinery Maintenance, we consider two-separated process models, namely: a data acquisition or monitoring process model which will allow CPS stream collection, data transformation and storage, and KPI comparison and maintenance process model which will find for suitable TAS teams and spare-part suppliers after a critical alarm is considered by the user. Hence, the former will be responsible for monitoring the FAGOR press machines and its components, i.e., the clutch-brake in this case, located worldwide. It will get and store machine-level as well as component-level data collected from FAGOR presses in the CREMA CRI component. The latter, in turn, will be executed once the user considers that the monitored alarm is critical and thus the machine needs to start the intervention/maintenance process. The above-mentioned processes are further described below.

2.5.1 Data Acquisition (monitoring) Process

The Data Acquisition Process aims to collect data from the press machine and its associated components (i.e., clutch-brake), transform raw data to a convenient format and storage this data into data storage component (CRI) for later usage. The Data Acquisition Process (see Figure 7: Data Acquisition Process) will contain the following process steps (s):

• [s1] Get press machine data: this process task connects to the press machine, i.e., it enables CREMA - FAGOR data logger connection and gets the raw data in a streaming pipeline. Prior to process instance execution, this abstract task will be mapped to a particular service implementation in T4.4 so once the process instance is created, CREMA starts receiving data from the source CPS service.





31 / 41


• [s2] Transform raw data: this process step transforms raw data coming from the press machine to a convenient data format for later storage (e.g., from jsonA to jsonB adding some metadata). As for the "Get press machine data" task, this abstract task will be mapped to a concrete T4.2 service in the marketplace, so different transformation services could be used for different Data Acquisition process instances.

• [s3] Execute GOIZ algorithm: this process step takes raw data coming from the "Get press machine data" step and computes this data. For example, Displacement_Time_Clutching and Displacement_Time_Braking values will be calculated by computing Application_Pressure values collected from the clutch-brake, as explained in Section 2.3.2. The computed result will be pushed to the CREMA Platform for later business rule definition and monitoring purposes. This abstract task will be mapped to an internal CREMA service (i.e., a ad-hoc service implemented for Use Case I) or to a data analytics component, which could run a streaming job to compute machine raw data.

• [s4]: Push data to CRI: this process step stores transformed (s2) and/or computed data (s3) into the data storage component. It will access an API to store data.

The user will be also able to start or stop the data collection for each particular Data Acquisition process instance.

2.5.2 Maintenance (KPI comparison) Process

The Maintenance Process aims to select a suitable TAS (Technical Assistance Service) team and spare-part supplier, if necessary, once the user considers that an on-site maintenance is required. The monitoring and alerting component will provide access to different alarms (e.g. critical and warning alarms) of each particular process instance, so the user can evaluate each alarm and decide on intervention. Two main situations can arise here:

1. Not intervention required, i.e., an alarm is restored without any Maintenance Process instance: this means that although a KPI threshold is exceeded the alarm is not severe enough and is not calling upon FAGOR to worry ruminate about all the terrible things that can happen (e.g., minor or warning).

2. Intervention required, i.e., a Maintenance Process instance is started: An alarm derives a maintenance process instantiation. This means that an on-site maintenance is required in order to reduce machine downtimes and more complex situations such as clutch-brake replacement. For instance, when Friction Disc happens (see Section 2.3.2) FAGOR/GOIZ will need to find a friction disc supplier in order to replace the original parts as soon as possible. Beyond this particular user story, the aforementioned user stories may consider two different situations:

i. TAS team selection is required: this means that only TAS team selection will be done during Maintenance Process execution.

ii. Spare-part supplier selection is required: this means that the machine component should be replaced.

As depicted by Figure 8: Maintenance Process, the Maintenance Process is not executed until a user considers an alarm within the CREMA Platform. The following steps are





32 / 41


encapsulated in monitoring and alerting component (MON) for process instance monitoring and KPI definition.

s1 Get press machine data

s2 Transform raw data

s4 Push data to CRI

s3 Execute GOIZ

algorithm

if data collection off by the user

if data collection

on by the user

connection works

Figure 7: Data Acquisition Process

s1 Select business

rule(s)s2 Check KPI

threshold s3 Send a message to the TAS manager

(notify user)

Selects the business rules to monitor

s5 Get customer

requirements

Maintenance contract, location, etc.

false alarm

s6 Find suitable TAS

s7 Find suitable spare-partsupplier

s8 Schedule onsite

maintenance

s9 Onsite clutch-brake maintenance

s10 Notify involved

stakeholders

s4 Check alarm

intervention required

compound task for MON

optimization tasks for ODERU

MON notifies PRU for maintenance

Figure 8: Maintenance Process

• [s1] Select business rule(s): The user, via MON component, selects business rules to activate. Already defined business rules are stored in CRI component so the user can decide which of the business rules wants to execute.

• [s2] Check KPI threshold: The MON component (more details in Global Architecture Definition (T3.1, D3.1)) has a Rule Engine that interprets different business rules. Once the user selects the business rules to monitor (s1 above), the





33 / 41


Rule Engine starts supervising these business rules. If a certain condition is exceeded business rule's actions will activate.

• [s3] Send a message to the TAS manager (notify user): For Use Case I, the MON will alert the user by showing different kind of alarms (e.g. warning or critical) in the MON frontend. Therefore, the TAS manager can receive these alarms and trigger command points if a critical situation arises.

• [s4]: Check alarm: This step specifies a user task where the user checks all generated alarms for each process instance and decides on the actions to be undertaken. In this particular situation, if the user decides to take action, this event will start a maintenance process within the CREMA Platform.

A user event will trigger a Maintenance Processes. Such type of processes will contain, at least, the following steps:

• [s5] Get customer requirements: This process step gets the customer requirements related to the monitored installation machine (Data Acquisition Process). This abstract task is mapped to an internal service, which actually retrieves each particular requirement for each customer.

• [s6] Find suitable TAS: This process step finds a suitable TAS team in the marketplace. This selection takes customer requirements and alarm message as an input and finds an appropriate TAS team that can solve issue(s) in the current machine.

• [s7] Find suitable spare-part supplier: Similarly to s6, this process step finds a suitable spare-part supplier from the marketplace that can satisfy customer requirements and alarm message.

• [s8]: Schedule onsite maintenance: It will notify the user about possible maintenance schedule depending on TAS team and spare-part selection. The user could therefore set a particular maintenance date onsite, so the spare-part supplier could manage its calendar and resources to guarantee spare-part manufacturing and shipping.

• [s9]: Onsite clutch-brake maintenance: This process step is a user task that will be mapped to a onsite maintenance work. This means that TAS teams will be responsible for machine checking and maintenance.

• [s10]: Notify involved stakeholders: It will call a feedback service to notify involved stakeholders about the maintenance intervention. This will be shown in the Dashboard so the user can check that the machine is restored and is well operating again.





34 / 41


3 Machinery Maintenance Use Case Evaluation Within the CREMA project, the Machinery Maintenance use case evaluation will be carried out in a press located in FAGOR ARRASATE (or FAGOR), which actually includes a clutch-brake provided by GOIZ. As explained above in User Story sections, machine-level and component-level (clutch-brake) data will be collected through FAGOR data logger system. Machine-level data will be managed by the press machine’s PCL (Siemens S7) while GOIZ clutch-brake will include a couple of sensors, without interrupting the press PLC's program. In order to merge both sources, an additional wrapper PLC will be added to the current press, as kind of data logger. This PLC will bring together machine-level data from the Siemens S7 PLC and component level data gathered from clutch-brake sensors. This way the Machinery Maintenance use case will offer a single data access point to CREMA. Beyond CREMA, this architecture would enable FAGOR to add in the future any other sensored component whose information needs also to be collected by CREMA Data Collection in a simple way by connecting it to this PLC. Figure 9: Machine-level and Component-level Data Acquisition illustrated the high-level functional architecture of the solution for machine-level and component-level data acquisition system.

sendrawdata

CREMA(T4.4-DataRelay)

DATALOGGER

PLC(wrapper)

Ethercat

PLC

pressmachinedataclucth-brakedata

Oncloud(CREMAPlaEorm)

Onpremise(CREMAPlaEorm)

clucth-brakesensors

Figure 9: Machine-level and Component-level Data Acquisition

The objectives of the evaluation of the Machinery Maintenance use case are twofold: 1. To test that the CREMA Platform monitoring features can enable the collection of

information from FAGOR press machines located along the world, to process all this information in order to detect problems that occur in the press machines, and report all the problems detected for each press machine.





35 / 41


2. To demonstrate that when the CREMA Platform detects a problem in a press machine a proper maintenance process is executed to solve the problem arisen in the press machine.

The Machinery Maintenance use case evaluation therefore will be splatted into two different sections. The first one will address the collection of data from press machines and the activation of alarms when unexpected operating conditions at the press machine are detected by CREMA. The second section will address the orchestration of the maintenance activities derived from each alarm launched by the CREMA Platform, taking into account some characteristics (location, maintenance contract, etc.) for the press machine. To carry out the first part of this evaluation, operating conditions will be modified in the press machine, trying to cause conditions for alarm activation in the CREMA Platform. What it is expected with these evaluation scenarios is to asses that the CREMA Platform detects all the alarm conditions, and alarms are properly triggered when the conditions are met. In this sense, taking into account the user stories described in Section 2.3 Detailed User Stories the following set of evaluation scenarios have been identified.

3.1.1 Condition-based Monitoring Scenarios for User Story A-F

3.1.1.1 Scenario A: Clutch-brake’s friction disc wear simulation

The objective of this scenario is to evaluate friction disc wear control process, which aims to detect when friction discs of the clutch-brake are worn and need to be replaced. As to cause wear of disc requires to have the press machine working for very long time and this is not possible to perform this evaluation in a controlled manner, this scenario will be carried out by modifying by some of the values collected from the clutch-brake. As explained in the description of the user story, the CREMA Platform must calculate Displacement_Time_Clutching and Displacement_Time_Braking values as well as Total_Slipping_Time and Mechanical_Braking_Time values to compare them with predefined thresholds. Thus, for this evaluation scenario, the Displacement_Time_Clutching and Displacement_Time_Braking values will be increased by software in order to make them big enough to met the conditions for Excessive_Friction_Disc_Wear_Warning alarm activation. Likewise Total_Slipping_Time and Mechanical_Braking_Time will be increased by software in order to met the conditions for Excessive_Friction_Disc_Wear_Error alarm activation. Hence, when alarm triggering conditions are met Excessive_Friction_Disc_Wear should be triggered by the CREMA Platform. Therefore, the results of this evaluation scenario will be considered valid if when Displacement_Time_Clutching exceeds CLUTCH_DISP_Nominal threshold value or when Displacement_Time_Braking exceeds BRAKE_DISP_Nominal threshold value Excessive_Friction_Disc_Wear alarm is triggered.

CLUTCH_DISP_Nominal, BRAKE_DISP_Nominal, CLUTCH_MEC_Nominal and BRAKE_MEC_Nominal threshold values will be measured during the first test that will be carried out in the evaluation press machine itself.





36 / 41


3.1.1.2 Scenario B: Clutch-brake’s spring fatigue simulation

The objective of this scenario is to evaluate spring fatigue control process, which aims to detect when the spring of the clutch brake has lost its force and need to be replaced. In order to perform the evaluation of the spring fatigue in a controlled manner, this scenario will be carried out by simulating the spring fatigue conditions modifying by software the values for the pressures needed to overcome the spring, Clutching_Pressure and Braking_Pressure, as well as Total_Slipping_Time and Mechanical_Braking_Time values.

Thus, when KPI conditions defined for this process are met, the CREMA Platform should trigger Excessive_Spring_Fatigue_Warning and Excessive_Spring_Fatigue_Error alarms. Therefore, the results of this evaluation scenario will be considered valid if when Clutching_Pressure exceeds CLUTCH_PRESS_Nominal threshold value or when Braking_Pressure exceeds BRAKE_PRESS_Nominal threshold value Excessive_Spring_Fatigue_Warning alarm is triggered.

CLUTCH_PRESS_Nominal and BRAKE_PRESS_Nominal as well as CLUTCH_MEC_Nominal and BRAKE_MEC_Nominal values will be measured during the first test that will be carried out in press machine where the evaluation will be performed.

3.1.1.3 Scenario C: Clutch-brake’s slipping simulation

The objective of this scenario is to evaluate slipping control of the press’s clutch-brake, which aims to detect when the clutch brake is slipping, despite it is already engaged. To get conditions for the clutch-brake to slip is not possible to do in a controlled manner in the press. Thus, slipping control process will be evaluated also by simulation. The conditions for simulating clutch-brake slipping must be generated by decreasing the value of crankshaft speed by software when the flywheel and crankshaft are already synchronized. Therefore, the results of this evaluation scenario will be considered valid if Clutch_Slipping alarm is launched when crankshaft lost synchronization with the flywheel, i.e., when slippage is forced by software.

3.1.1.4 Scenario D: Pressure loss at the clutch-brake

The objective of this scenario is to evaluate pressure control of the press’s clutch-brake, which aims to detect when the pressure in the hydraulic circuit of the clutch-brake is not what it should be and thus the clutch-brake is not the working under the specified conditions by GOIZ. To get pressure loss conditions, the key of the oil circuit in the press machine will be slightly closed during the clutching operation. As a consequence the CREMA Platform should launch the Pressure_Alarm_low alarm. When the piston finishes its displacement, the key of the oil circuit in the press machine will be closed a little bit more to cause a greater pressure drop. Consequently, the CREMA Platform should launch Pressure_Alarm_criticly_low alarm.





37 / 41


Therefore, the results of this evaluation scenario will be considered valid if Pressure_Alarm_low alarm is launched when the key is closed and Pressure_Alarm_criticly_low alarm is launched when the key is closed when the piston finishes its displacement.

3.1.1.5 Scenario E: Clutch-brake overheating

The objective of this scenario is to evaluate cooling control of the press’s clutch-brake, which aims to detect overheating in the GOIZ clutch-brake. To get alarm activation conditions two actions will be carried out in the press machine: the temperature of the outlet sensor will be increased by heating it and the key of the refrigeration oil circuit in the clutch-brake will be closed 45 degrees in order to reduce oil flow and increase the temperature. The results of the execution of this scenario will be considered valid if Clutch-brake over temperature alarm is triggered when outlet sensor is heated and the difference of temperature at the inlet and at the outlet exceeds the predefined limit (which may also be modified if needed to carry out these evaluations) and if insufficient cooling oil flow alarm is triggered when the refrigeration circuit key is closed.

3.1.1.6 Scenario F: Overshooting on the press machine braking angle

With this scenario, FAGOR wants to evaluate the performance of the clutch-brake. To achieve that, data from the PLC of the machine will be collected. Two types of alarms are going to be considered. On one hand, the braking angle along the time will be monitored. This braking angle is going to be increased gradually to show how this angle is wearing down. With this casuistry, a maintenance activity to be carried out by a TAS team to detect the real cause of the overshoot. On the other hand, the braking angle of the clutch-brake will be monitored, but a suddenly increase of the braking angle is going to be simulated. When this happens, the CREMA Platform should orchestrate a maintenance task that will be carried out by a spare-part supplier in order to know why this suddenly increase has happened.

3.1.2 Maintenance Process Execution Scenario Depending on Press Machine Conditions (User Story F)

The aim of all the scenarios described above is to achieve the conditions in the press machine for the activation of the alarms and to check that the proper alarm is activated for each case. That will be the first part of the Machinery Maintenance use case evaluation. The second part of the evaluation scenarios is related to the maintenance processes that will be orchestrated when a user triggers an alarm. When an alarm is triggered, the CREMA Platform must also orchestrate the maintenance process to solve the issue. The maintenance could consist of a set of inspection tasks to be carried out in the machine to detect the real causes of the failure or even the replacement of defective parts in the press machine itself. The purpose of these evaluation scenarios is to assess that, depending on the location of the press machine and the conditions in the maintenance contract, the CREMA Platform





38 / 41


will be able to orchestrate a different maintenance process, selecting the most suitable TAS teams and spare part suppliers for each case. To carry out this second part of the evaluation, different press machine locations are needed. As all the tests will be performed in the same press machine located at the headquarters of FAGOR in Mondragon, configuring different locations in the CREMA Platform for the press machine will simulate different locations for the press machine. Thus, three different relevant locations or geographical areas for FAGOR press machines will be selected first, and then an evaluation for each one will be performed. This way, three different executions of the same tests will be performed, and as result of each execution, a different maintenance process must be obtained. Therefore, three different locations must generate three different processes. As referred at the beginning of the description of this evaluation scenario, maintenance process orchestration starts in the CREMA Platform when an alarm is triggered. Therefore, for this maintenance process orchestration scenario alarm and maintenance activities described in Braking angle control of the Clutch-Brake scenario will be considered. It means that for carrying out this evaluation, alarm conditions described in Braking angle control of the Clutch-Brake scenario will be obtained first in the press machine to activate the alarm and the maintenance process that CREMA Platform should orchestrate must be the one described in that scenario.

3.2 Evaluation Equipment and Testbeds

Technical testings’ related with the areas concerning to FAGOR and GOIZ will be carried out in a press located in FAGOR headquarters in Mondragon. The press itself incorporates a clutch-brake provided by GOIZ. The data acquisition equipment and all necessary sensor technology installation will be made in the mentioned press, in order to obtain the data necessary to carry out the analytical part. Some information about the press machine where Machinery Maintenance Use Case evaluation will be carried out can be found below:

• Year of construction: 1998 • Serial number: 20.144 • Number of rods: 4 • Nominal force 12,7mm before the BDC: 12.500 KN • Maximum force used for die tests: 15.000 KN • Fixed trail: 710mm • Truck regulation: 300m • Distance between truck and table: 1250mm • Table dimensions: 5000x2300mm • Truck dimensions: 5000x2300mm • Table height: 60mmm • Strokes per minute: 10-14 • Principal engine power: 14Kw • Regulation engine power: 11Kw • Electrical power supply: 380V - 50Hz





39 / 41


Figure 10: (a) FAGOR Press Machine and (b) GOIZ Clutch-brake Sensors Installation in

the Press Machine

3.3 Evaluation Metrics

In this particular scenario, several metrics could be obtained from carrying out the aforementioned scenarios such as the percentage of alarm conditions detected by the CREMA Platform, the maintenance process cost (depending on the costs associated to TAS teams, spare-parts, etc.), or the maintenance process activities duration. Although all these metrics are important and can somehow visualize the benefits obtained by implementing the new condition-based monitoring and maintenance process based on CREMA, they do not enable to quantitatively compare the new maintenance management to the previous one without the CREMA Platform. Those result for themselves can suggest some benefits of using the CREMA Platform, but the obtained benefit is not measurable. As it was highlighted in the introduction the benefits expected by FAGOR/GOIZ by incorporating the CREMA Platform to its press machines maintenance management were

• to reduce up to 60% the unscheduled machine breakdowns

• to reduce 15% the total machine breakdown, in order to increase the availability

• to reduce 50% the intervention time

• to reduce 25% the cost of the intervention Both FAGOR and GOIZ manage historical information on the breakdowns in press machines due to problems with the clutch-brake or any other component. Errors in GOIZ clutch-brake are 6% due to disc wear, 4% due to spring fatigue, 65% due to working on inappropriate pressures, 15% due to overheating and 10% due to other uncategorized reasons. Thus detecting in advance the errors described into the user stories for the clutch-brake can lead GOIZ to reduce the unexpected breakdowns, due to clutch-brake problems, in a press machine up to 90%. Likewise, FAGOR and GOIZ manage information and estimations of costs associated with the fault reparation activities carried out on the press machines as well as intervention





40 / 41


times. In this sense, as the CREMA Platform will be able to calculate for each process the costs of TAS teams and spare parts as well as the intervention time required for performing the inspection or reparation activities in the press machines, a quantitative evaluation for the use case will be conducted. Average cost and time values calculated from historical data could be compared to the values provided by CREMA for the new processes. It should be mentioned that these metrics would be in some cases estimated values and the results of performing an evaluation scenario might be generalized to more general scenarios. Therefore, taking into account the limitations to get metrics to measure the benefits of using the CREMA Platform, following metrics could be obtained from the execution of the evaluation scenarios described below: (i) the percentage of alarms detected, (ii) the time of the intervention for each maintenance process, and (iii) the cost of the intervention for each maintenance process.





41 / 41


4 Conclusion Through the implementation of the CREMA Platform FAGOR and GOIZ expect to improve and automate its condition-based machine maintenance processes and operations, as well as efficiently deal with spare-parts suppliers (e.g., GOIZ) by monitoring key performance machine parameters and suppliers availability. The abstraction and virtualization of press machines, i.e., its PLC/SCADA systems, will be an important part of the project since it will allow direct access to machine data. However, security and privacy concerns will also play an important role, in order to securely access the industrial control system. Overall, FAGOR aims to obtain a configurable and secure industrial Internet capable of collecting data from a variety of machines, remote monitoring of KPIs, automating maintenance processes and allowing smart spare-part selection and communication. The next deliverable (D7.3) will present a detailed implementation details including to truly evaluate the applicability of CREMA in the presented use case scenario.

Cloud-based Rapid Elastic MAnufacturing...involves two industry partners, namely FAGOR and GOIZ. In...

Documents

Transcript of Cloud-based Rapid Elastic MAnufacturing...involves two industry partners, namely FAGOR and GOIZ. In...