Reference architecture for digital twin-based predictive maintenance systems

Context: Digital Twin-based predictive maintenance systems are frequently integrated into complex systems. The success of the integration depends on the design of the system. A Reference Architecture can be used as a blueprint to design Application Architectures rapidly and consistently for various application domains, resulting in a reduced time-to-market. Objective: The main objective of this study is to develop and evaluate a Reference Architecture designed using renowned software architecture methods. Method: A domain analysis was performed to gather and synthesize the literature on Digital Twin-based predictive maintenance systems, which we used to model the key features. We applied UML diagrams to design the reference architecture based on the feature model. We evaluated the reference architecture using three case studies. Results: We derived three views for Digital Twin-based predictive maintenance systems. For the user ’ s view, we developed a context diagram. We developed a package diagram for the structural view, and we designed a layered view to show the system ’ s decomposition in layers. We designed an Application Architecture for each case study based on the study ’ s features using each Reference Architecture view. Additionally, we designed a deployment view to describe the hardware and software and its environment. Conclusion: We demonstrated that the methods of creating a Reference Architecture could be used in the Digital Twin-based predictive maintenance domain and showed how an Application Architecture could be designed in this context.


Introduction
Since the industrial revolution, machines have been used increasingly in all domains, improving product performance, efficiency, and the consistency of quality.However, machine condition greatly affects business models dependent on machines.Until recently, machines were usually repaired after failure or maintained periodically.However, these two methods have a few downsides.First, the risk of breakdown is not minimized; as such, there is still a risk of downtime and catastrophic failures.Second, these two methods do not make optimal use of system maintenance engineers, a scarce resource.Third, these methods waste natural resources, as reactive maintenance can damage more than the broken component, and preventive maintenance does not use the full lifetime of a component (Errandonea, Beltrán, & Arrizabalaga, 2020).
One method to use the full lifetime of a component is predictive maintenance (PdM), a subgroup of Prognostics and Health Management (PHM).With PdM, we use large datasets of run-to-failure data from sensor-equipped machines.The data can determine several health aspects, such as Remaining Useful Life (RUL), a specific health indicator, or anomaly detection (van Dinter, Tekinerdogan, & Catal, 2022).However, current machines have become well-designed, meaning there is a low amount of historical failure data (Luo, Hu, Ye, Zhang, & Wei, 2020).
Current trends toward improving PdM models are leveraging a Digital Twin (DT) to generate synthetic data.A DT is a high-fidelity digital model of the physical asset based on physics, data, rules, behavior, or geometry (Semeraro, Lezoche, Panetto, & Dassisti, 2021), which acquires sensor data during the operation of equipment and stores the historical running data for further analysis (Luo et al., 2020).Meanwhile, a DT can generate reliable synthetic data for a more robust predictive maintenance model.A DT-based PdM system comprises two modeling layers: an asset representation layer and an application layer.
DT-based PdM systems are complex and contain many software modules (Luo et al., 2020).The software architecture is crucial for the success of a DT-based PdM system design.Software architecture should describe communication, design decisions, architectural concerns, and architectural decisions addressing these concerns along with the rationale (Tummers, Kassahun, & Tekinerdogan, 2021;Tummers, Tobi, Catal, & Tekinerdogan, 2021).We use the Reference Architecture (RA) design principles with structured and standardized design methods.An RA is a generic, domain-independent design that derives an Application Architecture (AA) based on system requirements.An RA can be considered as a template solution for a particular application domain and it also provides a vocabulary for implementation purposes.Application architecture selects some of the reference architecture elements and should be considered a specialization of the reference architecture.Application-specific changes are introduced in the application architecture.Using an RA enables software architects to develop a consistent design within a smaller timeframe, eventually reducing the time to market for the product.We propose an RA for DT-based PdM systems using well-known software design principles.We use key PdM and DT features from our systematic literature review (van Dinter et al., 2022).To validate our RA, we created three AAs from peer-reviewed literature studies.In addition, the design efforts are reduced, fewer errors occur in the designed system, and the overall quality increases (Ingeno, 2018).Communication within the organization is improved because of having a common architectural mindset.Development costs are reduced because the common assets are reused.The learning curve of developers is improved because of the use of the same vocabulary in the organization.The interoperability of the systems is enhanced by using a standardized solution.
Several studies are related to our work, which will be discussed in this paragraph.Lee, Bagheri, and Kao (2015) proposed the renowned 5C architecture, a layered architecture concept for cyber-physical systems (CPS).As a DT one kind of CPS, we leveraged this study and included the 5C architecture in our RA design.Mihai et al. (2021) designed a DT framework for predictive maintenance in Industry 4.0.Their framework is focused on a data science application using Python and the dashboarding tool Dash.They provide two analysis models that work in parallel: anomaly detection and a remaining useful life estimation module.Nordal and El-Thalji (2021) designed a predictive maintenance system architecture for Industry 4.0 applications called Maintenance 4.0.Their architecture is detailed and can be applied to manufacturing cases.However, they do not include a Digital Twin module in their design.Centomo, Dall'ora, and Fummi (2020) proposes a general framework based on the EDA approach that allows to set up a maintenance strategy by analyzing data retrieved from sensors.The framework is captured in diagrams describing the proposed system's generic behavior and is applied to gearbox degradation monitoring.Cohen and Singer (2021) developed a smart process controller framework for identifying anomalies.They designed an architecture using block diagrams of a typical manufacturing process control system and how to refactor it into a smart process control system.As this study clearly defines the modules used for validation, we use their implementation as a case study.Z. Liu et al. (2018); Z. Liu, Zhang, Xu, Jin, and Lee (2018) designed a CPS architecture for PHM of high-speed railway (HSR) transportation systems.They used the 5C architecture for their framework, specifically creating a layered design for HSR systems.Additionally, they developed a Cyber-Physical Interface Platform for HRS applications.Luo et al. (2020) developed a hybrid predictive maintenance framework based on a DT for CNC machine applications.However, they also provide a multi-domain model implementation.They present a well-structured layered architecture and multiple flowcharts to explain their design choices.Xiong, Wang, Fu, and Xu (2021) designed a framework and workflow for DT-driven predictive maintenance of aero-engines.Xiong et al. (2021) additionally provides a pipeline from aero-engine sensor data toward remaining useful life predictions.
There are also RAs that concern exclusively predictive maintenance systems or Digital Twins.Even though they are out of scope for this review, we will highlight the main contributions.Uhlmann, Polte, and Koutrakis (2021) developed a holistic concept toward a RA for predictive maintenance systems based on the three-layer Industrial Internet of Things (IIoT), which they validated in one case study applying Machine Learning (ML).Groba, Cech, Rosenthal, and Gossling (2007) proposed an Architecture of a predictive maintenance framework.In their study, in collaboration with SAP research, their architecture is housed as a component between the manufacturing domain and the Enterprise Resource Planning (ERP) systems.Balogh, Gatial, Barbosa, Leitão, and Matejka (2018) propose a RA for predictive maintenance systems using a cloud-based collaborative maintenance services platform for smart manufacturing.Zhidchenko, Startcev, and Handroos (2022) present an RA for interconnected systems running Digital Twins of heavy equipment.They provide a class and sequence diagram to elaborate their data model for Digital Twins.Redelinghuys, Kruger, and Basson (2019) present an RA for manufacturing systems with many Digital Twins that need interaction.They propose the Six-Layer Architecture for Digital Twins with Aggregation (SLADTA).Josifovska, Yigitbas, and Engels (2019) make use of the 5C architecture for CPS.They present a reference framework for the main building blocks of a Digital Twin framework that are missing from the 5C architecture.Lehner, Wolny, Mazak-Huemer, and Wimmer (2020) aim to connect Model-Driven Engineering models created in design time and use the knowledge during runtime.As such, they present a RA that enables data querying from model repositories to add design-time knowledge to the running system and reasoning system states at runtime in design-time models.Aheleroff, Xu, Zhong, and Lu (2021) identified Industry 4.0 technologies and designed a Digital Twin Reference Architecture.They also utilized the Digital Twin as a Service paradigm as a case study for digital transformation in appliances for wetlands schedule maintenance.
The practical contributions of this study are five-fold: • We developed a feature model using 42 selected articles on predictive maintenance using Digital Twins • We categorized the features using the 5C architecture for Cyber-Physical Systems • We proposed and validated a Reference Architecture for Digital Twins-based predictive maintenance systems using triangulation • We demonstrated the effectiveness of the proposed architecture using three case studies • We showed that the application architectures can be easily created using the proposed reference architecture.
Our main theoretical contribution is that we added another component to the development of a Reference Architecture (i.e., a graphical model of Predictive Maintenance Systems theory), which is analyzing state-of-the-art literature through a Systematic Literature Review (SLR) methodology.Additionally, we performed a domain analysis on existing Reference Architectures for Predictive Maintenance, Digital Twins, and Digital Twin-based Predictive Maintenance systems.The addition of the systematic literature review and resulting therefrom the feature model provides a structured overview of the mandatory and optional components in the state-of-the-art Digital Twin-based Predictive Maintenance Systems.
The next sections are organized as follows: Section 2 presents the methods.Section 3 explains the results.Section 4 shows the case studies.Section 5 presents the discussion and Section 6 concludes the paper.

Research questions
To generate a robust RA for DT-based PdM systems, we identified the following research questions: • RQ1: What are the existing reference architectures for Digital Twinbased predictive maintenance systems?• RQ2: What is a feasible Reference Architecture for a Digital Twinbased predictive maintenance system?• RQ3: Does the Reference Architecture allow for the derivation of a specific Application Architecture?
As such, we adopted the RA design approach from Tummers, Kassahun, & Tekinerdogan, 2021, Tummers, Tobi, et al. (2021), shown in Fig. 1.First, we perform a domain analysis, which synthesizes the domain knowledge to support the design of the RA.The domain analysis consists of two activities: domain scoping and modeling.Domain scoping specifies the domain's scope and the knowledge sources required to determine the foundational pillars.The goal of domain modeling is to describe domain knowledge in a consumable manner (van Geest, Tekinerdogan, & Catal, 2021).In our case, the domain scoping activity consists of a systematic literature review concerning PdM using DTs (van Dinter et al., 2022), while the domain modeling activity consists of creating a feature model.
Second, we use the information from the feature model for the design of our RA.Therefore, we create several views, which we will elaborate in Section 3.4.To show the suitability of the design, we derive multiple AAs from different application domains.We use a retrospective case study design from three applications, elaborated in the next section.We used the method for deriving the AA from the RR as proposed by Tummers, Kassahun, & Tekinerdogan, 2021, Tummers, Tobi, et al. (2021).

Case studies
This section describes the selection of case studies.Triangulation is a key principle in the design of a case study.Triangulation means taking multiple viewpoints toward the subject of study to capture the essence of the bigger picture (Runeson & Höst, 2009).We ensured data triangulation (i.e., various use cases) and observer triangulation (i.e., multiple application domains/observers).
The study was validated using cases involving different PdM requirements in different application domains.As mentioned in the previous section, we used studies implementing PdM algorithms.Then, we conceptually applied a DT-based PdM system to the case.The following three cases were selected for understanding and validating the RA design: Case 1. New Holland tractor transmission system.Maintenance of agricultural machinery, including tractors, is routine in the life of any farmer, especially preventive and corrective maintenance.da Silva, Rodrigues de Sá, and Menegatti (2019) created a PdM algorithm that identifies failures in the New Holland T8 tractor transmission system.It is a tractor for large-scale production, and pressure data of the clutch system is used for fault diagnosis.Case 2. Wafer semiconductor manufacturing.Silicon wafers are extensively employed in the semiconductor industry to fabricate integrated circuits.Typically, wafer thickness is monitored using scan data from a laser probe.Several polishing procedure factors can impact the quality and consistency of the acceptable thickness across the entire wafer.Cohen and Singer (2021) proposed an intelligent supervisory framework for a single process controller suitable for Industry 4.0 shop floors.It is compatible with the paradigm of a Cyber-Physical System (CPS) since its implementation creates a rich cyber-physical entity of the regulated process.This CPS entity might be considered the process's digital twin or a strong foundation for producing it.Case 3. Electro-optical imaging system.Infrared imaging devices are widely equipped for target recognition and tracking on aircraft and spaceships.Electro-optical detection excels at maintaining stealth and avoiding interference compared to radar and laser detection.However, when the electro-optical system's health deteriorates significantly, the imaging quality suffers, reducing the detection probability to target and, as a result, leading to the failure of combat operations.As a result, Yu, Song, Tang, and Dai ( 2021) designed a DT model and monitored the electrooptical system's health.

Results
This section starts with a summary of related reference architecture studies.It then presents the design phase's four steps: domain analysis, domain scoping, domain modeling, and RA design.

Domain scoping
DT-based PdM systems cover a wide range of subdomains.Much research is focused on the Manufacturing domain.Others focus mainly on the Energy, Aerospace, and Automotive domains.The most common DT abstraction level is the Component level and System level.Additionally, most DT-based PdM systems apply the Digital Monitor design pattern.

Domain modeling
Feature modeling is a method for representing domain knowledge and features of the system and its interdependencies (van Geest et al., 2021).The feature model is constructed from the information synthesized in the SLR study.A feature model also depicts whether a feature is optional or mandatory.Features mentioned by most publications or features that are required in every system are considered mandatory.Other elements are optional and can be leveraged based on a developer's needs.
We have generated a DT-based PdM system feature model, which has been divided into two figures to establish a robust overview of the features.Its features depend on literature from the SLR study and additional sources regarding data science techniques.Fig. 2 shows the DT-based PdM system with the collapsed PdM feature.Fig. 3 expands the features of the PdM side of the system.
A DT depends on several features, which we address following the order of the 5C architecture as proposed by Lee et al. (2015) (Connection, Conversion, Cyber, Cognition, and Configuration): Connection.First, the main component of a DT is its physical counterpart.Without the Physical Twin (PT), the DT cannot exist.Data acquisition is the process of synchronizing input data between the DT and PT systems at a specific Twinning rate.The Twinning rate may be a continuous stream or batches (Giray & Catal, 2021;Tekinerdogan & Verdouw, 2020).Storage is a feature supporting other features and refers to data's temporary and persistent storage (Giray & Catal, 2021).The storage feature involves relational and non-relational or NoSQL database systems (Cattaneo & MacChi, 2019;Priyanka et al., 2021;Wang, Lee, & Angelica, 2020).The communication feature consists of three subfeatures: publish-subscribe, client-server, and primary-secondary, which are the three most common communication architectures.
Conversion.Security was not mentioned by most studies identified by the SLR study.However, security is a mandatory feature for industrial applications, as it is undesirable to have an insecure connection between the machine and DT.Data quality management refers to handling data quality problems that may arise due to noise and drifting in sensor data, errors, or unreported human interventions.There may be missing, incorrect, unusable, or redundant data (Dhada et al., 2021;Moi et al., 2020;Xiong et al., 2021;Yu et al., 2021).
Cyber.The cyber layer consists of the simulation model feature.This feature contains the four DT representation types described by Semeraro et al. (2021): data-driven, behavior, physics-based, and geometrical representation models.A DT can also be represented through hybrid models consisting of two or more models (Luo et al., 2020;Tao et al., 2018;Yu et al., 2021).For example, a physics-based model can describe the known features of an asset, while a data-driven model can estimate the unknown parameters.
Cognition.The cognition layer consists of the visualization feature.With this feature, the DT model may be visualized using its FEM model (Wang, Liu, Liao & Mrad, 2020), CAD model (Rajesh et al., 2019), or AR techniques (Deebak & Al-Turjman, 2021).At last, we have the analysis module with batch and stream processing and PdM.The PdM's features are further elaborated using Fig. 3.
Configuration.The configuration layer contains the machine optimization feature.Z. Liu, Jin, et al. (2018) describe the machine optimization features with sub-features such as fleet management, zero downtime, optimized performance, and maximizing fleet readiness.
Five new sub-features are shown as we expand the PdM feature in Fig. 3. Again, we base the elaboration structure of the feature model using the Machine Learning workflow, as described by MLOps (2023).This section regards the application modeling layer, which is usually developed using machine learning techniques.
Data Engineering.As the PdM feature model is part of the DT-based PdM feature model, we use the data acquisition feature to obtain the necessary data.PdM algorithms may be executed in real-time or periodically, such as once per day.Feature extraction is used to gather more information from the data.It consists of time-domain, frequencydomain, and time-frequency domain feature extraction.
Machine Learning (ML) Model Engineering.As machine failures are not regularly occurring, datasets are often imbalanced.The data sampling sub-feature aims to balance the data to enable models to train on the essential features (Lemaître, Nogueira, & Aridas, 2017).When the data has been enriched and balanced, we can split the data needed for the validation feature.Engineers can choose between using a holdout set or N*k-fold cross-validation.When the data is correctly split, one must choose the right evaluation metrics to measure what it asserts.The KPI feature is essential for PdM as it determines the problem to tackle and the type of model to use.For example, Remaining Useful Life (RUL) is a    regression task, while fault condition is a classification task.Furthermore, the health indicator describes the deterioration of the asset, while RUL describes the time before failure.Model Development is the feature where the predictive model is engineered.We identified five types of predictive statistic models from the SLR study, seven types of ML models, and eight types of Deep Learning (DL) models for PdM tasks.
Model deployment.The model deployment step focuses on bringing the model to production (MLOps, 2023).The model serving feature enables deployment with three options, as described by Digital Twin Consortium (2023).Optionally, model performance monitoring can be added to keep track of model performance in production (MLOps, 2023).

Reference architecture design
In this section, we describe the selection of views and diagrams used to describe the RA design and elaborate on each view.

Selection of views
UML diagrams can be separated into five types of views to support the design of a system (Mall, 2018): These views map to the UML view models (Alhir, 1998).The relationship between these views is described by Kruchten (1995) as follows: "This use of multiple views allows to address separately the concerns of the various 'stakeholders' of the architecture: end-user, developers, systems engineers, project managers, etc., and to handle separately the functional and non-functional requirements" (Kruchten, 1995).We make use of this structure to design the RA.As the Behavior and Implementation views rely on exact system characteristics, we implement the User, Structural, and Layered views.For the User's view of the system, we develop a level-0 Data Flow Diagram (DFD), also known as a context diagram (Afyenni, 2014).For the Structural view, we provide a package diagram.For the Layered view, we create a layered view.For the case studies, we also develop a deployment diagram for the Implementation view.

User's view
The DFD level 0, depicted in Fig. 4, is a diagram that describes a system and its interfaces with the external environment at a high level.
The diagram shows data sources, such as sensors, and outputs, such as analytic insights, which relate to human supervisors and actuators.As DT systems are often served in the cloud, we introduced cloud computing resources as a bidirectional data source.The data is acquired, stored, processed, and analyzed by the DT-based PdM system to provide information on the DT's health state.

Structural view
Fig. 5 depicts the package diagram of the DT-based PdM system RA.The Physical Twin module is responsible for acting as a Proxy pattern for communication between the DT and PT.Data acquisition modules are responsible for loading data into the DT system for processing.The Communication module provides different communication protocols to enable the desired behavior of the system.Data quality can be managed by applying cleaning and enrichment procedures to the gathered data to gain more accurate findings from the analysis.The Abstraction level module enables the development of the SimulationModel in different levels of granularity.The SimulationModel module provides several submodules that enable the development of a DT.To help decisionmaking, submodules can be employed to Analyze the data, such as the Machine optimization and Predictive maintenance modules.The Batch and Stream modules describe the execution rate of analysis, which may be continuous or periodic.The Storage module manages several data storage mechanisms.To secure data from unwanted access, a Security module is required.
The Predictive Maintenance module is a member of the Analysis module.It is responsible for predicting the health of a component or system.It uses the cleaned input data and the Feature extraction module to generate relevant features.The KPI module provides a selection of key performance indicators that can be predicted.Predictive models are generated in the Model development module.The Validation and Model tuning ensure the model works optimally, verified using a validation dataset.When the model is working well, it can be Served, with the expectation to Monitor model performance, to continuously consider production challenges, such as data distribution changes, trainingserving skew, or data quality issues (Oladele, 2021).

Layered view
The layered view depicts the allocation of software modules into various layers based on a unidirectional "allowed-to-use" link between the layers (Richards, 2015).We decided to base our layered view on the standard of the 5C layered architecture, as described in 3.3.Fig. 6 depicts the layered 5C architecture for the DT-based PdM RA.Starting at the top, the layered view consists of a configuration layer with a machine optimization module.The Configuration layer relies on the Cognition logic layer that provides visualizations and performs risk analysis.The Cognition layer uses data from the Cyber layer.The Cyber layer contains sub-modules to create a simulation model at a certain abstraction level of the physical asset.The Cyber layer depends on the Conversion layer, which provides security, data quality, and the predictive maintenance module.The connection layer provides the Physical Twin proxy, acquisition, storage, and communication.

Validation
We used the case studies described in Section 2.2 to evaluate the RA by designing an AA.We used the AA design approach proposed by Tummers, Kassahun, & Tekinerdogan, 2021, Tummers, Tobi, et al. (2021).features from four clutches to detect anomalies.The study depicts the design of the software and tools used.We developed an AA as if the case study used a DT-based PdM system.

Feature diagram
We carefully investigated the study to detect the features implemented by (da Silva et al., 2019).As they used a PicoScope6 device to perform the data acquisition and predictive maintenance, we chose Batch acquisition and analysis.The transmission system is well-defined, and as CAD models are available, the Digital Twin may be represented using physics-based techniques.Clutch analysis was based on timeseries data, and anomalies were detected from the time domain.As the defects are clearly defined, traditional Machine Learning techniques for anomaly detection are sufficient.The feature diagram is shown in

User's view
We created a context diagram based on the available information explicitly mentioned in da Silva et al. ( 2019).There were no entities to add.We used three out of four entities from the RA.The context diagram is shown in Fig. 8.

Structured view
The package diagram extracted from da Silva et al. ( 2019) is depicted in Fig. 9.The package diagram was based on the features gathered in the section above.

Layered view
For the layered view, we designed a 5C architecture.The 5C diagram contains the high-level components and shows which level of the 5C architecture the components are located.These components may only communicate with components on the same or adjacent level.The 5C diagram is presented in Fig. 10.

Deployment view
The deployment diagram shows the two devices of the DT-based PdM system.The ClutchSystem contains components for secure communication and data acquisition of the sensors, while the Con-ditionMonitoringSystem contains the other components and replaces the PicoScope6 capabilities.The deployment diagram is presented in Fig. 11.

Case study 2: semiconductor wafer manufacturing
Cohen and Singer (2021) developed a statistical process control (SPC) for identifying abnormalities, which they applied in semiconductor wafer manufacturing.More precisely, they monitored a polishing machine to optimize the quality of the wafers (i.e., achieve the optimal thickness consistently).When the polishing quality is not optimal, the machine should be maintained, which is a predictive process maintenance example.

Feature diagram
We carefully read the study to detect the features implemented by Cohen and Singer (2021), who proposed a smart controller framework.As such, the features were well-defined.As they used a Smart Gateway module for the Industrial Internet of Things, we assumed they used a publish-subscribe architecture for communication.Furthermore, Cohen and Singer (2021) described that the SPC is a real-time system.As such, we selected Stream for data acquisition and analysis.For root-cause analysis, the authors used Machine Learning algorithms.Specifically, they used an ordinal decision tree algorithm with a depth of 3. The feature diagram is shown in Fig. 12.

User's view
We created a context diagram based on the proposed SPC framework and its main elements.We replaced Cloud Computing recourses with Industrial Internet of Things and Internet/Web.We also added Actuators.However, actuators are not typically included in the Digital Monitor pattern (Tekinerdogan & Verdouw, 2020).The context diagram is shown in Fig. 13.

Structured view
The package diagram extracted from Cohen and Singer ( 2021) is depicted in Fig. 14.The package diagram was based on the features from the feature diagram.

Layered view
For the layered view, we designed a 5C architecture.Compared to the 5C diagram of the New Holland Tractor case, this diagram also includes a Machine Optimization module on the configuration level.The 5C diagram is presented in Fig. 15.

Deployment view
The deployment diagram shows the two devices of the DT-based PdM system.The WaferPolishingSystem contains components for secure communication and data acquisition of the sensors, while the Smart-ControllerServer contains the other components and replaces the SPC capabilities.The deployment diagram is presented in Fig. 16.

Case study 3: electro-optical imaging system
We carefully investigated the study to detect the features implemented by Yu et al. (2021), who proposed a DT-based health monitoring system for an electro-optical imaging system.Yu et al. (2021) used image data to determine the health state of the electro-optical device.The image quality deteriorates over time and is the best source to monitor.Yu et al. (2021) clearly defined the software architecture of the Digital Twin, which is on a system level.(Yu et al., 2021) described that they used a hybrid Digital Twin model based on physical models and Bayesian, data-driven modeling.Furthermore, Yu et al. (2021) did not specify which communication protocol was used: "The physical system requires standard data communication devices to achieve uniform conversion of different communication interfaces or protocols and uniform packaging of data."They extracted features from the time-frequency domain using Dirichlet Process Mixture Models.At last, Yu et al. (2021) used a statistical Gaussian Particle Filter model to determine the health indicator of the electro-optical system, which was evaluated using the Mean Squared Error metric.The feature diagram is shown in Fig. 17.

User's view
We created a context diagram based on the available information explicitly mentioned in Yu et al. (2021).There were no entities to add.We leveraged all entities from the RA.The context diagram is shown in Fig. 18.

Structured view
The package diagram extracted from Yu et al. (2021) is depicted in Fig. 19.The package diagram was based on the features from the feature diagram.

Layered view
For the layered view, we designed a 5C architecture.The 5C diagram for the New Holland Tractor case has the same structure as the 5C architecture for the electro-optical system.The 5C diagram is presented in Fig. 20.

Deployment view
The deployment diagram shows the two devices of the DT-based PdM system.The ElectroOpticalDevice contains components for secure communication, data acquisition of the sensors, and data quality management.(Yu et al., 2021) describes: "data is standardized, cleaned and packaged by physical system, and then uploaded to the Digital Twin model in digital world."The Cloud contains the other components and replaces the health monitoring system capabilities.The deployment diagram is presented in Fig. 21.

General discussion
To our knowledge, this is the first RA exclusively designed for DTbased PdM systems using standardized software architecture methodologies.In this discussion, we critically reflect on our results regarding the research questions.
RQ1: What are the existing reference architectures for Digital Twin-based predictive maintenance systems?
RQ2: What is a feasible Reference Architecture for a Digital Twin-based predictive maintenance system?
We used the domain analysis information from our systematic literature review (van Dinter et al., 2022).A more comprehensive data collection with other search queries and grey literature might have introduced additional insights.However, peer-reviewed scientific articles provided a solid base for designing an RA.The results from our case studies confirm this.The feature diagram included the key components of a DT-based PdM system.
Furthermore, relevant features could be added regarding the specific needs of an application.This allows the feature model to adapt to the rapidly evolving domain of DT-based PdM systems.We identified four key entities for the context diagram based on the domain analysis.These entities were used in most of the reviewed studies.The Semiconductor Manufacturing case also showed the flexibility of the design, as we added an Actuator entity and replaced the Cloud Computing resources entity for Industrial Internet of Things and Internet/Web.RQ3: Does the Reference Architecture allow for the derivation of a specific Application Architecture?
The case studies for the derivation of AAs were based on three peerreviewed articles (Cohen & Singer, 2021;da Silva et al., 2019;Yu et al., 2021).Although they did not always explicitly name entities, features, or deployment environments, the studies contained sufficient detail to derive the diagrams and views.The use of five views to derive the AA was demonstrated.In theory, the same procedure can generate other potential perspectives (e.g., sequence diagrams, use-case diagrams).These diagrams may be designed using specific application requirements.
The RA package diagram showed its flexibility, as defining an AA feature diagram enabled an easy adaptation of the AA package diagram.The 5C architecture showed to be robust and informative of internal communication flows.However, using high-level modules caused the 5C architecture to be rather generic-the deployment views for the three AAs separate concerns for the device and its Digital Twin.However, regarding privacy concerns of high-tech enterprises, it may be considered to embed most software and its intelligence into the machine to limit the data stream that could be intercepted.In that case, it could be considered only to place a visualization module elsewhere or keep everything on the machine.

Threats to validity
Construct validity: The construct validity of the RA design determines if it accurately measures what it claims to.
The first threat is that we assumed performing Domain Analysis and Modeling using a semi-automated systematic review (van Dinter et al., 2022) would provide a complete view.As Digital Twins and predictive maintenance on their own are rapidly growing fields, each of these domains may be further researched to combine RAs.
The second threat is the selection of views.We have chosen to provide five views for this RA using (Alhir, 1998).However, the selection of which UML model to provide for each view may contain flaws.
Internal validity: Internal validity reveals biased relationships between results, leading to structural flaws.We carefully formulated each research question to determine the required approaches, methods, and techniques to design an RA for Digital Twin-based predictive maintenance systems to overcome these biases.As there are many options to design an RA for Digital Twin-based predictive maintenance systems, and the field is relatively new, we might have missed essential research questions or made assumptions about the UML views, which may be incomplete.
External validity: The external validity shows how well the RA study's outcome can be applied to other settings.We applied triangulation to apply our RA to three case studies from varying domains with moving and static components.Likely, novel Digital Twin RAs have not yet been applied with predictive maintenance modules and vice versa.These studies have not been published in the scope of Digital Twin-based predictive maintenance systems, so they have not been included in this study regardless of their potential.

Conclusion validity:
The conclusion validity measures the reproducibility of the RA design.Our study followed the RA design methodology from Tummers, Kassahun, & Tekinerdogan, 2021, Tummers, Tobi, et al. (2021).Additionally, data for the Domain Analysis was gathered from van Dinter et al. (2022), and UML standards were applied for the RA design.We deduced all conclusions from the retrieved and synthesized data based on the models to prevent subjective interpretation of the results.

Conclusion and future work
We executed this study as there was a lack of a Reference Architecture (RA) for Digital Twin-based predictive maintenance (DTbased PdM) systems based on well-established software architecture principles.In this study, we aimed to solve the challenging task of developing software architectures for predictive maintenance tasks in various application domains using the knowledge gained from a literature review.
This study demonstrated that software architecture methods could be applied to DT-based PdM systems.We proposed a high-level RA for DT-based PdM systems, which could be applied regardless of its application domain.As a result, we applied the RA to design three case study Application Architectures (AA) for New Holland Tractor clutch system monitoring, Semiconductor manufacturing polishing system anomaly detection, and Electro-optical system health monitoring.As such, this is the first study developing a domain-independent RA for DT-based PdM systems based on famous software architecture principles.A robust AA can be produced using this RA within a smaller timeframe, reducing the time-to-market.
Our future work will focus on applying our RA for DT-based PdM systems on use cases in several high-tech domains.We will mainly focus on the maintenance of the Dutch Mid-Voltage electricity network, and the maintenance of assets for semiconductor manufacturing.The insights gathered from the implementation of the framework will lead to further improvements due to iterative design changes.Furthermore, the next step of our future work will focus on developing design patterns for digital twins-based predictive maintenance systems.These can regard available data, the challenge to solve, or the type of asset or maintenance.These two studies should support industry professionals with faster time to market for developing robust predictive maintenance systems.

R
.van Dinter et al.

R
.van Dinter et al.

R
.van Dinter et al.

Fig. 8 .
Fig. 8. Context diagram for the New Holland Tractor Digital Twin-based predictive maintenance system based on da Silva et al. (2019).

Fig. 9 .
Fig. 9. Package diagram for the New Holland Tractor Digital Twin-based predictive maintenance system based on da Silva et al. (2019).

Fig. 10 .
Fig. 10.5C architecture for the New Holland Tractor Digital Twin-based predictive maintenance system based on da Silva et al. (2019).

R
.van Dinter et al.

Fig. 11 .
Fig. 11.Deployment diagram for the New Holland Tractor Digital Twin-based predictive maintenance system based on da Silva et al. (2019).

Fig. 12 .
Fig. 12. Feature diagram for the semiconductor wafer manufacturing Digital Twin-based predictive maintenance system based on Cohen and Singer (2021).

R
.van Dinter et al.

Fig. 13 .
Fig. 13.Context diagram for the semiconductor wafer manufacturing Digital Twin-based predictive maintenance system based on Cohen and Singer (2021).

Fig. 14 .
Fig. 14.Package diagram for the semiconductor wafer manufacturing Digital Twin-based predictive maintenance system based on Cohen and Singer (2021).

Fig. 15 .
Fig. 15.5C architecture for the semiconductor wafer manufacturing Digital predictive maintenance system based on Cohen and Singer (2021).

Fig. 16 .
Fig. 16.Deployment diagram for the semiconductor wafer manufacturing Digital Twin-based predictive maintenance system based on Cohen and Singer (2021).

R
.van Dinter et al.

Fig. 18 .
Fig. 18.Context diagram for the electro-optical imaging Digital Twin-based predictive maintenance system based on Yu et al. (2021).

Fig. 19 .
Fig. 19.Package diagram for the electro-optical imaging Digital Twin-based predictive maintenance system based on Yu et al. (2021).

Fig. 20 .
Fig. 20.5C architecture for the electro-optical imaging Digital Twin-based predictive maintenance system based on Yu et al. (2021).

R
.van Dinter et al.

Fig. 21 .
Fig. 21.Deployment diagram for the electro-optical imaging Digital Twin-based predictive maintenance system based on Yu et al. (2021).