Supporting the Implementation of Predictive Maintenance – a Process Reference Model

The perception of predictive maintenance as a proactive maintenance strategy to anticipate and reduce severe and costly failures and by thus increasing asset reliability has grown significantly in recent years. Due to the availability of machine sensor data and the intention to use these data in a purposeful way, the introduction of predictive maintenance provides a logical step towards maintenance optimization in industry. Several German industrial surveys highlight the growing interest in the topic by the majority of the addressed companies. Nevertheless, most of these companies are considering predictive maintenance on their future agenda and are currently only at the beginning of its implementation. This is, in many cases, due to missing internal knowledge and systematic guidance for maintenance practitioners. Existing process models and supportive guidance build on theoretical knowledge from experts; however, they often lack the complexity and challenges of industrial applications. In addition, most theoretical models focus on specific aspects of the entire process, target particular application areas, or present a few high-level steps. This paper, therefore, introduces the Process Reference Model for Predictive Maintenance (PReMMa), a comprehensive three-stage hierarchical process reference model for the implementation of predictive maintenance for industrial applications. The process reference model synthesizes existing process models as well as results from interviews with eleven practitioners from both management consultancies and experts from several industrial fields. With regard to four main phases and the predictive maintenance application, results are presented with consideration of the essential steps, their deliverables as well as the involved persons.


INTRODUCTION
The value of maintenance has increased for businesses in recent years. As traditional maintenance types, including corrective and time-based preventive maintenance, are no longer able to address the increased complexity of products, a shift towards more sophisticated maintenance approaches can be observed to ensure quality and reliability (Bousdekis, Magoutas, Apostolou, & Mentzas, 2015;Jardine, Lin, & Banjevic, 2006). Through the integration of new technologies, businesses can stay competitive (Guillén, Crespo, Macchi, & Gómez, 2016). Predictive maintenance (PdM) depicts a maintenance type that takes advantage of new technological advances in terms of monitoring and analyzing machine conditions using available sensor data. This data provides information to identify and estimate upcoming machine failures (Lee, Jin, Liu, & Davari Ardakani, 2017). The engineering discipline Prognostics and Health Management (PHM), as a key enabler for predictive maintenance, covers methods and technologies to evaluate the reliability of equipment in its actual life cycle condition (Guillén et al., 2016;Haddad, Sandborn, & Pecht, 2012). Results from PHM are used as a basis for improved maintenance decision making. Therefore, maintenance planners can rely on information about current and future machine conditions to schedule maintenance with minimal interruption of the regular operation (Xue et al., 2008).
Maintaining complex systems is costly and can consume as much as half of the initial investment costs (Zaidan, 2014). This indicates a potential cost-saving opportunity that would most likely result in financial benefits for the vast majority of companies. Despite a few successful realizations, the majority of companies, however, are still in the early stages (Feldmann, Herweg, Rauen, & Synek, 2017). This is attributed to various factors, such as innovation-averse mindsets, unclear scope and structure, as well as uncertainties regarding the monetary benefits and the corresponding business model. To pave the way for future successful applications, step-by-step guidance for the development of PdM implementations is beneficial. In general, research publications in the field of PdM and PHM address particular cases (Brahimi, Medjaher, Leouatni, & Zerhouni, 2016), with only a few efforts with regard to a generic methodology independent of a specific application or equipment (Lee, Ni, Djurdjanovic, Qiu, & Liao, 2006). Even though there are process models supporting practitioners during the implementation process, these models stay at a high level with few steps only and are based on theoretical insights lacking the complexity of real-world applications. While there are detailed elaborations on some parts of the overall process (e.g., requirements specification (Saxena et al., 2010)), a synthesized and aligned view on the complete process currently lacks in the field of research. For this reason, this research addresses the objective of identifying the predictive maintenance implementation process in a company to support the development of industrial PdM applications at a sufficient level of detail by presenting the required phases, steps, deliverables, as well as the project team, including the key competencies.
In order to reach the stated objective, the Process Reference Model for Predictive Maintenance (PReMMa) is developed. PReMMa provides comprehensive and detailed assistance and structured guidance for the realization of predictive maintenance for practitioners. Due to its reference perspective, it should be adaptable to create a PdM process model considering the particular PdM characteristics and targets. The model is developed, building upon the available theoretical body of knowledge and subsequently extended and verified with industrial insights from eleven expert interviews. The identified process reference model is structured in a hierarchical manner with regard to three levels of detail. On the highest level, a phase model is developed, which provides generic phases to be followed. These phases are detailed on the second level in terms of concrete processes for each defined phase. On the lowest level, specific steps and tasks (referred to as process elements) to be executed for PdM implementation are described. For a company realization, the process reference model requires adaptations (in terms of skipping or adding processes and process elements ) to better address the application-specific needs.
PReMMa exhibits the following characteristics:  Considered elements: phases, processes, process elements, as well as input/outputs, project team, and project management  Main focus: production plants with legacy systems  PHM methods: data-driven approaches Even though, as a primary focus, PReMMa targets datadriven PHM approaches for production plants with several different machines, it is generally applicable to other types of predictive maintenance implementations with slight adaptations. This includes, among others, the integration of PdM during machine development, the development of PdM for a specific machine, as well as the realization of service projects by transferring the corresponding steps to the particular area and possible skipping non-relevant aspects. In addition, the emphasis was placed on data-driven approaches due to their ability to learn intricate hidden patterns. With respect to current advances in sensor technology and data processing, as well as increasing system complexity, datadriven methods are becoming more accessible and favored within industrial applications (Hu, Youn, Wang, & Taek Yoon, 2012). Beyond that, they do not require prior knowledge on the physics-of-failure, their implementation is fast and simple, and solutions are adaptable to other systems (Elattar, Elminir, & Riad, 2016). However, they demand multiple run-to-failure occurrences. Nevertheless, in cases where the failure mechanism is understood in detail, only little data is available, and/or accuracy is of utmost importance, physics-based approaches should be considered (Heng, Zhang, Tan, & Mathew, 2009). Even though the process reference model targets the former case (data-driven approaches), the corresponding phase can be adapted at a low charge to handle physics-based methods.
The paper is structured as follows: the second chapter explains the information gathered and structured with regard to the body of theoretical literature. It highlights the classification of existing process models, the synthesis of the identified theoretical models as well as the review and integration of related areas. This is followed, in the third chapter, by the introduction of the process reference model for predictive maintenance (PReMMa). Therefore, the phase model is presented, followed by a detailed description of each phase, associated processes, and process elements. The fourth chapter then depicts the evaluation and extension of PReMMa with industry insights in terms of expert interviews. Besides the alignment of the process reference model to industrial processes, the responsible departments and competencies for each phase are extracted and presented.

Process Model Classification
The need for a systematic process to support the development of a predictive maintenance solution, respectively, a PHM system has been emphasized by several authors, including, among others, Brahimi et al. (2016) and Lee et al. (2014). However, no process model was identified, which provides both application-independent and detailed guidance for the realization of predictive maintenance in a company. Nevertheless, there exist several process models in academic research as well as in standard documents, which describe (parts of) the predictive maintenance implementation process, which can be used as a foundation for the development of the process reference model.
Predictive maintenance processes outline the sequence of steps to be performed to realize its implementation. While PdM process models (PM) depict an abstraction to illustrate the generic process sequence, processes refer to specific instantiations. Processes and process models in PdM can be grouped into four classes and two levels of details, depending on their origin and focus (Wagner & Hellingrath, 2019). Figure 1 depicts a visualization of the different classes.  The first category represents the academic process models. Academic research in this category develops conceptual process models to highlight and address aspects of the implementation process. This category includes, among others, the application-independent 5s methodology (Lee et al., 2017), which describes five processes for PHM implementation as well as the application-dependent PMs for large-scale applications (Cocconcelli, Capelli, Cavalaglio Camargo Molano, & Borghi, 2018). In addition, a large number of detailed process models are available, in particular with regard to prognosis. These are, inter alia, the conceptual framework for prognosis (Voisin, Levrat, Cocheteux, & Iung, 2010) as well as the four technical processes in a machinery health prognostic program (Lei, Guo, Li, & Yan, 2018). Furthermore, research has been conducted on various parts of the overall PdM process, e.g., with regard to requirements specification (Saxena et al., 2010), functional architecture definition (Li, Verhagen, & Curran, 2018), and decision making (Bousdekis et al., 2015).
The second group depicts process applications presented in academic research. In these studies, a process is used to highlight the steps carried out for a specific case study. The onboard system (Das, 2015), which enables near real-time diagnostics and prognostics as well as the fan unbalance monitoring system (Z. Shi, Lee, & Cui, 2016), are exemplary application processes.
The third group addresses industry-independent standards, whereas the fourth group depicts industry-specific standards.
The fundamental standard document in predictive maintenance is ISO 17359-1:2018ISO 17359-1: , 2018. This standard provides a general procedure for condition monitoring. In addition, standards for diagnostics (ISO 13379-1:2012(ISO 13379-1: , 2012 and prognostics (ISO 13381-1:2015) (Bousdekis et al., 2015). Another publication in this group is NISTIR 8012 (Vogl, Weiss, & Donmez, 2014), which depicts a meta-analysis of available standards for PHM, provided by the National Institute for Standards and Technology (NIST). In this report, numerous standards from five organizations are analyzed and presented within a seven-step framework.
For industry-specific standards, on the other hand, the Aeronautical Design Standard Handbook (ADS 79D-HDBK, 2013) from the U.S. Navy for aircraft as well as the IEEE Std 1856-2017 for electronic systems describe process models for their specific application areas.
None of the process models, however, provide comprehensive and detailed guidance for the realization of predictive maintenance from the problem specification to its final realization and application. The majority of the models are either application-oriented or address a specific part of the overall process (in particular, data analytics). In addition, process models that depict the entire implementation process remain on a relatively high-level without providing detailed guidance. For this reason, a process reference model that synthesizes the available knowledge and provides guidance for all phases and steps of PdM implementation can support the successful realization in industry and is adaptable to specific applications.

Theoretical Process Synthesis
For the development and design of the reference process model, a structured literature review was conducted to identify relevant literature. Due to its concept centricity, the literature review was structured based on Webster and Watson (2002). Their approach consists of three steps; (1) identification of starting literature, (2) backward search, and (3) forward search. The search is terminated as soon as no other concepts are identified.
The initial literature identification targeted a title search, including different synonyms for process models as well as for predictive maintenance. Due to the non-uniform terminology for process models in predictive maintenance and the use of these terms for other aspects (mainly concrete algorithms), the initial search only revealed a few relevant publications. For this reason, the search was further extended to known review publications, which highlight different steps and reference further publications. This was followed by an extensive forward and backward search. Beyond that, applicable technical standards have been researched and included in the body of theoretical literature.
The structured literature research yielded 49 relevant processes and process models with various levels of detail and focus. The resulting knowledge base contains models and descriptions from all categories of the process model classification. While most models stem from academic literature in terms of applied processes or high-level process descriptions, there are also eight standard documentations, which are considered.
The developed process reference model synthesizes the identified processes and process models and arranges the described steps in a logical sequence. Due to the different levels of detail and a large amount of steps, the process reference model is structured in a hierarchical manner with regard to three levels (phases, processes, and steps).
The synthesis of the process models was carried out in two steps. Initially, the steps mentioned by process models that provide guidance for the complete predictive maintenance implementation process are gathered and subsequently arranged to form an initial three-level hierarchical process model. This is followed by the extension and adjustment of the model with regard to the information provided by the process model with a focus on particular aspects.

Integration of Related Fields
The synthesized theoretical process reference model was furthermore extended with process models and methodologies from the areas of data analytics, business process improvement, systems engineering, and project management. Besides the integration of additional knowledge, the purpose is to align the elaborated theoretical model with existing best practices and standard processes in influencing fields, which are not targeted in detail by the identified processes.
Data Analytics (in this context, often referred to as Knowledge Discovery in Data or Data Mining) aims at extracting information from large data sets. Existing processes provide support for generic steps for a wide range of data analytics projects. Due to the need for sensor data analysis for diagnosis and prognosis, PdM implementation can be seen as a data analytics project and, therefore, profit from existing knowledge. In the field of data analytics, the cross-industrial standard process for data mining (CRISP-DM) (Chapman et al., 2000) is chosen for integration. CRISP-DM depicts the leading methodology for data analytic projects in industrial applications (KDnuggets, 2014). It contains 24 process steps, which are structured in 6 phases starting from the business perspective to the deployment. With regard to the detailed processes, several adjustments were made to the synthesized PdM process model. These adjustments mainly included several steps from the data understanding phase that are not covered in detail before, as well as reporting and reviewing activities.
The field of Business Process Improvement targets business process re-engineering in order to adapt and redesign existing processes. The implementation of predictive maintenance requires maintenance processes to be proactive. For this reason, described steps provided by the generic and practical methodology for model-based and integrated process improvement (MIPI) (Adesola & Baines, 2005) are considered in the predictive maintenance reference process model. The MIPI methodology was developed by reviewing and analyzing available methodologies and was thoroughly validated by industry interviews and case studies. It consists of a seven-step procedural approach that guides a process design team during business process improvement. The general procedure was integrated into the theoretical process reference model by introducing two processes for the analysis of current maintenance processes as well as for the redesigned process implementation. In addition, continuous process review was incorporated.
Systems Engineering describes an approach that targets the design and management of complex technical systems. It includes the development of appropriate technology architecture, referred to as system architecture, which comprises the logical and physical view, as well as integration and operation. In order to design a PdM system architecture that fits best to the company's needs, systems engineering provides support from system concept development to system disposal (Walden, Roedler, Forsberg, Hamelin, & Shortell, 2015). The INCOSE systems engineering handbook describes the key systems engineering processes (Walden et al., 2015). It comprises 25 process steps within four process groups (enterprise, agreement, project, and technical processes). The integration into the PdM process reference model focuses on the technical process steps. With regard to the handbook, several processes are supplemented to and re-structured in the system architecture phase; in particular, detailed processes during system implementation and integration are included.
Project Management captures the different processes which are necessary to manage a project from its initiation to the closing. The implementation of predictive maintenance in a company represents a project due to its limited time duration, which creates a unique result (Project Management Institute, 2017). The Project Management Body of Knowledge (PMBOK) (Project Management Institute, 2017), which defines guidelines and standard terminologies developed by the Project Management Institute (PMI), is integrated into the process reference model, as it provides well-established and widely-applied traditional practices (Project Management Institute, 2017). In the PMBOK, 47 process steps are elaborated, which are grouped into ten knowledge areas and five process groups. As project management is usually conducted in parallel to the project and its concrete application depends highly on the project characteristics, only the five process groups are assigned to the second level of the PdM process reference model.

PReMMa Structure
The Process Reference Model for Predictive Maintenance (PReMMa) describes phases, processes, and process elements with its relevant inputs and outputs for the realization of PdM implementations. In addition, it provides guidance with regard to the project team and corresponding project management tasks.
PReMMa is organized hierarchically on three-levels of detail. The first level describes a phase model that includes five generic phases to be followed during the implementation of predictive maintenance. These phases are detailed on the second level, the process level. For each phase, a number of processes are highlighted. On the third level, the process element level, the identified processes are described with their corresponding steps. Figure 2 provides a visualization of the PReMMa structure. In the following, only the phase level and process level are visualized; however, the process element level is described in the respective phases. Figure 9 presents a comprehensive summary and reference view of PReMMa. It shows the identified process elements grouped with regard to their processes and phases. In addition, it highlights the main outputs on the process level, as well as the responsible project team and project management tasks.
PReMMa depicts a reference process model, which presents a large number of process elements. Depending on the scope of a targeted PdM solution, not all described processes and process elements need to be addressed.

Phase Model (Phase Level)
In order to structure the process reference model, different phases for PdM implementation are deduced, taking into account the set of identified steps. These steps have been grouped into distinct phases to be performed during predictive maintenance implementation. The resulting phases, therefore, describe the highest level of the PdM process reference model, the phase level. The resulting phase model is presented in Figure 3, which emphasizes on the relation between the phases as well as the primary outcomes.
Besides the four phases for PdM implementation, the phase model also depicts the PdM application, which represents the final target of the project.

The PdM implementation is initiated in the Preparation (PP)
Phase. This phase covers all steps required to define the project scope and target, as well as the particular implementation concept. The phase is subdivided into the project preparation phase and the candidate preparation phase. The former sub-phase addresses the complete project refines its specifications, identifies possible realizable candidates for PdM implementation as well as the current maintenance processes. Here, a candidate denotes the unit of analysis. Depending on the application context (with respect to inter alia function and complexity) and targeted scope, this could be, e.g., a system, sub-system, equipment, or component. The second sub-phase covers the planning and specification of the complete realization of a specific candidate. The following phases, PHM design and candidate solution deployment, are iteratively executed for each candidate, while the system architecture design phase is executed once independently of the specific candidates.  Under consideration of the developed concept, algorithms for anomaly detection, diagnosis, and prognosis are generated for each candidate in the PHM Design (PHM) Phase. This is followed by the solution assessment with regard to predefined performance metrics and requirements as well as the consideration of possible mitigation actions.

Begin PdM Introduction
In parallel to the PHM design phase, the technical system architecture (technology architecture) is defined, which should enable real-time access to machine condition (sensory) data. The System Architecture Design (SA) Phase, therefore, includes the physical/distribution architecture as well as the logical/information architecture and results in the final system implementation, including system verification and validation. Besides the system architecture, the maintenance database is setup.
In the Candidate Solution Deployment (CSD) Phase, the developed PHM algorithms are deployed, and its sustainment is implemented. In addition, the existing maintenance processes are redesigned to fit the new requirements, and the resulting change is subsequently realized, including corresponding personnel training and change management.
Lastly, the PdM Application (PA) comprises the usage of predictive maintenance in the company. It defines the steps related to performing anomaly detection, diagnostics, prognostics, and health management taking into account the developed PHM algorithms. The PdM application process allows for return loops to early phases in case of required revisions of the PHM algorithms, as well as for necessary maintenance process and technical system adjustments.

Preparation (PP) Phase
A PdM project requires detailed and comprehensive planning for its successful and target-oriented realization. For this purpose, the preparation phase depicts a critical element. PReMMa covers this phase in detail; however, depending on the scope and target of the project, not all steps are relevant to this extent. The preparation (PP) phase is subdivided into the project preparation phase, which plans the general project scope independently of specific PdM components and the candidate preparation, which is executed for each candidate iteratively. The first subphase includes project specification, as-is maintenance process modeling, as well as candidate identification, whereas the subsequent phase covers the prerequisite determination, measurement extension, and concept elaboration. Figure 4 visualizes the process level of the PP phase. The preparation phase consists of six additional processes (described in the following) on the lowest level, which provide detailed steps for each element defined on the process level. The steps are summarized in Figure 9.
The project specification in the PP phase starts with an as-isanalysis and a maturity assessment of the company, mainly with regard to its technological maturity. Based on these results, targets and objectives are defined. In addition, project stakeholders have to be identified, which range from members of the executive board to the machine operators, but can also be external company persons (e.g., customers). In particular, their expectations, their responsibilities, and potential influence on the project results have to be evaluated and addressed in the stakeholder requirements. Given both the objectives and stakeholder analysis, a general project charter (including the business case) can be derived. This is further refined in terms of project specifications and constraints, as well as requirements. The requirement analysis depicts an iterative process from high-level to lowlevel requirements. As soon as the targeted project scope is defined, the economic benefit of the project has to be evaluated. In particular, the costs for PHM implementation have to be justified and resulting benefits identified. This is done by means of a return-on-investment (ROI) analysis. This analysis yields a final decision on the realization of the project. A critical part hereby is the definition of appropriate key performance indicators (KPIs) (e.g., equipment uptime, total maintenance costs, process quality, and false-positive rates for Remaining Useful Life (RUL) estimation) and envisioned targets. These should be aligned with the crucial stakeholders identified in the previous step and will provide a measure of project success. The process completes with the project plan development. The main outputs are the project specification and the project plan.
The as-is process modeling identifies and models the existing maintenance processes, which form the basis for required process adjustments in the context of PdM. For this reason, the general maintenance processes have to be primarily understood, modeled, and analyzed. The modeled as-is processes will be input for the process redesign in the candidate solution deployment phase.  The candidate identification targets the identification of a list of relevant PdM candidates, which are further considered for the PHM method design. In order to define possible PdM candidates, existing equipment is identified initially. From the list of equipment, potential candidates are subsequently assessed. This can be done in a rigorous and very structured approach either bottom-up, via component breakdown and analysis (event tree analysis, FMECA, or hazard analysis) or top-down with regard to equipment functions using fault tree analysis, Markov/Petri net analysis, or reliability block diagrams. In addition, a simplistic criteria-based approach, in terms of defining components and assessing these based on various assessment criteria, can be performed. Independent of the strategy, process and safety criticality are key criteria for the candidate assessment, which are often decisive for the selection. All strategies result in a list of assessed components, which is evaluated with regard to their PdM necessity (maintenance strategy determination). The list of PdM candidates is thereafter prioritized, and candidates are iteratively taken as input to the second sub-phase, the candidate preparation, in the order of their priority.

Begin Preparation Phase
The candidate preparation sub-phase takes as input one candidate. In prerequisite determination, a team is first formulated consisting of various experts for the respective candidate (including engineers and maintenance personnel). The team is then responsible for identifying and defining failure modes and required parameter measurements. These are assessed against existing sensor capabilities to determine if further sensor measurements are needed. Finally, a prefeasibility analysis under consideration of the analytical and data feasibility of the candidate is performed, which allows for the early cancellation of the candidate in case of infeasibility without the need to execute the steps up to the final feasibility analysis. In case available measurements are insufficient, additional sensors have to be installed if the candidate allows for additional sensor mounting. Measurement extension, therefore, comprises the steps of measurement market research conduct, measurement technique definition, and location identification, as well as its installation and testing.
Finally, the candidate concept elaboration defines and formulates the implementation of the respective candidate. For this reason, candidate requirements, including the targeted PHM task as well as performance metrics, are defined based on the detailed system requirements. These specifications are used to develop a complete concept as well as the end-to-end use case description. In case more data is required for the PHM design, the experimental generation is planned in terms of experimental design. In addition, an ROI analysis for a particular candidate can be performed. The phase concludes with the final feasibility assessment and the decision about the candidate's further investigation.
The PP phase is supported by the project management tasks project initialization and planning during the project preparation sub-phase, as well as the project execution in the candidate preparation sub-phase. The project management tasks (PM tasks) are summarized in the PReMMa reference view (Figure 9) for each phase.

PHM Design (PHM) Phase
The core phase of the PdM implementation features the PHM Design (PHM) phase. For each candidate, it comprises the formulation of the required engineering knowledge, data acquisition/preparation, algorithm development, algorithm assessment, and solution mitigation/documentation. Figure 5 depicts the process level of the PHM Design phase. Depending on the targeted PHM task (anomaly detection, diagnostics, and prognostics), the process is shaped differently. As stated above, the process focuses on the development of data-driven approaches due to their high applicability in practice. Nevertheless, the process can be adjusted to physics-based approaches where more effort must be put towards understanding the degradation process rather than data preparation and algorithm development. This might be the case for safety-critical systems, where high accuracy is essential. The PHM Design phase covers five processes on the second level, which are detailed on the third level. The processes and process elements are depicted in the following paragraphs and summarized in Figure 9. The phase is supported by the project management tasks of monitoring and controlling. The engineering knowledge formulation defines the prior knowledge about the candidate required for the majority of data-driven techniques. In the first step, healthy and dysfunctional machine behavior is analyzed. Based on that information, targeted failure modes and associated potential parameters are selected, and failure thresholds are determined. To evaluate the feasibility of the parameters with regard to its requirements, several measures are available, including the observability, diagnosability, coverage (Goebel et al., 2017), trendability, monotonicity, and prognosability (Coble, 2010). As soon as the parameters are defined, the candidate description is prepared.
In data acquisition and preparation, the defined data is collected, integrated, and prepared. In case a software solution is used for support, it needs to be selected and setup. The subsequent steps are carried out in alignment with an excerpt from the historical data. To gain an initial understanding of the data, data is visualized, and prior knowledge of the data is obtained through the use of simple descriptive statistical methods. In addition, data quality is verified. For unlabeled data, labels are specified with the support of experts. This is followed by data reduction (variable selection), integration, and transformation. As soon as the data is available in a uniform format, signal processing (e.g., data cleaning, normalization, and filtering) is done, which is followed by sensor validation. Lastly, either feature engineering (including feature extraction, evaluation, and selection) or smoothing is performed depending on whether symptoms and degradation are visible directly or indirectly in the data.
The scope of the algorithm development depends on the targeted PHM tasks. To specify the setting, an appropriate algorithm is selected, and the test-design generated (e.g., a split of training and testing data). For condition monitoring, an anomaly or fault detection algorithm is developed, including health assessment. In addition, diagnostics covers the tasks fault isolation, failure mode identification, primary cause identification, and degradation level assessment. The development of a prognostic algorithm includes the steps endpoint definition, health index construction, health state division, RUL prediction, confidence level determination, and prognostics event horizon identification.
The algorithm assessment includes, on the one side, the performance evaluation under consideration of the defined performance metrics using cross-validation as well as the requirements verification and validation. If the objectives are not achieved, the algorithm development is re-executed. Once the performance is appropriate, it is continued with mitigation and documentation. Primarily, the mitigation action is defined. Either it consists of simple maintenance instructions or complex optimization models to provide decision support to improve the planning and scheduling of the respective maintenance tasks. Based on this information, a human-machine interface or visualization dashboard is designed, and the candidate solution is documented. Lastly, a review of the performed steps in the PHM phase is performed to identify tasks that have been overlooked as well as the determination of the next steps based on remaining resources and budget.

System Architecture Design (SA) Phase
The system architecture (SA) design phase describes the development of an appropriate technical infrastructure to enable continuous machine monitoring and (real-time) predictive maintenance. For this, it is necessary to connect the machines and transfer data in a standardized manner. Control systems used for data gathering in predictive maintenance require sound operational technology as a basis for further data processing in terms of diagnostics and prognostics. In modern control systems, the company's information technology is often integrated (Hahn, 2016). While in some cases, a system architecture is available, and only adaptations are required, the process reference model additionally addresses the situation with no system architecture currently in place. Beyond that, the open standards for physical asset management (MIMOSA, 1998(MIMOSA, -2019, which provides several industry-standards with regard to enterprise application integration and condition-based maintenance, should be respected. The phase comprises the objective and requirement definition, network, and information technology architecture design, the system implementation as well as the system operation and maintenance. Figure 6 highlights the process level of the SA phase. Each process element in Figure 6 is described by a detailed process on the third level, which is depicted in the following and listed in Figure 9. The phase is supported by the project management tasks of monitoring and controlling. The objectives and requirements analysis makes use of the stakeholder specifications, system constraints, and detailed system requirements defined in the preparation phase. Based on these specifications, SA objectives and requirements are refined. The system requirements are validated against its operationalization afterwards. If the realization is feasible, it is continued with a detailed elaboration of the targeted architecture. The physical/distribution architecture design determines the technical architecture based on the objectives and requirements. Prior to the architecture design, existing instrumentations need to be identified, and therefrom further required instrumentation derived. In case additional instrumentation is required, a market review with regard to available technologies and hardware options is conducted. Thereafter, the hardware architecture, as well as its connectivity, is specified. For this purpose, operational technology usually comprises hardware and software systems such as SCADA, DCS, or PLC, which specify connectivity and communication between the different components of the network. For the detailed design of the system, in particular, storage and computing options are to be analyzed, which can extend or replace parts of the existing control system. In general, edge computing and cloud computing are two paradigms frequently used in conjunction with operational technology. While edge computing facilitates decentralized data processing at the edges of the network, cloud computing describes an infrastructure that is accessible via the internet either as a private (on-premise) or public (outsourced) service (W. Shi & Dustdar, 2016). For applications with highfrequency data, edge computing could, for example, be a reasonable solution. Data is preprocessed directly at the edges, and only aggregated reduced data is transferred to central databases. In addition, the physical/distribution architecture design should include cybersecurity concepts. For highly sensible data, on-premise solutions are preferred over cloud solutions.
The SA is further refined with regard to the logical/information architecture design. This includes, in particular, data standardization, interface definition, and data integration. The last aspect, data integration, integrate various data sources, which are deemed as relevant for PHM design, and can therefore contribute to the integration with the company's IT system (e.g., information available in ERP/MES). As a result of both the physical/distribution and logical/information architecture design, the SA is defined and described.
In system implementation, the specified and defined system is realized and integrated within the available technical infrastructure. This is followed by the system verification (considering the system specification), transfer of responsibilities (system transition), and, as a final step, its validation. After the system implementation, the system is operating, and system maintenance is carried out if required.

Candidate Solution Deployment (CSP) Phase
Once the PHM algorithm is developed for the currently targeted candidate, and a suitable system architecture is available, the candidate solutions can be deployed. This is done either successively for each candidate or in batches. The candidate solution deployment (CSP) phase includes deployment preparation, process adjustment, as well as deployment and sustainment. Fig. 7 presents the process level of the CSP phase. Detailed process elements for the CSP phase are listed in Figure 9. The deployment preparation includes the process elements of the industrial implementation and deployment planning with the deployment plan as output.

Begin
Process adjustment depicts the steps to integrate PdM in current business (maintenance) processes. Given the as-is process model developed in the PP phase, the maintenance process of the specific candidate is redesigned and implemented. This is followed by change management, in particular, personnel training. Lastly, the resulting process is assessed, considering its overall suitability, and identified adjustments are implemented. This is usually performed after the deployment of the candidate solution in the subsequently described parallel process.
The deployment and sustainment implement the solution in terms of system integration and final candidate solution deployment. This is followed by a test and validation step. In case the deployment or testing reveals required adaptations in the SA phase, a return to the SA phase is defined in the process element level. Thereafter, sustainment measures should be implemented, which results in a maintenance and monitoring plan of the candidate solution. Finally, documentation and review are performed, providing best practices and experience to future candidates as well as transferring existing knowledge. In case all candidates are deployed, the project is finalized with the project documentation.
The phase is supported by the project management tasks of monitoring and controlling and the project closing for the final project documentation.

PdM Application (PA)
PdM Application (PA) depicts the process, which is performed after the implementation is finalized, and the PdM solution is deployed. It, therefore, describes the final execution and realization of predictive maintenance in the company. The second level of the PdM application process is illustrated in Figure 8. Detailed process elements are depicted in Figure 9.
In data acquisition and preparation, machinery sensor data is continuously acquired and stored. This is followed by sensor data validation as well as signal processing and preparation (feature extraction and/or smoothing). The prepared data is input to condition monitoring. Data values are monitored and compared against a threshold. In case of a deviation, fault detection in terms of symptoms identification and system health assessment is conducted. For diagnostics, fault isolation, fault mode identification, primary cause identification, as well as severity assessment, is performed. In this case, the system sends an alert to the responsible person. In critical situations, the equipment is shut down immediately. For Prognostics, the best fitting degradation model is selected under consideration of the fault situation, and the current health and performance are assessed. Depending on the method, the trend is projected in the future, or model features are updated. The resulting RUL of the component is verified and combined to form system prognostics. In health management, risk assessment provides the foundation for the maintenance advisory generation taking into account diagnostic and prognostic results. Existing possibilities are assessed with regard to their operational impact. The resulting information is visualized and presented to the responsible persons. Based on the failure analysis, different actions are possible (compensation, correction, or execution). These are integrated and aligned in the maintenance and manufacturing schedule. After the maintenance activity, feedback on the system performance is provided in terms of quality assurance. The phase ends with the solution revision. Feedback and required adjustments are integrated into the database. The solutions are continuously reviewed, and effective measurements are evaluated. In addition, the technical system and business processes are reviewed. In case a revision in one of the described cases is required, the respective phase is re-executed, and adjustments are carried out, taking into account the identified issues.

Industry Insights
The theoretical model was extended and validated with knowledge and best practices from industrial applications. For this purpose, information from real-world PdM implementation processes is gathered. The identified processes are matched against the theoretically derived model to assess the fit and make adjustments/extensions in case of deviations. Furthermore, PReMMa was extended by the team structure and required capabilities (cf. Chapter 4.3), using industry insights. The reference process model presented above already includes the resulting adaptations from the validation step.
To gather information from industrial applications, eleven industry experts with medium to long experience in PdM were addressed using semi-structured interviews. Experts from several industrial fields were questioned to capture the variety of different applications, including both companies with internal PdM implementations and consultancies supporting the introduction process. The companies with internal implementations are active in the steel, automotive, aerospace, as well as in the wind energy industry. In addition, research and management consultancies, as well as solution providers, were considered with experience in multiple diverse projects. Due to the reoccurring nature of their projects, these companies have well-established processes, which are continuously further developed with experiences and best practices from previous projects. Table 1 depicts detailed information about the eleven industry experts, including their industry, their PdM expertise as well as their position within their company.
The expert interviews were conducted with regard to the seven stages of an interview investigation defined by Kvale and Brinkmann (2009). The semi-structured type, in terms of both telephone and personal interrogations, was considered to allow the interviewee to raise new content but also ensure  (Misoch, 2019). After the introduction of the participants and the interview target, the interviewees were questioned about their position and experience with predictive maintenance in the warm-up phase. The following main phase applied the dual-process mapping method by Widera and Hellingrath (2011), which structures the interview in two parts (unstructured and semistructured). Initially, in the unstructured part, the company was asked to present its PdM introduction processes without being interrupted by the interviewer. This facilitates broad information gathering. Following this in the semi-structured part, in-depth questions about the different phases were asked to enable comparison between the various interviews. The questions focused on the processes, steps, tasks, deliverables, and persons involved.
The qualitative data gathered from the interviews are analyzed using a reflexive thematic analysis. Information was extracted and structured with regard to themes enabling detailed descriptions of the present cases (Braun, Clarke, Hayfield, & Terry, 2019). These were derived directly from the questions and the theoretical background. In addition, a few themes were added based on the qualitative data, in particular for steps highlighted during the unstructured process narration. The identified and modeled processes were validated afterward with the experts

Processes Analysis and Evaluation
The material resulting from the eleven interviews provides valuable insights into current predictive maintenance implementations. The PdM applications of the interviewed companies can be classified with regard to two dimensions: the responsibility (internal/external) as well as the target (production machinery/product). While companies A-E implement PdM internally, companies F-K realize PdM projects as external consultants. This distinction, however, does not affect the described processes very strongly with the only exception of company K, which does not support the entire implementation process but only provides its software solution. In addition, companies A-C implement PdM for their production machinery, whereas companies D and E provide PdM for their products as a service for their customers. The management consultancies, on the other hand, support both options. Nevertheless, it was stressed that their customers mainly consider their own production. In general, no substantial differences in the processes between these groups are visible.
A large number of the identified steps are carried out by the majority of the companies. These include the requirements engineering, the machine/candidate selection, the technical infrastructure, data preparation, model development, deployment as well as continuous review. On the other hand, some steps were only mentioned by one or two companies, which might be attributed to the specific context and situation of the company. In addition, the maturity of the company with regard to the available technical infrastructure, as well as their PdM solution, affects the resulting process positively. Companies with low maturity are not considering the PHM design phase in detail and are targeting mainly data visualization. In contrast, companies with high maturity in their PdM implementation apply prognostics and provide decision support with regard to prognostic results. Beyond that, the sequence of the conducted steps might change between different companies. Nevertheless, all companies described their processes as being highly flexible, which allows for a return to previous steps and adaptations, in particular during the PHM design phase.
In general, it is observed that the industry PdM processes are well aligned with the theoretical reference process model. The interview material reveals that all industrial PdM processes exhibit the different phases, as well as most of the steps identified in the theoretical literature. The most significant deviation depicts the system architecture design.
An existing system architecture is most times extended and not defined from scratch. Due to its reference character, the complete system architecture design phase is kept in the process reference model. However, this does not reduce the applicability of the model as the system architecture extension is included as well. Another deviation depicts candidate identification. In this process, available literature portrays a very structured and rigorous approach, while the interview material reveals a simple criteria-based approach. Both options are depicted in PReMMa.
Each described process was matched against its applicability to the model. This resulted in a few necessary adjustments. On the one side, the sequence of the preparation phase was adapted to better fit the industry processes. This includes the insertion of the prerequisite determination, in which several steps are re-positioned before the sensor extension. In addition, further steps were included in the reference process model. These steps are the maturity assessment, concept development, team formulation, market analysis (software and hardware), software selection and set-up, data labeling, process adjustments, and change management.
The summary of the identified process elements per expert interview, as well as their allocation to the different phases, is provided in table 2 (Appendix). The defined steps are marked with an X, in case they were mentioned explicitly by the interviewee. If the step has not been carried out yet by the company but was referred to as a step planned for the future, it is marked in parentheses.

Team Structure and Capabilities
In order to develop and implement PdM in a company, not only the steps are relevant, but also the required skills and the overall project organization contribute positively to the project's success. As a first draft, the capability taxonomy for prognostics and health management was presented by Bird, Madge, and Reichard (2014). It provides a detailed description of the capabilities for the design of PHM approaches. Different tasks are depicted with regard to three levels of competencies. The taxonomy offers several required PHM capabilities in the area of data analysis and engineering, however, with a focus only on the PHM design phase. Due to the lack of further theoretical contributions, this aspect was addressed in the interviews. The synthesized results are depicted in the PReMMa reference view (Figure 9) per phase in terms of the core and the extended project team.
With regard to the data provided by the experts, three competencies are identified for predictive maintenance implementation, which has to be present for successful execution. These key competencies are:  Technical and engineering knowledge  Data science skills  Functional know-how Furthermore, the project team consists of a core as well as an extended project team, which provides further information and input to the project and which is addressed only for specific topics. Projects are managed either by the maintenance department, the technical planning department, and/or the production department for production optimization projects, or by the service department in the case of customer service projects. The core project team is responsible for the complete realization of the project, including task distribution, project monitoring, and design. The extended project team includes the management (e.g., business owner, asset manager, COO), which usually acts as the project sponsor. They initiate the project, support, and make crucial decisions. Furthermore, they should ensure that the project is in line with the corporate strategy. Besides the management, additional support for the project team is required during data acquisition and data analysis. For this purpose, in most cases, the machine operator, the maintenance department, as well as the engineering, are supporting the project team. For servicerelated projects, these are, in general, the customer service as well as the field technicians. In addition to machine knowledge, potential parameters and failure behavior should be formulated jointly. Depending on the context, production, and quality control, as well as the machine manufacturer, can also be addressed. For data visualization and dashboard design, the machine operator or field technicians, as future primary users, are asked for a contribution, which also improves their acceptance and usability of the final solution.
The system architecture design, on the other hand, is supported by the IT or production-IT department.

CONCLUSION
PReMMa is a process reference model for the implementation of predictive maintenance. It provides guidance and support for the realization of a PdM project within all phases and tasks to be performed on three different levels of detail. PReMMa is designed to be universally applicable and is adaptable to the specific project characteristics and scope. The process reference model includes not only the reference process but, in addition, the required team structure together with key competencies and associated project management tasks. It is grounded on theoretical knowledge, which is extended by industry insights with regard to eleven expert interviews.
The need for a structured predefined process for the successful implementation of a predictive maintenance project was highlighted by three experts addressed during the industry study. They emphasized that the development of a structured process was critical to their success, whereas they were struggling much without the defined process. It enabled a means to communicate the project concept and required steps to the supporting team and management as well as guidance throughout the project. PReMMa can, therefore, be used to define an appropriate PdM project process by presenting relevant tasks to be performed.
Due to its general validity, the developed process reference model is not exhaustive regarding specific applicationdependent requirements and challenges. It provides a structured approach that outlines the essential steps. However, the detailed design and adaptation to the concrete application context must be carried out by the company itself.
In particular, PReMMa is designed for the development of data-driven approaches. In cases where physics-based approaches are more appropriate, several steps require adaptation within the PHM design phase. This includes, in particular, algorithm development, but also algorithm assessment.
PReMMa is founded and backed by a large body of literature. However, the material under investigation is not comprehensive, which is due to a large amount of available information and sources on various aspects of the entire process. In particular, standards are not yet covered exhaustively. A lot of work has been done with regard to standard development in the field of PdM and PHM. In NISTIR 8012 (Vogl et al., 2014), an extensive review of available standards is provided and organized by defined steps of PHM development. In addition, among other initiatives, the IVHM Working Group (SAE) and the PHM Subcommittee (ASME) are currently developing further PHM-related standards.
Future work should target the validation of the applicability and adaptability of the process reference model conclusively by assessing its completeness, understandability, correctness, generality, flexibility, and usability (Matook & Indulska, 2009). In addition, the implementation of several application cases considering PReMMa will lead to further adaptations and improvements. Besides that, the PHM design phase is currently developed on a generic level to support different kinds of data-driven techniques. To further improve guidance, different algorithm groups and their characteristics should be addressed and their specific processes identified. Lastly, the identification and delimitation of varying maturity levels with regard to data analysis and technical infrastructure, as well as their influence on the different phases, are envisioned for future work.