Using Intelligent Edge Devices for Predictive Maintenance on Injection Molds ^†

Abstract

A considerable part of enterprises’ total expenses is dedicated to maintenance interventions. Predictive maintenance (PdM) has appeared as a solution to decrease these costs; however, the necessity of end-to-end solutions in deploying predictive models and the fact that these models are often difficult to interpret by maintenance practitioners hinder the adoption of PdM approaches. In this work, we propose a flexible architecture for PdM to recommend maintenance actions. The proposed architecture is based on containerized microservices on intelligent edge devices together with a hybrid model which fuses generalized fault trees (GFTs) and anomaly detection. Results on injection molds carried out at OLI, a Portuguese company, show that the proposed solution is suitable for deploying predictive models and services such as data preprocessing, sensor management, and data flow control, among others. These services run near the shop floor, allowing for greater flexibility, as they may be remotely managed and customized according to the company’s requirements. The results of the GFT model show an estimated reduction of more than 63% in current maintenance costs, while the distribution of analytics tasks by the edge devices reduces the burden on the network, requiring only 0.2% of the current cloud storage.

1. Introduction

One-third of the global plastics production is processed by injection molding [1], making injection molding machines (IMMs) widely used industrial assets. Figure 1 depicts the main components of a typical IMM. During the injection process, plastic pallets stored in a feed hopper are melted along the barrel by heating bands and injected via pressure into a mold cavity filled with plastic material. After solidifying, the material is ejected from the mold cavity, producing a three-dimensional part. The complexity of the injection molding process makes the maintenance of IMMs and their components a challenge [2], which has particular importance when it is acknowledged that expenses related to maintenance are typically a considerable part of an enterprises’ total expenses [3]. For this reason, adopting sensors to monitor IMMs and their components is very common, especially concerning injection molds [4,5], as they are a key component of the injection process [6].

Injection molds are subjected to degradation due to repeated use, high temperatures, pressure, and contact with melted materials, which may cause issues including such as surface degradation, dimensional changes, or misalignment. These issues may be time-consuming, leading to high periods of unavailability, or may be easily solved without a major intervention. Scheduling maintenance actions for these components is challenging, as the time between two failures does not follow a pattern, and requires balancing the mold’s performance with the expected maintenance costs. Furthermore, keeping detailed records of mold maintenance activities, including repairs, modifications, and maintenance history is essential for maintenance planning; however, this can be challenging in large-scale manufacturing.

There are several strategies to handle maintenance actions, such as corrective maintenance (CM), preventive maintenance, condition-based maintenance (CBM) [7], and predictive maintenance (PdM). CM assumes that only corrective actions are taken, i.e., maintenance is carried out only when there is a failure that forces the equipment to stop and it cannot work anymore without an intervention. This strategy may be useful when it is used in components that are easily and quickly replaceable, and when failure does not cause other malfunctions in the system. Otherwise, severe failures may occur, which can be costly and cause long periods of unavailability. PM intends to schedule proactive maintenance actions, usually in equally spaced intervals of time. However, this strategy may encounter two issues: (1) the asset’s lifetime may be under-exploited if the time between interventions is too short; and (2) if this time is too long, the same issues are encountered as in the CM case. When there are components in the system that need to be replaced due to wear and for which the lifetime follows a well-defined pattern, PM may be successfully implemented; however, this scenario only occurs in controlled environments where the components subjected to wear spend their entire working lifecycles under the same working conditions, which is not the typical scenario in real industrial environments.

According to [8], more than 30% of maintenance costs are derived from poor maintenance scheduling. For this reason, PdM, and CBM strategies have received increasing attention, as they take into account the actual degradation state of the assets. While CBM usually relies on monitoring and analysis of the relevant parameters of an industrial process, PdM additionally exploits analytics techniques to improve maintenance decisions. The adoption of optimal maintenance strategies is crucial for enterprises, and proactive actions may not be the most suitable strategy for all scenarios; when a given failure is very simple to solve, spending time and resources on proactive actions may be unnecessary. Reliability-centered maintenance (RCM) is considered a type of PM [9]. It is not a specific maintenance strategy, instead being a decision-making process based on reliability analysis that attempts to ensure efficient, cost-effective, and reliable maintenance [10]. RCM uses proactive actions while combining several maintenance policies to optimize its process; in this way different decisions may be taken for different failures.

Proactive maintenance actions require end-to-end infrastructure to handle data collection, storage, and processing, which represents a considerable challenge [11]. Although centralized cloud solutions may provide high computational resources and storage capacities, the increasing number of industrial assets and high volumes of data require modular solutions capable of handling analytical tasks near the shop floor to alleviate the burden on the cloud [12]. Using intelligent edge devices for PdM distributes the computing requirements, enabling more efficient data processing, which in turn reduces latency. This approach can enhance security as well, as sensible data can be processed and stored locally in an isolated network, reducing both network latency and exposure to potential cybersecurity threats.

In our previous work, presented at the 4^th International Conference on Industry 4.0 and Smart Manufacturing [13], we proposed a combination of the statistical technique of generalized fault trees (GFTs) and the anomaly detection technique of an isolation forest (IF) to optimize maintenance actions on injection molds at OLI, a Portuguese company known for its expertise in the injection molding process. The above-mentioned approach suggests proactive actions prior to severe failures, while allowing non-severe failures to occur. This work extends our previous paper [13] by: (1) presenting a smart distributed architecture based on Docker microservices deployed on intelligent edge devices; (2) describing in detail the deployment of the predictive models in the proposed architecture and presenting new services and functionalities, such as retrofitting of IMMs with new sensors; and (3) providing additional experimental results. The main contributions of this work are as follows:

• We introduce a novel modular architecture centered around intelligent edge devices, offering significant advantages in data preprocessing and analytics capabilities in close proximity to the shop floor. By harnessing the potential of edge devices, the proposed architecture alleviates network congestion and diminishes storage demands. The aggregated and preprocessed data occupy less than 0.2% of the storage space needed for the raw data, enhancing efficiency and resource utilization, which demonstrates the potential of intelligent edge devices in optimizing data management and analysis within industrial settings.
• The proposed architecture is presented for deployment of highly adaptable services on edge devices and on the cloud. This approach empowers seamless customization of services developed through Docker containers, allowing for effortless modification without disruption to ongoing operations. To validate this capability, we successfully implemented retrofitting sensors on the feed hopper of an IMM in response to a new specific requirement from the company. Our findings demonstrate the practicality and effectiveness of the proposed solution in meeting evolving industrial needs while ensuring uninterrupted service functionality.
• We exploit OpenBalena [14], an open-source platform, in conjunction with a graphical interface to efficiently manage device fleets and remotely update the microservices deployed on edge devices. Through this approach, we demonstrate the practical implementation of a comprehensive solution for streamlined device management and seamless microservice updates, showcasing the potential of open-source technologies in optimizing fleet operations.
• Automatic integration of data monitoring using contextual data from the manufacturing execution system (MES) is achieved, enabling real-time proactive maintenance actions to be suggested, which demonstrates the potential for leveraging integrated data sources to drive efficient and proactive maintenance strategies in industrial settings.
• The combination of anomaly detection and GFTs enables the development of features that are monotonic, which can describe the degradation process better than raw sensor data. Furthermore, the GFT training process based on maintenance costs allows for a better balance of proactive and corrective maintenance actions than can be achieved with traditional predictive models.

Figure 1. Schematic of an IMM and its components [15].

Figure 1. Schematic of an IMM and its components [15].

The remainder of this document is organized as follows: Section 2 presents a literature review on related topics; Section 3 presents the practical use case at OLI; Section 4 provides the details of the proposed architecture for PdM on injection molds; Section 5 describes the subsequent deployment of the predictive models; the results and discussion are presented in Section 6; finally, Section 7 concludes the work.

2. Literature Review

Using sensor data to deploy proactive maintenance strategies in a real industrial environment requires research on different concepts and methods. These are presented here as follows: Section 2.1 shows the status of maintenance solutions on IMMs and their components; Section 2.2 presents the reliability method of fault tree analysis (FTA) and introduces the basic concepts of the GFT methodology exploited in this work; finally, Section 2.3 discusses different perspectives on architectures when deploying predictive models in an industrial environment.

2.1. Maintenance of IMMs and Their Components

IMMs are widely used assets for which maintenance is challenging due to the high number of parameters and components involved in the injection process. Research has been carried out on ways to improve maintenance actions for IMMs and their components, particularly by exploiting process parameters monitored by sensors. In [16], the authors used the maximum entropy principle [17] together with a fuzzy technique to deal with only censored data uncertainty while incorporating the knowledge of the maintenance staff to reduce annual maintenance costs of IMMs. On the other hand, [18] used a copulas model that considered the dependence of different failure modes to optimize maintenance actions on an IMM.

In [19], the authors presented an interesting work in which a statistical method based on kernel density was mixed with outlier detection for PdM in the case of the hydraulic pump of an IMM. Although an interesting path, the proposed approach is in an embryonic stage and lacks results. The process parameters of injection were analyzed by [20], who adopted the Nelson Rules [21] to detect abnormal patterns in the injection process. Other authors have exploited machine learning (ML) techniques to handle IMM maintenance. For instance, [22] employed several data mining techniques to forecast machine-related disruptions on IMMs, while [23] employed reinforcement learning for real-time production planning and scheduling in smart manufacturing of injection molding thermoplastics. The authors of [2] exploited ML classification algorithms to distinguish between optimal and borderline functioning of IMMs in order to trigger maintenance actions when borderline functioning is detected. Other research has focused on creating the necessary apparatus to monitor and collect relevant data for further analysis [24,25], which is the basis for applying maintenance actions based on the actual condition of the equipment.

One of the main fields within PdM is prognostics, in which the main focus is determining the number of working cycles a given industrial asset can perform before its failure [7]. One of the main challenges in such approaches is the fact that the sensor data often present stochastic patterns that do not allow for determination of the asset’s degradation [26]. As is apparent from this overview of maintenance solutions for IMMs and their components, the majority of research has focused on classifying the working state of the assets or detecting anomalous behaviors, as there are no monotonic sensor signals able to describe the degradation process. In the present work, new features are created through the combination of anomaly detection and GFTs, enabling degradation assessment of injection molds by determining their failure probability. This contributes to the field of prognostics more broadly, as the same approach may be employed in other industrial use cases where the degradation of assets follows a stochastic distribution of abnormal events.

2.2. Fault Trees (FTs) and Generalized Fault Trees (GFTs)

Reliability analysis is concerned with the failure probability of a given system or part. It relies on statistical data from relevant parameters of a given process. One of the most widely used reliability methodologies is FTA [27], which is exploited by well-known entities such as NASA [28].

FTA graphically represents a failure event, designated as the top event (TE) using a fault tree (FT). An example of a generic FT is depicted in Figure 2. This structure has two main components, namely, the basic events (BEs) and the gates or operators. BEs are the root factors responsible for causing a given TE, while gates are logic operators ($AND$ and $OR$) that compute the probability of the TE based on the probability of the BEs according to $AND(F_X,F_Y)=F_X{F}_Y$ and $OR(F_X,F_Y)=F_X+F_Y-F_X{F}_Y$, where X and Y are two BEs and $F_X$ and $F_Y$ are the respective cumulative density functions (CDF) of X and Y. Note that the $AND$ gate triggers when both of the input BEs have occurred, while the $OR$ gate triggers when at least one of the input BEs has occurred. In addition to quantitative analysis enabled by the calculation of TE probability, FTA allows for qualitative analysis of the minimal cut sets (MCS), which are the sets containing the minimum number of BEs to ensure the occurrence of a TE [29] (for example, the minimal cut sets for the FT shown in Figure 2 are $C1=\left\{BE1\right\}$ and $C2=\{BE2,BE3\}$).

There have been several approaches for quantitative analysis of FT proposed in the literature, such as state-space models [30,31,32], simulation methods [29,33,34], algebraic approaches [35,36], and commercial software tools and model checkers such as Galileo [37], Coral [38], DFTCalc [39], and Storm [40], among others [41]. Although research effort that has been dedicated to FTA, the methodology does have a number of issues [42,43]. Typically, the TE represents the failure of a complex system, while BEs represent the failure of parts or components within the main system. This has two limitations: (1) expert knowledge is necessary to build the FT structure according to the possible failure modes of the components, which may be tedious and expensive; and (2) the probability of BEs, which is the failure probability of a given part or component, does not accord with the actual state of degradation of these components, as its calculation is only based on the hazard rate calculated from historical data on the malfunctioning of these components.

To overcome the aforementioned issues, the GFT methodology was proposed in [42]. Contrary to FTA, the GFT methodology does not rely on previous expert knowledge of the system, as the BEs are generated automatically from data; in addition, the tree structure that best describes a given TE is automatically obtained through a training procedure. The definition of BEs from continuous data can be achieved by discretizing the data, using cutting-edge parameters [42,43], or using an anomaly detection technique to detect abnormal events which are then used as BEs in the GFT analysis [13]. With respect to the training process, it can be used to either minimize the error between the CDF obtained by the GFT and the real CDF of the TE for a given dataset, or to optimize the maintenance costs.

2.3. Architectural Perspective

Approaches for developing and deploying predictive models in real scenarios have changed over time. The first were centralized, and relied mainly on the computational power of the cloud [44]. With the increasing number of assets being monitored and the high volumes of generated data, these approaches evolved into decentralized and modular solutions, exploiting the capabilities of edge devices to reduce the network latency and the storage requirements of the cloud [45]. For example, in [46], the authors preprocessed data and ran ML algorithms on edge devices, integrating these features within a modular platform with computational cloud capabilities. In [34,47], the authors exploited the computational capabilities of edge devices to run complex algorithms for fault detection, while in [48] the authors used edge computing for anomaly detection.

In addition to the edge layer, architectures may use a fog layer, which is an intermediate layer between edge devices and the cloud that enables cloud services such as data storage near the shop floor. In [49], the edge layer was used mainly for data collection, data transmission, and low-complexity analytics, while the fog layer was used to run more complex analytics and then send the processed and aggregated data to the cloud. In [11] and [50], the authors explored cloud capabilities to train complex models and push them as Docker microservices to the edge devices through a fog network.

In addition to recent architectures for PdM, there is a trend of exploring the capabilities of edge devices [12] for either data collection and extracting field-level data from legacy built-in sensors [51], or for preprocessing the data to run more complex algorithms. Because data produced in industrial environments are noisy and typically collected at a high rate, sending raw data to the cloud requires high network and storage capabilities; thus, carrying out preprocessing locally on edge devices can alleviate the burden on the network, as only relevant data need to be transmitted.

One aspect that should be accounted for when developing an architecture for PdM is the flexibility to customize several services, as production requirements and an enterprise’s needs may change over time; therefore, the applications running on edge devices may have to be adapted according to new requirements. Using containerization approaches, as proposed in [11,50], is one path that might be followed to achieve flexibility and customization. However, a suitable management platform is required in order to easily customize and deploy services on edge devices on a large scale, and should support different types of devices, allow remote updates, enable the addition or removal of devices, be able to manage permissions, and have a graphical interface that allows for easy used by maintenance practitioners and stakeholders.

In this work, we propose an architecture that exploits the capabilities of edge devices by deploying microservices built as Docker containers. These services can preprocess data, run predictive models near the shop floor where the data are produced, and retrofit industrial settings with additional sensors. We exploited the OpenBalena [14] open-source platform to manage fleets of edge devices deployed on a large scale in a real manufacturing environment at OLI. This platform supports different types of devices, allowing their management by enabling services to be remotely updated securely, managing permissions, and removing or adding devices, among other functionalities described in the remainder of this document. Furthermore, a graphical interface allows for easy use of the platform.

To the best of our knowledge, this work represents the first time the open-source OpenBanela platform has been used in a real industrial environment. Together with containerized services, the use of this platform has the benefits of portability, high scalability, and ease of deployment of predictive maintenance services, while providing a secure framework to manage all edge devices across the shop floor. The proposed solution is in accordance with Bosch’s white paper [12], which highlights the requirements that an architecture based on edge devices should accomplish; next, we demonstrate its features in an industrial use case at OLI.

3. Use Case

The injection molding process is known for its high productivity rate; however, as the number of working cycles increases, the degradation of the IMM and its components tends to increase as well. In this work, we studied a practical use case at the facilities of OLI, a company known for its expertise in the production of injected thermoplastic parts, in Aveiro, Portugal. One of the most relevant maintenance issues of the enterprise is related to production stops due to mechanical failures of injection molds. When these problems occur, the mold must be repaired, as it is an expensive component with no spares.

It is important to note that proactive actions have a cost, in that technicians that need to inspect the IMM and decide on the actions to be taken. Possible mechanical failures of molds differ in severity; there are failures that are easily solved with quick corrective actions as well as others that imply long unavailability times and expensive repairs. With this consideration, and taking into account that CM is the only strategy currently applied by this enterprise, the objective of our work was to reduce the unavailability of injection molds due to mechanical failure and consequently reduce the costs of maintenance, which we sought to achieve both through proactive maintenance and by selecting the correct maintenance strategy in each case, i.e., failures that can be easily repaired do not justify proactive maintenance, while more severe ones can be mitigated.

The enterprise has several IMMs equipped with built-in sensors to monitor the injection process, following the standards of EUROMAP 63 [52], which is a protocol used in the plastics industry for data exchange between IMMs and peripheral devices. These sensors collect a total of 123 parameters; however, only a few of these present any abnormal behavior in the periods between mold failures according to the experts and engineers at the enterprise that monitors the data. For this reason, only ten signals were considered for analysis in this work, represented in

Table 1. IMM sensor descriptions.

EUROMAP Parameter	Description	Unit
ActStrCsh [1]	Injection completion position	mm
ActPrsXfrSpec [1]	Pressure at the time of injection with 1st pressure	MPa
ActStrXfr [1]	Transfer stroke actual for each injection unit.	mm
ActTimCyc	Cycle time	s
ActTimFill [1]	Time spent for 1st injection	s
ActTimPlst [1][1]	Time spent for plasticizing	s
ActPrsXfrSpec [1]	Pressure at the time of injection with 1st pressure	MPa
ActVolPlst [1]	Actual plasticization volume for each injection unit	mm${}^3$
@ActFrcClp_PstInj [1]	Clamping force at injection completion	MPa
ActTmpBrlZn [1;1]	Measured heater 1 temperature	${}^{\circ }$C

. Although the majority of IMMs are monitored by sensors, tracking the degradation patterns of injection molds is not straightforward, as they are used in different IMMs, requiring analysis of a given mold to account for working cycles involving different IMMs. Furthermore, each mold may have different working settings, such as temperature, pressure, and cycle time, because the produced parts may be made from different thermoplastic materials. Additionally, each mold may have multiple cavities, allowing for production of parts with different geometries, and they may produce identical parts in each cavity or unique part with different geometries. All of these factors make the forecasting of mechanical failures in molds a challenging task.

4. Proposed Architecture

The proposed architecture comprises edge and cloud capabilities built on flexible Docker microservices, as shown in Figure 3. The edge devices use the Balena operating system (OS), which is a lightweight Linux-based OS specially developed to run on low-powered edge devices, while the cloud layer is composed of the OpenBalena [14] microservices platform, which allows for remote management of the edge devices and for microservices to enable features such as data hubs, storage, and dashboards.

The OLI shop floor comprises several IMMs, each of which is equipped with an edge device that executes the following tasks:

• Data Collection: Data are collected from each IMM according to the EUROMAP63 protocol [52]. Each device receives 123 parameters from the injection process at a sampling rate of 1Hz.
• Preprocessing Rules: Of the 123 process variables, most are not considered in our analysis as they do not have variance over time, while others are not considered based on insights provided by the enterprise’s technicians and engineers, mostly because these variables do not present abnormal values between mold failures. In addition to sensor selection, the aggregation of data in time windows and the creation of additional features are performed on edge devices. Note that these rules are easily configurable, allowing customization of the pipeline.
• Intermediate Storage: The edge devices in this use case are Raspberry Pi 4 boards with storage capacity, allowing temporary storage of raw data for preprocessing, aggregation, and enrichment before being sent to a central broker.
• Data Flow: The aggregated and processed data are sent to a topic in the mosquitto broker on the cloud, where consumer applications can use the data stored in the cloud for several purposes. Because only preprocessed data are sent, the volume of generated data is reduced compared to the raw data.
• Prediction: The edge devices run predictive models such as GFT and anomaly detection. These models are trained on the cloud and pushed to the edge devices using the OpenBalena microservices running on the cloud. When an impending failure or abnormal behavior is detected, the edge devices can trigger alerts and send them to operators and maintenance teams.

The fact that the mentioned services are built using Docker containers enables several features; isolation at the application level makes it easier for microservices to be managed and updated without affecting others; flexibility and portability mean that microservices can be deployed across different infrastructures that support Docker and be easily customized for other use cases; and ease of deployment is achieved thanks to the fact that all applications and dependencies are packed in the same container, making them less dependent on the particular device on which they are running.

Management of the devices relies on the OpenBalena platform installed on the cloud, which is an open-source platform for managing and deploying fleets of devices running the Balena OS. It is composed of several microservices, with the registry and API being the most important ones. The registry is a central repository used to store and manage Docker images that are used to deploy applications to the devices, while the API provides endpoints for authentication and authorization of requests made to the platform. These requests allow the management of all the devices, allowing the following features:

• Fleet and device management, enabling the creation of new fleets and devices within the network and the allocation of devices in different fleets.
• Secure communication between edge devices and the platform by providing a range of security and access control features, including user authentication, permission management, data encryption, and secure communication protocols.
• Monitoring of device and application performance, tracking the system logs, and generating reports on fleet health and usage.
• Flexibility in deploying and updating the microservices running on edge devices, allowing them to be customized and/or updated remotely.

Hacking and unauthorized access are among of the main concerns when developing applications based on wireless communication; consequently, research has specifically focused on these issues [53]. With respect to this work, there are several mechanisms to ensure privacy and security when developing and deploying services:

• OpenBalena is deployed locally, ensuring that sensitive data remain within the company’s network and reducing the risk of unauthorized access.
• OpenBalena uses secure communication protocols such as hypertext transfer protocol (HTTP) over secure socket layer and transport layer security (SSL/TLS) between the server and edge devices or clients, ensuring that the data transmitted through the network remain confidential and protected.
• There are access control mechanisms to manage user permissions and restrict access to sensitive features and data, which allow the roles and permissions required to access services and devices to be defined.
• Authorization and authentication mechanisms, namely, API credentials and authorization tokens for users and devices to access the OpenBalena server, ensure that only authorized individuals can interact with the system.

In addition to the OpenBalena platform, the cloud comprises other services, including a central mosquitto broker where data from the edge devices are sent to be consumed by the services on the cloud as well as a time-series database to store the collected data. For this purpose, the influxDB database is used in this work; however, this service may be customized according to different use cases. The analytics engine is responsible for fusing the sensor data collected from the shop floor with contextual data from the enterprise’s MES in order to label the data, i.e., to generate a new column of data. This column contains ‘0’ when the injection mold is working correctly, ‘1’ when there is a mold mechanical failure, or a code error when there are other malfunctions in the IMM. Because the data patterns may change over time, this feature is important, as it enables the predictive models to be retrained from time to time.

Predictive Analytics

The main goal of the proposed architecture is the deployment of scalable and flexible services near the shop floor to enable proactive maintenance actions based on the condition of the injection molds. The architecture of the analytics services reported in Figure 4 shows the services exploited in the use case of this research; however, the pipeline and services may be customized according to other industrial use cases of interest, as they have the flexibility to be adapted to different requirements.

Real-time data from the IMM sensors are collected through the data flow microservice running on the edge devices; these data are temporarily stored in a local database. When enough data accumulate to aggregate the raw data in a 5-min time window, the data are aggregated by the preprocessing microservice using the maximum (max), minimum (min), mean, and standard deviation (std) functions as aggregation primitives, then the data are enriched with new features by calculating the difference (diff) between consecutive time windows of the same variable. These data are encoded to build a message in the JSON format, which is forwarded to a central broker for distribution to other services on the cloud. Note that in addition to collecting the built-in sensor data, the edge devices allow retrofitting of IMMs with new sensors. For example, the bme280, which is a digital sensor for measuring temperature, humidity, and barometric pressure, was used to monitor the plastic pallets on the feed hopper. The addition of such sensor data was requested by the company’s stakeholders, as these parameters may be useful to develop additional analytics services for product quality assessment.

The analytics services on the cloud fuse the incoming shop floor data with contextual data from the enterprise’s MES in order to build datasets for training the anomaly detection and GFT models, which are then stored and pushed to the devices. Because the same device collects data from different injection molds and the working condition settings are different for each one, it is necessary to have a different model for each mold; thus, each time a mold is replaced, a topic in the central broker is updated using the reference of the mold being used in each machine, which is consumed by the edge devices immediately before a prediction is made in order to identify which models should be used to estimate the failure probability of the mold in use. The training process of the GFT is based on the optimization of costs with respect to maintenance, as described in the following section; thus, when these costs increase by a given percentage, it means that the predictive accuracy of the models may be deteriorating. When this occurs, the models need to be trained again on the cloud with the new data, then pushed to the edge devices. The training process can be scheduled to occur at equally spaced intervals of time, for example, on a monthly basis.

5. GFTs and Anomaly Detection for PdM

The GFT approach estimates the probability of a given TE, which in the case of this work is the mechanical failure of an injection mold, from the probability of given BEs obtained from data. In [42], the authors proposed a method based on cutting-edge parameters to discretize the continuous sensor data into five classes based on their distributions. The same approach was explored by [43]. However, in this work, as in [13], an anomaly detection technique is used to define the BEs. The following subsections provide details of the GFT and anomaly detection approaches.

5.1. Definition and Calculation of BEs

Typically, the signs of malfunctions in industrial assets are manifested by abnormally high or low values of the sensors monitoring the relevant process parameters [42,43]. Using the edge parameters to discretize the data and define BEs leads to the result that each variable generates five different BEs, increasing the complexity in training the GFT model. However, these abnormal behaviors can be well captured by anomaly detection techniques. In this approach, the BEs represent the anomalous datapoints for each variable detected through anomaly detection. The method used for anomaly detection is the well-known isolation forest (IF) method, which was deployed using the Sklearn Python library. This technique identifies abnormal or unusual data points in a dataset by randomly partitioning the datapoints into a set of binary trees. To identify an anomaly, the algorithm creates a decision tree for each datapoint by randomly splitting the features and thresholds. It then counts the number of splits required to isolate the datapoint from the rest of the dataset. Anomalies are isolated closer to the tree’s root [54], as they require fewer splits to be separated. An important parameter for this algorithm is the contamination ratio, which is the proportion of abnormal values in the training dataset. In this work, the contamination ratio was determined following [54], and the model was trained using 80% of the dataset as training data.

This method was employed because it isolates anomalies instead of profiling the normal behavior of data. There are different configuration settings in the IMM use case (temperatures, pressures, cycle time, etc.) because different parts are produced, and the working parameters may change for a given mold, as it may produce parts from different materials. Thus, there is no unique normal behavior model, i.e., the sensor values that are normal for a given setup may be anomalous in another. For this reason, isolating anomalous points is a better approach for detecting abnormal behaviors in this case than outlier detection techniques or using cutting-edge parameters to discretize data.

The distribution of the BEs is calculated by considering the time elapsed from the last mechanical failure until the BE occurred for a given mold, as illustrated by Figure 5. The elapsed time only accounts for working time, as the inactive periods (when the IMM is not producing) are previously removed by the preprocessing microservice on the edge device. Note that when there are other malfunctions, such as a mechanical failure of the IMM, data anomalies are expected to occur; however, such cases are generally related to IMM degradation, not mold degradation. When there are malfunctions that are not related to mold degradation, the occurrence of BEs is not accounted for. The CDF of each variable can be obtained with a discretization step h of five minutes, which is the time window used to aggregate the data. From the CDF of each BE, the probability of BEs can be calculated and updated according to its occurrence, i.e., at a given time after the last repair, the probability of a given BE is the value of the CDF curve for that elapsed time. If the event has already occurred, its probability is updated to the maximum value calculated from the training distribution.

Note that injection molds may work in different IMMs; thus, each time there is a mold change, the number of working cycles performed by the mold and the cumulative probability of each BE is encoded into a JSON message and sent to the central broker to be stored in the cloud, as depicted by Figure 6. In each replacement, the set containing the historical data on BEs occurring in each mold is pushed to the edge devices, thereby accounting for the degradation caused by previous working cycles on different machines.

5.2. Cost-Based GFT Training

The output of a GFT is the probability p of the TE, and the training process consists of finding the GFT structure that minimizes the costs of maintenance. The maintenance approach considering the GFT output consists of proactively performing maintenance interventions when the failure probability p reaches a given threshold $p_t$. At this time, the cost of the next corrective maintenance action is replaced by the cost of a proactive intervention. During the training phase, each tree is evaluated considering the percentage of the mold’s unavailable time achieved with each tree. This metric is defined by Equation (1), where $N_i$ is the number of interventions performed during the considered period, $u{t}_i$ is the unavailable time caused by each intervention, and $w{t}_i$ is the working time of the machine from the mold’s last maintenance intervention $i-1$ until intervention i. Note that the optimal $p_t$ for each tree is determined iteratively by varying this parameter from 0.50 to 1.00 in intervals of 0.01. A low value of $p_t$ may avoid more failures; however, this means that fewer working cycles are performed, which may increase the cost due to the molds’ lifetime under exploitation.

$$Cost=\sum _{i=0}^{N_i}\frac{u{t}_i}{w{t}_i+u{t}_i}.$$

(1)

Because the training dataset contains only corrective maintenance interventions, the time during which the mold is unavailable can be determined for each failure using the contextual data of the enterprise’s MES. However, these data lack information concerning the different mechanical failures that may occur, making it hard to estimate the reduction in unavailable time achieved by changing a corrective action to a proactive one in a given case. Because the time spent on corrective interventions has a wide range of possible values, as discussed in the next section, it is reasonable to assume that the benefit of performing a proactive action instead of a corrective one is irrelevant when the latter takes only a short time to perform, or that it may even increase unavailability of the mold due to proactive revisions and maintenance actions taking longer than a simple and short corrective measure. Considering these aspects, we consider that $u{t}_i$ for a proactive action assumes a constant value, which is the median of $ut$ for all corrective actions. Note that in the future this training rule may be customized according to different scenarios and the respective interests of different enterprises.

The model training process is an iterative one in which trees are generated, starting with less complex ones with fewer BEs before proceeding to more complex ones. As shown in Figure 7, the process starts by calculating all possible trees containing two BEs. From there, the process continues by using the output of simpler trees to build more complex ones. For example, a tree with four BEs can be calculated using a gate/operator that has a tree with three BEs and a single BE as inputs, or using two trees with two BEs each. These trees are saved during the process in order to speed up calculation. The training process stops when the best solution containing K BEs does not represent an improvement of more than 3% compared to the best solution containing $K-1$ BEs.

The time complexity of the GFT training process is $O\left(n^{2}lg\left(m\right)N\right)$, where m is the number of BEs in the tree, n is the number of columns, i.e., the total number of BEs that may be used during the training process, and N is the number of instances in the training set. The failure probability estimated by the GFT is obtained by an algebraic expression; thus, its prediction complexity is O (1), making prediction very lightweight and suitable for running on edge devices. Note that the training process is not exhaustive, as a dynamic pruning technique is used; i.e., for a tree with K BEs, only the trees that contain all the BEs of the best tree with $K-1$ BEs are considered, as stated in [13,43], reducing state space explosion.

6. Results and Discussion

The methodology described in the previous section was deployed on OLI’s shop floor. In this section, we present the results obtained for analysis of the mold that showed the highest number of mechanical failures over a period of one month. Figure 8 depicts the prototype of the data acquisition system in a real industrial environment, Figure 8a shows a Raspberry Pi 4 board inside an electric cabinet near the IMM, and Figure 9 depicts the implementation of the bme280 sensor on the feed hopper to monitor parameters such as temperature and humidity. The sensor is wired-connected to the Raspberry Pi 4 board, which collects data through the I2C protocol. Finally, Figure 8c shows the interface used to monitor the variables obtained from the IMM’s built-in sensors, obtained through the EUROMAP63 protocol.

Data from the built-in sensors are preprocessed on the edge devices, and only aggregated and relevant data are sent to the cloud, which represents a colossal storage savings. For example, for a period of one month the raw data for the studied mold require 976.16 MB of disc space, while the preprocessed data only require 1.93 MB; this represents less than 0.2% of the initial storage requirements. This is relevant when considering the burden on the network, as data must be sent to the central broker within a period of five minutes, which is the aggregation time window, instead of sending it at 1 Hz rate, which is the sampling rate. Note that because the energy consumption of edge devices is very low when compared to the IMMs, this parameter was not studied exhaustively; however, in cases where the energy of low-power devices is relevant, its optimization should be accounted for [55].

The data from the retrofitting sensors were not used to assess the health state of injection molds; however, collecting these data was a requirement of the enterprise, as in addition to the optimization of maintenance actions with molds, improving of the quality of injected parts is crucial for the success of the company. Thus, monitoring parameters such as humidity and temperature inside the feed hopper are important indicators to assess the quality of the final product. New parameters may be calculated From the temperature and humidity as well; for example, the dew point (the temperature at which air becomes saturated with water vapor, leading to the formation of dew) can be calculated using Equation (2), where T is the temperature in Celsius degrees, H is the humidity in percentage, and a and b are constants, with $a=17.62$ and $b=243.12$. Figure 9a,b shows the humidity and the dew point, respectively, inside the feed hopper for a given period, which shows the ability of the proposed architecture to be used for several purposes and its flexibility to adapt to new requirements of the enterprise.

$$DP=\frac{b\times T}{c+T}+log\left(H\right)$$

(2)

The management of edge devices is carried out through a dashboard which communicates with the openBalena platform API. Figure 10 shows the dashboard, which is an open-source project [56]. It allows end users such as technicians and engineers at the enterprise to easily manage API keys and access to the platform, manage device health, and monitor their logs and microservices. Note that all the platforms and dashboards are self-installed in order to allow greater flexibility and control over all the applications.

Assessing the degradation of industrial assets from data obtained in a real industrial environment is a challenge, as unexpected events may occur, such as malfunctions from several origins, production stops due to production changes, and planned interventions, among others. Several approaches for PdM try to forecast the degradation of industrial assets by determining how many working cycles they can perform until a failure occurs. Such approaches achieve very good results when the sensor signals have an almost monotonic trend that describes the asset’s degradation, which is often the case when using data from simulation models, such as the ones in [57]. However, real data sensor signals typically do not follow a monotonic trend, while the component’s degradation increases. Instead, there are abnormal data points stochastically distributed over time, and their cumulative occurrence may describe the degradation process.

Figure 11a shows the maximum time for the first injection (the time that it takes to fill 95–99% of the mold) in each 5 min time window aggregation. The data were collected in the period between two mold malfunctions, with the first point collected just after the mold was repaired and started working again and the last point representing the moment when another mold failure occurred. As can be seen, the sensor values do not follow a monotonic trend. Instead, there are data points that clearly differ from the remaining ones. Furthermore, the failure occurs a considerable time after the last spike occurred, which makes it challenging to determine the exact moment when a failure may occur. Figure 11b shows the CDF curve of a BE that results from anomaly detection for this variable within the same period. While the sensor’s signal follows a stochastic trend of abnormal events, the CDF curve of the BE obtained from it has an increasing monotonic trend that describes the mold’s degradation much better. Note that the anomalies detected when there are other planned events, such as a setup change, are not accounted for, as they are not expected to cause degradation of the mold. While we present only the example of the first injection time in Figure 11a, the remaining variables show similar stochastic behavior.

After sensor selection, a total of ten variables regarding the mold’s operation were selected. After the aggregation process and data enrichment, a total of 80 different BEs were generated from the initial variables. The GFT approach was used with all these variables to build the tree that best described the mold’s mechanical failures. Note that all 123 initial variables are available for consideration, as the approach is not dependent on expert knowledge; however, if such knowledge is available, as it was in the case under study, it can be exploited to speed up the training process.

The GFT structure obtained from the training process is represented in Figure 12, and the description of BEs is presented in

Table 2. Description of BEs.

BE	Description
E_1	The difference in the standard deviation of the cycle time between consecutive time windows is anomalous.
E_2	The difference in the mean stroke position at cushion for each injection unit between consecutive time windows is anomalous.
E_3	The mean stroke position at cushion for each injection unit is anomalous.
E_4	The difference in the maximum injection start position between consecutive time windows is anomalous.
E_5	The difference in the mean cycle time between consecutive time windows is anomalous.
E_6	The difference in the max stroke position at cushion for each injection unit between consecutive time windows is anomalous.

. An issue that often hinders the implementation of PdM is the fact that complex ML or deep learning (DL) methods are seen by maintenance practitioners as “black boxes” [58]. One of the main features of GFT models is that their graphical representation is easily interpretable by humans, as it is possible to perform a qualitative analysis of the failure modes from the tree structure by determining and analyzing the MCS. In the concrete case of the considered injection mold, the following four MCS were obtained:

• $C_1=\{E\_1,E\_3,E\_4\}$,
• $C_2=\{E\_1,E\_3,E\_5,E\_6\}$,
• $C_3=\{E\_2,E\_3,E\_4\}$,
• $C_4=\{E\_2,E\_3,E\_5,E\_6\}$.

From this, it can be concluded that parameters such as the position at cushion (for each injection unit), the cycle time, and the injection start position are the most relevant process parameters when inferring the mechanical failure of this mold, as the BEs on the GFT skeleton are obtained from these variables. Furthermore, the position at cushion is the most relevant parameter, as $E_3$ is present in all the MCS.

At the date of implementation of the proposed approach the company only adopted CM actions, and information about the failure modes and actions that were performed to overcome a given failure was not maintained in the enterprise’s MES. For this reason, the cost of a proactive action was set as the median of the unavailability time of the mold with the current CM policy (247.5 min) within one month, which, when discussed with experts at OLI, was considered a conservative approach for the upper bound of the time that would be needed for a proactive action. The cost set for proactive actions influences the GFT structure obtained during the training phase. When minimizing the mold’s unavailability, estimating high probabilities of failure when this failure causes low unavailability is not interesting; thus, it is to be expected that different failure modes may have different importance when building the GFT skeleton. This is especially interesting for use cases in which a mix of proactive and corrective actions may be the best maintenance policy.

Table 3. Results for different maintenance strategies.

Failure Number	${\mathit{wt}}_{\mathit{i}}$ CM (min)	Unavailable Time (CM) (min)	${\mathit{wt}}_{\mathit{i}}$ PM (min)	Unavailable Time (PM) (min)	${\mathit{wt}}_{\mathit{i}}$ GFT (min)	Unavailable Time (GFT) (min)
1	2485	315	-	315	2155	247.5
2	140	35	-	35	-	35
3	300	180	-	180	-	180
4	55	585	-	585	5	247.5
5	2895	5	-	5	-	5
6	1890	390	-	390	-	390
7	850	725	-	725	680	247.5
8	3030	3915	3025	247.5	2945	247.5
9	2955	35	-	35	-	35
10	170	95	-	95	-	95

presents an overview of the mechanical failures of the considered mold. As can be seen from Figure 13, the working time of the mold before a failure ranges from 55 to 3030 min, while the unavailable time due to repairs has similar behavior, ranging from 5 to 3915 min. Two things may be concluded from this: it is difficult to estimate equally spaced intervals of time for proactive actions, as mechanical failures of molds do not follow temporal patterns; and proactive actions may not be the best approach for all types of failure, as, for example, failures 2, 9, 10, and especially 5 took very little time to solve. Because these malfunctions are easily repaired, proactive actions are unnecessary. The fourth column of the table presents the scenario that would occur with the PM strategy in optimized equally spaced intervals of time. Because it only accounts for the working time, the majority of mechanical failures of the mold would not be avoided; however, this policy avoids the failure that caused the most impact in terms of unavailability of the mold, which would represent savings of 49.86% compared to the CM policy. When using the obtained GFT to optimize maintenance actions, it can be seen that the four major failures are avoided (the penultimate column of Table 3). In fact, the only failures that are not avoided are the ones where the unavailable time is lower than the estimated time needed for a proactive action (247.5 min). The fact that the GFT accounts for the actual state of the mold as provided by the BE probability allows for a cost reduction of 27.05% compared to the optimized PM strategy, and a reduction of as much as 63.43% compared to the CM strategy.

The GFT results show that mold failures can be distinguished from the sensor data according to their severity, as the GFT model is able to suggest proactive maintenance actions only when justified by the predicted failure’s severity. In cases where the unavailability caused by the malfunction would be short, the failure probability does not reach the threshold value $p_t$ required to suggest a proactive action. In this way, the model balances proactive and corrective actions using only the knowledge obtained from sensor signals and information on the duration of unavailability caused by each failure.

7. Conclusions

This work presents a modular architecture that exploits edge and cloud capabilities to deploy analytics techniques on the shop floor near industrial assets. Services running on edge devices were developed using a Docker containerization approach to perform tasks such as data collection, sensor selection, data flow, data preprocessing, and suggested maintenance based on the predictive models running on each edge device. The cloud allows services such as data storage, integration of sensor data with contextual data from the company’s MES, and dashboards for data visualization and management of edge devices.

The studied use case at OLI in Aveiro, Portugal shows the advantages of the proposed architecture, primarily in terms of being customizable and flexible, achieving all the features highlighted in [12] that an architecture based on edge computing should encompass. The edge devices can be remotely updated through the graphical interface and the services are container-based, allowing the architecture to be adjusted to new requirements. For example, in this work it was necessary to add new sensors to monitor humidity and temperature inside the feed hopper. In the future, new functionalities, such as analytics for quality assessment of injected parts or collecting new sensor data, could be added to the system without disrupting its current functionalities.

Distributing data preprocessing over edge devices allows for a reduction of storage space, as only useful data are sent to the cloud. The results show that the processed and aggregated data require only 0.2% of the storage space required by the raw data. This alleviates network burden, as the data are sent in intervals of five minutes (the aggregation time window) instead of being sent with the 1Hz sampling rate. Furthermore, because each mold may work on different IMMs, using a distributed approach allows for customization of different predictive models for each injection mold. Exploitation of anomaly detection with GFTs balances proactive and corrective actions in such a way that, when considering a maintenance strategy based on GFT suggestions, estimated reductions of 27.05% and 63.43% were achieved compared with the optimized PM and CM strategies, respectively. Furthermore, the combination of anomaly detection and GFTs enables the creation of monotonic features from raw data containing abnormal values distributed stochastically, which enables the degradation assessment of industrial assets that would be impossible with only raw sensor data.

Our future work will focus on exploiting the proposed architecture to solve other data-related issues in other industrial scenarios. In the concrete case of IMMs, with sufficient data from the retrofitting sensors inside the feed hopper a study could be conducted analyzing the impact of the monitored parameters on the quality of the injected parts, which could allow development of other models to assess the quality of these parts. The presented architecture allows new services to be added to edge devices without interfering with those already running, which makes it easy to build new functionalities on top of existing ones. On the other hand, existing services may be exploited in different scenarios and use cases through small adaptations to the models and algorithms, which are easily customizable.