Keywords

1 Introduction

The increasing capabilities of data collection mechanisms have evolved new intelligent solutions for decision-making. The burgeoning advancement in Machine Learning (ML) algorithms have yielded a tangible impact on decision-making techniques. In addition, adapting efficient management systems for maintenance work can decrease the unpredicted costs during equipment failures and shutdown periods.

Indeed, industrial equipment failure can be costly or even endanger personal safety. Therefore, moving from simple schedule-based maintenance to smart sensor-based predictive maintenance systems has become increasingly popular. However, these systems are not simple, and there are several approaches to them, including those based on expert knowledge and those based on machine learning. We propose a conceptual architecture that combines these using known solutions (patterns) from the field of software engineering. The proposed architecture is based on a real-world, but anonymous industry implementation of predictive maintenance, but the approach, observations and discussions presented here are of general interest for anyone designing practical predictive maintenance systems.

The remainder of this paper is organized as follows. In Sect. 2, we present an overview of the related work about predictive maintenance models. In the next Sect. 3, we discuss the methodological contribution of our work compared to the related work and their practical applications in real-life scenarios. Next, in Sect. 3.1, we briefly present the Matrix Profile Method for Predictive Maintenance and discuss its application from the perspective of our case study. The penultimate section describes the conceptual pattern-based architecture for predictive maintenance using UML class diagrams. Finally, the conclusion and issues of future works are stated in Sect. 5.

2 Related Work

Hashemian [6] identifies eight applications of equipment condition monitoring: process optimization, personal safety, equipment health, emission monitoring, process diagnostics, equipment performance, leak detection and calibration verification. Predictive maintenance has been a field of active study [3, 5, 9].

In their literature review on predictive maintenance, Ran et al. [14] state the cruciality of maintenance in the industry, damage of unplanned downtime, and the capability of emerging technologies to make predictive maintenance widely accessible. They divide the approaches to predictive maintenance into three:

  1. 1.

    Knowledge-based approaches (Ontology-, Model- and Rule-based)

  2. 2.

    Traditional machine learning-based approaches (ANN, DT SVM, kNN)

  3. 3.

    Deep learning-based approaches (AE, CNN, RNN, DBN, GAN, etc.)

For machine learning, we make heavy use of the Matrix Profile method invented by Eamonn Keogh and Abdullah Mueen [16] which we will describe later. Our implementation is built on Python stumpy Matrix Profile library [8].

Our architecture aims to combine the rule-based approach with traditional or deep learning methods. To achieve that, we propose an architecture based on archetype and analysis patterns from software engineering. Analysis patterns were described by M. Fowler [4] as groups of concepts that represent a common construction in business modeling that may span many domains. Business archetype patterns (namely Product, Party, Order, Inventory, Quantity, and Rule), originally introduced by Arlow and Neustadt [2], are the universal information models describing the universe of discourse of businesses [13]. The archetypes and archetype patterns were further explored in the works of Piho et al. [11, 12] as part of Sentry (sample entry) software for CBPG (Clinical and Biomedical Proteomics Group, Leeds Institute of Cancer and Pathology, University of Leeds). Interestingly, the Rule pattern that is fundamental for our architecture is described in these works as covering all the fundamental business requirements - What (Things), How (Processes), Where (Locations), Who (Persons), When (Events), Why (Strategies) - of Zachman Framework [17]. To best of our knowledge the application of these patterns to the field of predictive maintenance has not been explored before. We implemented our prototype system based on this architecture through Grafana observability platformFootnote 1.

3 Matrix Profile Method for Predictive Maintenance

We make heavy use of a Matrix Profile (MP) method in our predictive maintenance system. While our architecture is general and can work with different methods, it is an effective method and an excellent example to explore the issues of time series analysis.

Time series analysis typically looks at anomalies and motifs/patterns. The basic idea of MP is to calculate the distance between pairs of sub-sequences in the time series by computing the distance between each pair. An important parameter for MP is the window size: length of sub-sequences. Despite the simplicity of a naive algorithm based on nested loops, it can take years or months to get an answer for a moderately sized time series using this method. However, using the Matrix Profile algorithms, computation time is significantly reduced. It is a relatively new time series analysis data structure invented by Eamonn Keogh [10] at the University of California Riverside, and Abdullah Mueen at the University of New Mexico [16]. A matrix profile is a vector that stores the z-normalized Euclidean distance between any sub-sequence within a time series and its nearest neighbor. This algorithm is agnostic to domains, fast, supplies an exact solution, and only requires one parameter (window size).

In Fig. 1 we show at the top a synthetic time series from a temperature sensor, which contains two sawtooth patterns and added noise. Temperature is standardized to the mean of zero and standard deviation of one. At the bottom we show the corresponding Matrix Profile values for sub-sequences of the length 640. MP values correspond to distance to nearest (most similar) sub-sequence and therefore low MP values show repeating motifs. As we can see, these identify our two sawtooth patterns. Anomalies can correspondingly be identified by large MP values as shown in Fig. 2.

Fig. 1.
figure 1

Matrix profile motif detection

Full size image
Fig. 2.
figure 2

Matrix profile anomaly detection

Full size image

Multi-dimensional MP [7] generalizes finding motifs and anomalies to multi-dimensional cases. This algorithm [15] requires careful design to minimize the additional time complexity owing to its computational complexity. In addition, although it may be tempting to look for motifs in all available dimensions (i.e., the motif must exist in all dimensions and co-occur), it has been shown that this rarely produces meaningful motifs except in the most contrived of cases [7]. An alternative strategy would be to reduce time-series dimensions to a subset of "useful" dimensions before assigning a sub-sequence as a motif.

3.1 Matrix Profile in Our Case Study

Our goal is to analyze the collected sensor data for failures in the equipment alongside detecting sensor anomalies. In our case study, we analyzed the available sensor data and the correlations, adopted the MP algorithm for detecting anomalies and patterns in time-series data and extracted potential rules about sensor anomalies and device failures.

Our training dataset contained 169, 489 rows \(\times 17\) columns (sensors) collected over seven months. At the moment we have no legal rights to publish actual data from the project.

A Pearson correlation study demonstrated that the sensors’ observations of the same type were highly correlated. As a result of the correlations, measurements from one sensor could be used to represent all the others of the same kind. If one goes down, the data from the other is still sufficient since their behavior is correlated.

MP is a visual method and our prototype supports visual explanations through GrafanaFootnote 2 dashboard. We use both single- and multi dimensional MP. We mention shortly that we have concluded that selecting the window size is crucial for MP. We get fewer motifs whenever we go longer and vice versa. In addition, we notice anomalies at different points in the time series.

4 General Architecture and Patterns

We describe the conceptual pattern-based architecture for predictive maintenance using UML class diagrams. We base this on known analysis patterns [4] and architectural patterns [2].

Fig. 3.
figure 3

Class diagram UML notation [1]

Full size image

4.1 Domain Modeling, UML Class Diagrams and Patterns

First, we introduce the main ideas of domain modeling. The domain is any field that computation can be applied to [11]. Domain (Conceptual) modeling aims to identify, detect and define the concepts from the domain. The latter are usually but not always, mirrored within the computational system. For example, in a healthcare system, we may identify concepts like Patient, Observation, Protocol, etc. [4]. In the field of trading, we can identify concepts like Derivative Contract, Contract, Portfolio, Trading Package, etc. [4]. Potential concepts can be at a higher or lower level of abstraction (Measurement vs. Blood Pressure Measurement) and be more or less relevant for certain goals (Blood Pressure Measurement is not relevant for the goals of Trading but relevant for Healthcare). Models are not right or wrong, but more or less valuable [4]. However, models that describe confusing concepts or are not general enough can make extending, scaling, and changing a system a nightmare. General models used in many different domains and named and described in the literature are called patterns. Patterns are meant to help with describing and proliferating good design practices [4]. They are widely used in software engineering, but with the rapidly increasing complexity of AI systems like predictive maintenance, they should become more relevant.

A visual way to describe domain concepts is through class diagrams of Unified Modeling Language (UML) [1]. Class diagrams can describe either domain concepts or software classes. We provide a short explanation of this notation in Fig. 3.

4.2 Patterns for Predictive Maintenance

A system of predictive maintenance should ideally combine the expert knowledge with the power of AI systems like MP to detect outliers and anomalies. Our aim is common with the field of software engineering: to protect the system from variations arising from changing user requirements.We do not want to change, reprogram and redeploy our system when user tolerance for false positives and false negatives changes, when user decides that certain indicator is not useful anymore etc. Therefore we introduce a rule interpreter that allows user/expert to add, change and delete various alert rules, controlling the behaviour of our system. We also note that these rules could apply to both actual sensor observations and machine learning anomaly/motif estimates derived from those observations. Therefore we generalize both of those into Indicators. Our general split between expert defined rules and various indicators that these rules apply to was present before we made the connection to the patterns from the field of software engineering but this connection has enabled us to clarify and generalize our approach. As it is common with patterns we have modified them to suit the needs of our specific field of predictive maintenance.

4.3 Observation and Indicator Patterns

Observation pattern (Fig. 4) was originally described by M. Fowler as follows [4]:

Fig. 4.
figure 4

Martin Fowler’s Observation pattern [4]

Full size image

Observation observes some actual parameter that is either a quantity or category. Observation can, of course, be mistaken. Here we reproduce only the basic pattern which is described and extended in Fowler’s book [4]. Fowler provides various extensions for the fields of Medicine and Corporate Finance.

For the field of predictive maintenance observations come from the sensors. Experts may want to use them directly in alert rules using their expert knowledge to complement machine learning estimates.

We generalize observations from sensors and Machine Learning estimates into Indicators (Fig. 5) used for predictive maintenance analysis and alerts.Both estimates and observations are indicators.

Fig. 5.
figure 5

Indicator pattern that extends on M. Fowler’s Observation pattern [4].

Full size image

While observation is a qualitative or quantitative statement about some measured phenomenon, an estimate is a qualitative or quantitative statement calculated based on the observations according to some method. For example, a temperature reading from some sensor is an observation, predicted likelihood of component failure is an estimate.

4.4 Time Series Estimates Using Matrix Profile

We make heavy use of Matrix Profile and Multi-Matrix Profile estimates. They have to fit into our system of patterns which they do easily through specialization. Both are time series estimates based on a time series of observations. Both are Anomaly or Motif estimates that indicate if a particular sub-sequence of observations is a typical motif or a rare anomaly. Matrix Profile is based on a single class of observations, and Multi-Matrix Profile is based on several classes of observations. Estimating anomalies and motifs from a time series is an exceedingly useful specialization of general estimate for predictive maintenance.

Fig. 6.
figure 6

Time series estimates and Matrix Profile [16]

Full size image

4.5 Methods for Calculating Estimates

In Sect. 4.3 we mentioned a general Method that calculates Estimates from Observations. Here we introduce two specific and important subclasses of these methods. Our method for computing estimates may be realized through Queries, Pipelines, or a mix of these.

Fig. 7.
figure 7

Query and Pipeline methods for computing estimates.

Full size image

Query methods (Fig. 7) are based on SQL-like queries from the observation database. They can also be implemented through systems like GrafanaFootnote 3.

Pipeline methods (Fig. 7) transform the data through a series of transformers and finally calculate the estimate on the transformed data using a predictor. This pipeline pattern is common in machine learning, for example it is used in a popular Python machine learning library scikit-learnFootnote 4.

4.6 Rules and Alert Rules

We have already mentioned the need to allow experts to inject their knowledge into the system of predictive maintenance. Our solution is based on a general rule pattern well known from the field of software engineering. Rule pattern was originally described by Arlow and Neustadt [2] and has been used in various systems including laboratory management [11], etc. This pattern is central for our conceptual architecture.

Fig. 8.
figure 8

Rule archetype pattern from Arlow and Neustadt [2].

Full size image

As shown in Fig. 8 the original Rule is a sequence of RuleElements that can be Variables or Operators. Variables have values for specific RuleContext that could describe a date, a time, and an industrial site. If needed, a Party (e.g., an Expert) could override a Rule using RuleOverride.

Fig. 9.
figure 9

Alert Rules are based on a rule pattern [2].

Full size image

Figure 9 describes our proposed Alert Rule pattern. We replace the Rule from Arlow and Neustadt [2] with an Alert Rule. Rule Element sets a threshold value for a particular Indicator. Indicators replace the Variables in the original pattern. For example, if temperature observation is higher than 50C or if Matrix Profile value is lower than 10 then the rule applies.

Our conceptual architecture based on Indicators, Matrix Profile estimators, and Alert Rules should provide a pattern-based architecture that is flexible and extensible.

5 Conclusions

The article proposes a conceptual architecture that splits the system into a rule/expert system layer and an indicator/machine learning layer. This architecture is based on known patterns from the field of software engineering. It establishes expert rules on indicators from sensors and machine learning methods like Matrix Profile and allows for independent, flexible evolution of rule management and machine learning subsystems. This paper also presented one potential set of technologies to implement such conceptual architecture, using Grafana open observability platform, Python’s stumpy framework [8] for Matrix Profile. To the best of our knowledge the application of Rule and Observation patterns in our predictive maintenance architecture is a novel contribution.

We have already started building a scalable near-real-time platform to detect underperformance and uptake the proactive maintenance activities. We use the most cutting-edge techniques from machine/Deep learning and big data fields for that purpose.

The technical impact will be manifested through increased innovation facilitated by new AI solutions. The architecture of near-real-time management tool offers some distinctive features :

  1. 1.

    Velocity challenge: Provides a near real-time accurate classification of data collected (and aggregated) from multiple sources (sensors, images, videos).

  2. 2.

    Zero-delay challenge: The early detection of underperformance is pivotal as it may have dramatic consequences.

  3. 3.

    Scalability: Built using the open-source big data platform APACHE-SPARK; on top of it stands the most scalable event streaming platform APACHE-KAFKA (High throughput and availability).