Multiple aspects maintenance ontology-based intelligent maintenance optimization framework for safety-critical systems

Abstract

Maintenance optimization is a process for improving the efficiency of maintenance strategies and activities, considering various aspects of the target system and components, such as the probabilities of system failures and the cost of repair and replacement of a failed component. The improvement of maintenance optimization algorithms generally requires information from various data sources. For example, it may require the system risk information derived from risk analysis tools or the residual lifetime of a component from fault prognosis tools. The requirements of data acquisition (DAQ) and aggregation pose new challenges for maintenance management systems (MMSs) that implement and use these maintenance optimization algorithms. This paper proposes a multiple aspects maintenance ontology-based framework to facilitate DAQ from MMSs, online monitoring systems, fault detection and discrimination tools, risk assessment tools, decision-making tools, and component identification tools, and accelerate the implementation and verification of contemporary maintenance optimization models and algorithms. The proposed framework consists of a multi-aspect maintenance ontology with critical information for maintenance optimization and application interfaces for collecting information from various data sources, such as fault prognosis tools, online monitoring tools, risk assessment tools, and decision-making algorithms. In addition, this paper proposes a heuristic method for integrating concepts and properties from other existing ontologies into the proposed framework when the existing ontology is not fully compatible with the ontology under construction. Finally, the paper verifies the proposed ontology framework using a feedwater system designed for nuclear power plants with valves and filters as the components under maintenance.

Introduction

Safety-critical systems are systems whose failure will cause catastrophic consequences, such as massive property damage or fatalities. Safety-critical systems are commonly used in modern industrial systems, such as flight control systems in airplanes and cooling systems in nuclear power plants (NPPs). Component or structure degradations and failures during the operation of such systems may significantly impact the functions implemented by such components and subsequently increase the risk of system failures and catastrophic consequences. System maintenance activities aim to keep system components reliable and functional, which is essential for the long-term, safe, and economic operation of industrial systems. However, maintenance activities usually are faced with challenges, such as being time-consuming and costly. Therefore, optimization is required to reduce maintenance activities’ expenses and maintain system outages to a minimum. The optimization process should ensure that the most appropriate type of maintenance is performed on system, structure, and components (SSCs) and determine at which periodicity maintenance should be performed on account of regulatory requirements and maintenance targets related to safety, reliability, availability, and cost (IAEA, 2018).

As a modern maintenance optimization methodology, condition-based maintenance (CBM) collects and assesses real-time information and recommends maintenance decisions based on the current operational condition of the target system (Alaswad and Xiang, 2017). Many CBM models have been proposed (Sharma et al., 2011), such as the hidden Markov process model (Zhao and Smidts, 2022), the Wiener process model (Guo et al., 2013), and the Gamma process model (Yuan et al., 2021). However, the mathematical models cannot be applied without real-time data collected from system operations, failures, modifications, and costs (Sharma et al., 2011). As an example, these models require data from condition monitoring to identify the state of system functions (e.g., operating or failed) and components (e.g., on or off) (de Jonge and Scarf, 2020). Therefore, several maintenance optimization algorithms are developed (Kobbacy, 2004) to implement the CBM models designed for various specific industrial systems. These optimization algorithms and their implementations provide interfaces for collecting monitoring data from various sources as model inputs, running algorithms for evaluating the effectiveness and cost of maintenance activities and making decisions, and interacting with existing maintenance management systems (MMSs) for maintenance work order deployment and maintenance model evaluation (Lee et al., 2020).

Nevertheless, developing a maintenance optimization system requires us to overcome several challenges. These challenges are becoming more severe as the variety and complexity of CBM models increase (Apeland and Aven, 2000; Alaswad and Xiang, 2017). Existing optimization systems only focus on one or two aspects of maintenance, such as security and economic loss (Gu et al., 2009) or making decisions based on fault prognosis (Wang et al., 2006).

This paper implements an ontology-based framework to bridge the gap between the maintenance optimization models and their implementations. This framework facilitates model applications for maintenance optimization by unifying the concepts and algorithms used by models and industrial applications, providing interfaces to the modules required by the maintenance optimization process, and automatically routing required data to these modules. The following list summarizes the contributions of this paper.

• • An MuAMO with unified concepts and properties required by maintenance optimization considering multiple aspects, such as SSCs, monitoring data, system risk, and decision-making. The proposed ontology serves as a knowledge repository with generic and specific information for running various maintenance optimization models.

• • An ontology-based framework for implementation and evaluation of maintenance optimization models. The optimization system developers do not need to repeatedly adapt the optimization models for different target systems. Using the unified concepts and measures defined by MuAMO, various optimization models can be quickly integrated into the proposed framework and applied to various specific systems. In addition, the proposed framework can automatically infer the models with the best fitness for the target component or system. The satisfaction of preconditions defined for different optimization models can be verified automatically by the ontology build-in solvers.

• • A series of application interfaces for integrating with other information resources. Generally, a maintenance optimization algorithm requires various system information, such as system structures, configurations, failure modes, and real-time monitoring data from sensors and data acquisition systems. As an information aggregation platform, the proposed framework includes interfaces designed and implemented for collecting information from third-party tools that provide the information required by the maintenance optimization algorithms.

• • A heuristic method to extend the existing ontology and integrate it with other domain ontologies. To efficiently enrich the concepts and properties of MuAMO, we propose a heuristic method for ontology integration. Specifically, the proposed method can minimize the hierarchical changes to the classes in existing ontologies.

In the following sections, the “Related work” section introduces related work which has used ontologies for maintenance optimization. The “Overview” section overviews the structure of the proposed framework. The development methodology and process used to develop MuAMO are detailed in the “Ontology development methodology” section. The “Ontology framework” section details the algorithms used by the framework to perform maintenance optimization in real time. The “Implementation” section discusses the implementation of the framework. The “Case study” section uses two components in a feedwater system for an NPP as the case study. The “Discussion” section describes the use of the proposed framework. The “Conclusion” section concludes the paper.

Related work

“An ontology is an explicit specification of a conceptualization” (Gruber, 1993). As an effective way for standardizing and sharing information, ontologies have become increasingly valuable tools in computer science for their utility in enabling a thorough and well-defined discourse and for building logical models of systems. Ontology has been applied to various system engineering processes, such as collaborative assembly design (Kim et al., 2009), engineering knowledge modeling (Harrison and Chan, 2009) and maintenance (Ajit et al., 2008), and project management (Wu et al., 2021). However, these ontologies are developed for the development stages of industrial systems and cannot support the tasks performed in the maintenance stage.

For system maintenance and optimization, some ontologies were developed for specific industrial fields. For example, Elhdad et al. (2013) proposed an ontology for process monitoring and maintenance in petroleum plants. The proposed ontology can enhance maintenance decisions based on the knowledge gathered through the process of monitoring. This monitoring process is based on signals which are triggered during the plant safety shutdown process. The proposed ontology is extended to ensure that decision-makers have sufficient information to make the right decision at the right time. Ebrahimipour and Yacout (2015) developed an ontology-based schema to support maintenance knowledge representation for physical components. The schema can overcome the problems of heterogeneity and inconsistency in maintenance records. A bond graph model is employed to model the structure of equipment functions involved in fault propagation at the part-component level. In addition, this method provides a generic technical understanding, which enriches semantic extraction and knowledge discovery in a typical maintenance report. Anquetil et al. (2006) developed an ontology for software maintenance optimization. They defined two common maintenance scenarios and considered the industrial issues associated with them. Campos (2007) proposed an ontology for asset management for mechanical systems. The ontology records the data structure and information needed for the maintenance management of the industrial assets with their objects, attributes, and relationships. Dimitrova et al. (2020) developed PADTUN, a novel intelligent decision support system that assists with pathology diagnosis and assessment of tunnels with respect to their disorders and diagnosis influencing factors. Nevertheless, these ontologies are designed for specific industrial fields or for a specific type of industrial systems.

For the purposes of generalization, the industrial maintenance management ontology (Karray et al., 2012) was developed for industrial maintenance, ensuring semantic interoperability and generating new knowledge that supports decision-making in the maintenance process. ROMAIN (Karray et al., 2019) is a domain-specific ontology for the maintenance management domain. It constrains the classes that are unique to the maintenance management practice, such as maintenance strategy, degradation, and work order management. Emmanouilidis et al. (2020) conducted a study of maintenance ontologies from the viewpoint of reliability-oriented context information management and proposes a baseline context information management ontology aligned with the needs of maintenance services for connected production machines. This ontology is applied on an industrial case study relevant to maintenance services for a distributed fleet of connected industrial printers. Canito et al. (2021) proposed an ontology to bridge the gap between data sampling from different types of sensors and equipment for predictive maintenance. It also provides interface for machine learning algorithms to train data mining models. Table 1 compares the existing ontologies or methodologies recently designed for system maintenance in terms of features important to this paper’s maintenance optimization, such as the maintenance activities, assets, failures, risk, and cost. From the table, we can observe that none of these ontologies are able to cover all the aspects considered in the proposed ontology MuAMO.

Table 1. Literature comparison of the ontologies related to maintenance optimization (IMAMO: industrial maintenance management ontology; MuAMO: multiple aspects maintenance ontology; ROMAIN: a domain-specific ontology for the maintenance management)

MuAMO is the methodology/ontology proposed in this paper.

Framework and methodology

Overview

The objective of the maintenance ontology framework is to facilitate the development of a maintenance optimization system that requires information from various data sources. Figure 1 describes the methodology used for achieving the proposed target. This section first introduces the ontology development methodology used for establishing the maintenance ontology framework. The method proposed for creating classes and properties is based on existing standards and reports. Also, this section includes a method to integrate existing ontologies into the proposed framework. The outcome of the introduced ontology development method is the maintenance ontology framework with its associated views. This section details the classes and properties defined for each view (see the “Ontology framework” section) and then introduces the use of the proposed framework in the “Implementation” section, in which the related algorithms and interfaces are discussed, and the queries generated for eliciting required information are explained.

Figure 1. Roadmap of the paper.

Ontology development methodology

The ontology development methodology defines the steps and the pathway to design, implement, and verify a domain-specific ontology. This paper refers to and adjusts some mature ontology engineering methods that are already applied in other industrial domains (López et al., 1999; El-Diraby, 2013; Chantrapornchai and Choksuchat, 2016; Kethavarapu and Saraswathi, 2016; Qu et al., 2016). In Steps II and III, a heuristic methodology for defining and integrating ontologies is detailed since they are part of contributions of this paper. The development of the proposed maintenance ontology follows an ontology engineering approach which includes the following steps (Noy and Mcguinness, 2017).

Step I. Determine the domain and scope of the ontology

Generally, an ontology is developed to solve a series of problems for a specific type of target system or a specific domain, and the competency questions are used to define the requirements for the ontology, that is, the competency questions are the necessary questions the ontology needs to answer (Noy and Mcguinness, 2017). Therefore, this paper defines the domain of the proposed ontology as supporting maintenance optimization and related activities.

We also defined the competency questions that the proposed ontology needs to answer. These competency questions are used as necessary criteria for verifying the completeness of the proposed ontology in the “Case study” section. Since the objective of the proposed ontology is to facilitate the development of a maintenance optimization system, the following competency questions are defined, derived from our understanding of industry needs and that should be answered by maintenance optimization systems:

• • To decrease the risk of the target system, what is the most efficient maintenance activity (MEMA)?

• • Considering maintenance costs and system risks, what is the most critical part of the target system/component?

• • What is the maximum achievable improvement of system safety in terms of all feasible maintenance activities given a specific budget?

Step II. Consider reusing existing ontologies

Many domain ontologies have been developed to solve knowledge representation and sharing issues. Reusing existing ontologies can save time and maximize compatibility with other existing ontologies. However, reusing terms in one domain may cause inconsistencies or even contradictions since the terms commonly used in different domains may have different meanings and explanations.

Table 2 summarizes the advantages and disadvantages of reusing existing ontologies. This paper balances these advantages and disadvantages when investigating and integrating existing ontologies into MuAMO.

Table 2. The advantages and disadvantages of reusing existing ontologies

By considering the problems that may be encountered as discussed above, existing ontologies are carefully evaluated to ensure their compatibility with the field of maintenance. Table 3 summarizes the domain ontologies considered for reuse in the proposed maintenance ontology framework. It is worth noting that upper-level ontologies are also investigated for consideration in the proposed ontology since these ontologies provide meta-concepts and properties useful for bridging concepts defined in different domain ontologies.

Table 3. Domain ontologies considered for reuse

In recent years, researchers have provided many ontologies for conceptualizing and sharing knowledge between research domains, such as the basic formal ontology (BFO) (Smith, 1998), the suggested upper merged ontology (Niles and Pease, 2001), and the descriptive ontology for linguistic and cognitive engineering (Gangemi et al., 2003). Since most of the reused ontologies are compatible with BFO, the proposed framework will also be built based on BFO (Smith, 1998).

Since some of the ontologies do not use BFO (Smith, 1998) as their meta-ontology (i.e., some of the ontologies are not compatible with BFO), the existing ontology integration methods are not applicable; hence, reusing and integrating the concepts and relations in such ontologies requires extra efforts to prevent inconsistencies and conflicts. This paper proposes an expert-aided incremental method to integrate portions of the existing domain ontologies into the proposed ontology (MuAMO). To minimize the changes in the relations between the concepts in MuAMO and the concepts in the integrated ontology, we propose a heuristic method for ontology integration. The following definitions are required by the method.

Assume that the ontology of the proposed framework $ \mathbf{\mathcal{O}}=\left\{\mathbf{\mathcal{C}},\mathbf{\mathcal{R}}\right\} $ contains a set of concepts $ \mathbf{\mathcal{C}}=\left\{{c}_1,\dots, {c}_m\right\} $ (i.e., classes) and properties $ \mathbf{\mathcal{R}}=\left\{{r}_1,\dots {r}_n\right\} $ (i.e., links), where c represents a class and r represents a property (i.e., a link). If we restrict $ \mathbf{\mathcal{R}} $ as the set of all “is_a” links between two classes, the notation $ r\left({c}_i,{c}_j\right) $ or $ {r}_{i,j} $ denotes that a “is_a” link exists between class $ {c}_i $ and class $ {c}_j $ , that is, class $ {c}_i $ is the parent class of class $ {c}_j $ .

Definition 1. Function $ \mathcal{L}\left({c}_i,{c}_j\right) $ _: $ \mathbf{\mathcal{C}}\times \mathbf{\mathcal{C}}\to \mathbf{\mathcal{R}} $ returns the set of links R which start from $ {c}_i $ and end at $ {c}_j $ . Based on this definition, the notation $ \mathcal{L}\left({c}_i,\ast \right) $ represents the set of links starting from $ {c}_i $ and $ \mathcal{L}\left(\ast, {c}_j\right) $ represents the set of links ending at $ {c}_j $ .

Definition 2. Function $ \mathcal{D}\left({c}_i\right) $ : $ \mathbf{\mathcal{C}}\to \mathbf{\mathcal{C}} $ returns the descendants of class $ {c}_i $ . The descendants include all the subclasses of class $ {c}_i $ , all the subclasses of these subclasses, and so on.

Definition 3. Function $ {\mathcal{D}}_{\mathcal{S}}\left({c}_i\right) $ : $ \mathbf{\mathcal{C}}\to \mathbf{\mathcal{C}} $ returns the direct descendants (children) of class $ {c}_i $ . The direct descendants include only the subclasses of class $ {c}_i $ .

Definition 4. Function $ \mathcal{U}\left({c}_i\right) $ : $ \mathbf{\mathcal{C}}\to \mathbf{\mathcal{C}} $ returns the ancestors of class $ {c}_i $ . The ancestors include all the parent classes of class $ {c}_i $ , all the parent classes of these parent classes, and so on.

Definition 5. Function $ {\mathcal{U}}_{\mathcal{S}}\left({c}_i\right) $ : $ \mathbf{\mathcal{C}}\to \mathbf{\mathcal{C}} $ returns the direct ancestors (parents) of class $ {c}_i $ .

Definition 6. Top Nodes $ \mathcal{T}(C) $ return the set of top classes in the class set $ C $ so that $ \forall c\in C,\hskip0.35em c\in \mathcal{T}(C) $ if $ {\mathcal{U}}_{\mathcal{S}}(c)=\varnothing $ .

Definition 7. Block $ B=\left\{C,R\right\},C\subseteq \mathbf{\mathcal{C}},R\subseteq \mathbf{\mathcal{R}},\mathcal{L}\left({c}_i,{c}_j\right)\ne \varnothing $ , where $ {c}_i\in C,{c}_j\in C,{c}_i\ne {c}_j $ . The notation means that all the classes in a block are linked, that is, there is at least one link starting from or ending at every concept. Generally, an ontology $ \mathbf{\mathcal{O}} $ can be divided into various block set $ \mathbf{\mathcal{B}}=\left\{{B}_1,\dots, {B}_l\right\} $ . For each $ {B}_i $ in $ \mathbf{\mathcal{B}},\mathcal{T}\left({B}_i\right)=\left\{{c}_T\right\} $ has only one element which is the top class in block $ {B}_i $ .

Definition 8. Minmax block set $ {\mathbf{\mathcal{B}}}_{\boldsymbol{M}} $ is a block set in which there is no link between the concepts belonging to different blocks. $ {\mathbf{\mathcal{B}}}_{\boldsymbol{M}}=\left\{{B}_1,\dots, {B}_l\right\},\hskip0.35em \mathcal{L}\left({c}_i,{c}_j\right)=\varnothing, \hskip0.35em {c}_i\in {B}_x,\hskip0.35em {c}_j\in {B}_y,{B}_x\in {\mathbf{\mathcal{B}}}_{\boldsymbol{M}},{B}_y\in {\mathbf{\mathcal{B}}}_{\boldsymbol{M}},x\ne y $ .

Assume that the new ontology with new concepts and links $ {\mathbf{\mathcal{O}}}^{\prime }=\left\{{\mathbf{\mathcal{C}}}^{\prime },{\mathbf{\mathcal{R}}}^{\prime}\right\} $ will be integrated into the ontology $ \mathbf{\mathcal{O}}=\left\{\mathbf{\mathcal{C}},\mathbf{\mathcal{R}}\right\} $ . The Minmax block set of the new ontology $ {\mathbf{\mathcal{O}}}^{\prime } $ is $ {\mathbf{\mathcal{B}}}_{\boldsymbol{M}}^{\prime }=\left\{{B}_1^{\prime },\dots, {B}_l^{\prime}\right\} $ . Then the integration process can be classified into the following cases.

Case 1, for each $ {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ in $ {\mathbf{\mathcal{B}}}_{\boldsymbol{M}}^{\prime } $ , no common class between $ {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ and $ \mathbf{\mathcal{C}} $ exists, that is, .

In this case, the top class $ \mathcal{T}\left({B}_i^{\prime}\right) $ is selected first to be integrated into the ontology $ \mathbf{\mathcal{O}} $ . Expert knowledge is required in this step to identify the concept $ {c}_0 $ that is closely related to the top class $ \mathcal{T}\left({B}_i^{\prime}\right) $ and add the top class as the subclass of $ {c}_0 $ by adding the relation $ r\left({c}_0,T\left({B}_i^{\prime}\right)\right) $ . Then the other classes and relations in $ {B}_i^{\prime } $ can be added into the ontology $ \mathbf{\mathcal{O}} $ . For example, Figure 4 displays the block of classes $ {B}_i^{\prime } $ that will be integrated into the existing ontology. The block $ {B}_i^{\prime }=\left\{{C}^{\prime },{R}^{\prime}\right\} $ contains six classes $ {C}^{\prime }=\left\{{c}_1^{\prime },\dots, {c}_6^{\prime}\right\} $ and their relations $ {R}^{\prime }=\left\{{r}_{1,2}^{\prime },{r}_{1,3}^{\prime },{r}_{2,4}^{\prime },{r}_{2,5}^{\prime },{r}_{3,6}^{\prime}\right\} $ . The top class $ T\left({B}_i^{\prime}\right)=\left\{{c}_1^{\prime}\right\} $ .

In this case, the top class $ {c}_1^{\prime } $ will be integrated into the ontology $ \mathbf{\mathcal{O}}\hskip0.35em $ first by using expert knowledge. As shown in Figure 5, the class $ {c}_3 $ is selected as the parent class of $ {c}_1^{\prime } $ , and then the relation $ r\left({c}_3,{c}_1^{\prime}\right) $ is added into the ontology $ \mathbf{\mathcal{O}} $ . Finally, the set of classes and relations of block $ {B}_i^{\prime } $ are added into the ontology $ \mathbf{\mathcal{O}} $ .

It is worth noting that the class $ {c}_1^{\prime } $ will never be the top class of the ontology $ \mathbf{\mathcal{O}} $ since the ontology $ \mathbf{\mathcal{O}} $ defined by the propose framework uses BFO (Smith, 1998) as the meta-ontology which defines “Thing” as the top class.

Case 2, a common class $ {\boldsymbol{c}}_{\mathbf{1}}^{\prime } $ exists between $ {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ and $ \mathbf{\mathcal{C}},{C}^{\prime}\cap \mathbf{\mathcal{C}}=\left\{{\boldsymbol{c}}_{\mathbf{1}}^{\prime}\right\},{C}^{\prime}\in {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ .

This case can be further classified as $ \left\{{c}_1^{\prime}\right\}=\mathcal{T}\left({B}_i^{\prime}\right) $ and $ \left\{{c}_1^{\prime}\right\}\ne \mathcal{T}\left({B}_i^{\prime}\right) $ .

• • Case 2.1, $ \left\{{\boldsymbol{c}}_{\mathbf{1}}^{\prime}\right\}=\mathbf{\mathcal{T}}\left({\boldsymbol{B}}_i^{\prime}\right). $ In this case, the other classes $ \left\{{c}_2^{\prime },\dots, {c}_6^{\prime}\right\} $ and relations in $ {B}_i^{\prime } $ can be added into the ontology $ \mathbf{\mathcal{O}} $ following the procedure in Case 1. As shown in Figure 6, the class $ {c}_1^{\prime } $ is the common class that exists both in $ {C}^{\prime } $ and $ \mathbf{\mathcal{C}} $ . Then the block $ {B}_i^{\prime } $ is integrated into $ \mathbf{\mathcal{C}} $ without the changes of relations between the classes in $ {C}^{\prime } $ and $ \mathbf{\mathcal{C}} $ .

• • Case 2.2, $ \left\{{\boldsymbol{c}}_{\mathbf{1}}^{\prime}\right\}\ne \mathbf{\mathcal{T}}\left({\boldsymbol{B}}_{\boldsymbol{i}}^{\prime}\right) $ . In this case, if we define the block with class $ {c}_1^{\prime } $ as $ {B}_{i_0}^{\prime } $ and the other derived blocks as $ {B}_{i_1}^{\prime },\dots, {B}_{i_n}^{\prime } $ , then we can add $ {B}_{i_0}^{\prime } $ into ontology $ \mathbf{\mathcal{O}} $ using the method in Case 2.1 and add the other blocks $ {B}_{i_1}^{\prime },\dots {B}_{i_n}^{\prime } $ using the method in Case 1. As shown in Figure 7, $ {c}_2^{\prime } $ is the common class with $ \mathbf{\mathcal{C}} $ , but $ {c}_2^{\prime } $ is not the top class of $ {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ . In this case, the link $ {r}_{1,2}^{\prime } $ is pruned, and the descendants of $ {c}_2^{\prime } $ are added into $ \mathbf{\mathcal{C}} $ . Then the new block with $ {c}_1^{\prime } $ and its descendants are integrated by using the method in Case 1. In this example, $ {c}_1^{\prime } $ is added as the child class of $ {c}_1 $ .

Case 3, more than one common classes exist between $ {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ and $ \mathbf{\mathcal{C}},{C}^{\prime}\cap \mathbf{\mathcal{C}}=\left\{{\boldsymbol{c}}_{\mathbf{1}}^{\prime },\dots, {\boldsymbol{c}}_{\boldsymbol{t}}^{\prime}\right\},{C}^{\prime}\in {\boldsymbol{B}}_{\boldsymbol{i}}^{\prime } $ .

• • Case 3.1, $ \nexists {\boldsymbol{r}}^{\prime}\left({\boldsymbol{c}}_{\boldsymbol{i}}^{\prime },{\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\right),\hskip0.35em {\boldsymbol{c}}_{\boldsymbol{i}}^{\prime}\in \boldsymbol{C},\hskip0.35em {\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\in \boldsymbol{C},\hskip0.35em \boldsymbol{r}\left({\boldsymbol{c}}_{\boldsymbol{i}}^{\prime },{\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\right)\in \mathbf{\mathcal{R}} $ . In this case, no common link exists in both $ {B}_i^{\prime } $ and $ \mathbf{\mathcal{O}} $ . We can break the links $ \mathcal{L}\left(\ast, {c}_i^{\prime}\right),{c}_i^{\prime}\in \boldsymbol{C} $ and generate new blocks. For each new block, we can use the methods in Case 2. Figure 8 shows an example of this case.

• • Case 3.2, $ \exists {\boldsymbol{r}}^{\prime}\left({\boldsymbol{c}}_{\boldsymbol{i}}^{\prime },{\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\right),\hskip0.35em {\boldsymbol{c}}_{\boldsymbol{i}}^{\prime}\in \boldsymbol{C},\hskip0.35em {\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\in \boldsymbol{C},\boldsymbol{r}\left({\boldsymbol{c}}_{\boldsymbol{i}}^{\prime },{\boldsymbol{c}}_{\boldsymbol{j}}^{\prime}\right)\in \mathbf{\mathcal{R}} $ . In this case, there is at least one common link existing in both $ {B}_i^{\prime } $ and $ \mathbf{\mathcal{O}} $ . Since $ {c}_i^{\prime },{c}_j^{\prime } $ , and $ {r}_{i,j}^{\prime } $ are already in ontology $ \mathbf{\mathcal{O}} $ , we can break the link $ \mathcal{L}\left(\ast, {c}_j^{\prime}\right) $ and add the derived blocks using the methods in Case 2. Figure 9 shows an example of this case.

Figure 2. Architecture of the ontology-based maintenance optimization framework.

Figure 3. Dependencies between the views of the proposed framework.

Figure 4. Example block that will be integrated into the existing ontology.

Figure 5. Example of Case 1.

Figure 6. Example of Case 2.1.

Figure 7. Example of Case 2.2.

Figure 8. Example of Case 3.1.

Figure 9. Example of Case 3.2.

Step III. Enumerate important terms in the ontology

Since the proposed ontology is used to model and manage knowledge for maintenance optimization, the important terms describing concepts and relations related to this target need to be included in the proposed ontology. This step collects and determines the important terms widely used in the target domain. These terms are collected from several industry standards and reports that domain experts and researchers commonly accept. In this paper, the importance of these terms is evaluated by the experts. In the future, natural language processing tools can be reused in this step.

The following content describes the steps of the methodology used for collecting information from these documents.

Step III.1. Locate descriptions of key concepts, definitions, restrictions, or dependencies in the target document.

Step III.2. Select the terms denoting the key concepts or relations in the target domain.

Step III.3. Iterate on the selected terms $ {w}_0 $ :

• • Step III.3.1. For each noun, compare it with the classes $ \mathbf{\mathcal{C}} $ already in the ontology $ \mathbf{\mathcal{O}} $ . If the selected term $ {w}_0 $ has the same meaning as a class $ {c}_i $ already defined by the ontology $ \mathbf{\mathcal{O}} $ , link the selected term as an alias of the class alians $ \left({w}_0,{c}_i\right) $ . Otherwise, from the ontology $ \mathbf{\mathcal{O}} $ , find a class $ {c}_i $ whose meaning is closest to the new term and define the new term as a subclass of it $ \mathcal{L}\left({c}_i,{w}_0\right)=\left\{r\left({c}_i,{w}_0\right)\right\} $ .

• • Step III.3.2. For each verb, compare it with the links $ \mathbf{\mathcal{R}} $ already in the ontology $ \mathbf{\mathcal{O}} $ . If the selected term has the same meaning as a link $ {r}_{i,j} $ already defined by the ontology $ \mathbf{\mathcal{O}} $ , define the selected term as an alias of the link alians $ \left({w}_0,{r}_{i,j}\right) $ . Otherwise, if the subject(s) and the object(s) of the verb, that is, the concepts $ {c}_i $ and $ {c}_j $ related to the link, are already in the ontology $ \mathbf{\mathcal{O}} $ , then add the new link to the ontology $ \mathbf{\mathcal{O}},\mathcal{L}\left({c}_i,{c}_j\right)=\left\{{r}_{i,j}\right\} $ . If one or more of the related concepts are not defined in the ontology $ \mathbf{\mathcal{O}} $ , repeat Step III.3.1 for adding the missing concepts.

• • Step III.3.3. If a rule or constraint is defined by a link of some concepts, an axiom represented by the Semantic Web Rule Language (SWRL) (Horrocks et al., 2004) will be defined since some complex relations cannot be represented by adding a new link.

For example, the following sentence is extracted from a maintenance optimization document and is selected since it contains key concepts and relations in the maintenance domain.

“Maintenance techniques can also check the status of components that are not malfunctioning and seek to increase the interval of inspection.”

The key terms “Maintenance techniques,” “components,” “status of components,” “malfunctioning,” “inspection,” “interval of inspection,” “check,” “seek,” and “increase” are included in the sentence. According to the methods introduced above, the terms “Maintenance technique” and “component” are already defined in the proposed framework. The term “status of component” is defined as an alias of “state of component,” and the term “malfunctioning” is defined as an alias of “failure.” The term “inspection” is defined as a child class of “Maintenance activity,” and the term “interval of inspection” is already defined by the class “Maintenance time interval” based on expert’s knowledge. The term “check” builds the relationship between the concepts “maintenance technique” and “status of components” initially. But later this relationship is revised to be the link between the concepts “maintenance team” and “maintenable item” in Step III. The terms “seek” and “increase” are pruned since these relations are already represented by other links in the proposed ontology.

Step III.4. Refine the established ontology

• • Step III.4.1. Remove contradictions or inconsistencies by using the ontology built-in reasoners (e.g., HermiT; Glimm et al., 2014). (Inconsistencies may exist between different documents; some terms in the nuclear power field may be inconsistent with the ones in other fields.)

• • Step III.4.2. If there are too many direct subclasses of a class, then add more intermediate classes to optimize the ontology hierarchy.

• • Step III.4.3. Eliminate redundant classes, properties, or axioms and revise inappropriate classes, properties, or axioms based on expert’s knowledge, if applicable.

Step III.5. Validate the established ontology. Check if all the key concepts, rules, and constraints have been covered. This step is usually completed by domain experts.

The current method depends on experts’ judgment to determine which terms are important. Usually, an important concept or relation will appear multiple times in a standard or document. Experts can select the sentences or paragraphs that contain the key concepts, definitions, restrictions, or dependencies described using nouns or verbs. If there is no sentence or paragraph that describes the important concepts, definitions, restrictions, or dependencies using nouns or verbs, the experts can rewrite that sentence or paragraph and then apply the proposed method.

Table 4 describes the referenced documents to which we applied the methodology described above for establishing the proposed ontology MuAMO. It is worth noting that some documents in the nuclear field are being referenced since the case study system used in this paper is a safety-critical system designed for NPPs. The methodology mentioned above can be applied to other industrial fields as well.

Table 4. Documents referenced by the proposed ontology (NPP: nuclear power plant; PRA: probabilistic risk assessment)

This section identifies the terms and relations that need to be integrated into the proposed ontology. The following subsections perform the integration in which the corresponding classes, properties and facets, are defined.

Step IV. Define classes, properties and facets

Several terms and concepts are collected by applying the information collection methodology (see the “Step II. Consider reusing existing ontologies” and “Step III. Enumerate important terms in the ontology” sections) to the industrial standards and guidelines, and their corresponding ontology classes are established. The “Ontology framework” section details the classes defined for the views in MuAMO based on the methodologies introduced above.

The properties and facets link the classes established in MuAMO and define constraints for using these classes. MuAMO reuses several properties defined by the existing ontologies, for example, fault ontology (Diao et al., 2022), ROMAIN (Karray et al., 2019), and information artifact ontology (Ceusters, 2012). Due to the page limitation, these properties are not presented in this paper.

Step V. Create instances

Creating instances for an ontology is applying the ontology to a practical problem. The “Case study” section details the instances of the concepts and properties introduced in this paper to demonstrate the proposed ontology’s capability and complete the validation.

Ontology framework

Based on the aforementioned methodology, an ontology framework can be created to collect, represent, manage, and maintain the knowledge that will be used, synthesized, inferred, and verified during the maintenance optimization process. Figure 2 illustrates the architecture of the maintenance ontology framework with its related external tools or algorithms. In the figure, the proposed maintenance optimization framework consists of MuAMO, the maintenance optimization ontology, and several interfaces (labeled by IF). The concepts in the proposed ontology are categorized into six views, including the asset and component view (ACV), the function and failure view (FFV), the online monitoring view (OMV), the risk assessment view (RAV), the decision-making view (DMV), and the maintenance management view (MMV). Knowledge and information will be shared between these views. One view may include several concepts that depend on the concepts included in other views. As an example of these dependencies, the maintenance costs included by various maintenance strategies and the system risk caused by system failures, recorded by the MMV and the RAV, respectively, are required by the reward function of algorithms included in the DMV to select the MEMA. In the proposed framework, the failures of system components and the maintenance activities are correlated through the concepts related to risk assessment. In detail, the failures of system components are quantified by their probabilities and further quantified by the risk caused by these failures. On the other hand, maintenance activities will impact the failure rates of the components under maintenance and further impact the risk after each maintenance activity. However, the proposed framework implemented the information flow through these concepts and recorded/updated the corresponding information in real time. The quantification involved in the information flow, such as the calculation of the failure rates of the components under maintenance, is performed by external tools. This mechanism provides flexibility in the integration of various tools related to maintenance optimization.

Each view in the framework possesses an application programming interface (API) that implements the communications between the proposed ontology and other external tools or algorithms. Figure 3 uses a portion of the critical concepts contained in each view to depict the dependencies between views. Besides the reused classes from other ontologies, Table 5 lists some of the critical classes defined in the proposed ontology MuAMO.

Table 5. Critical classes defined for the proposed framework (DAQ: data acquisition)

Implementation

Tools and interfaces

The proposed ontology is implemented using Protégé (Musen, 2015), an open-source ontology editor with built-in description logic reasoners. Figure 13 is a screenshot of the tool. Protégé supports the SWRL (Horrocks et al., 2004) for defining complex constraints. This research utilizes Protégé to reuse the existing ontologies, add and manage new concepts, and check for inconsistencies that may occur during the insertion of new concepts and properties.

Figure 10. Algorithm of maintenance optimization process using the ontology repository.

Figure 11. Algorithm for obtaining failure information.

Figure 12. Algorithm for obtaining risk information.

Figure 13. Screenshot of the ontology editor Protégé.

The interfaces of the proposed framework are implemented using the Python programming language and the OWLReady2 library (Lamy, 2017). OWLReady2 provides packages for modifying and saving ontologies and performing reasoning. The library has been optimized for managing an ontology repository with a large number of classes and instances. OWLReady2 uses HermiT (Glimm et al., 2014) as a default reasoner. In addition, this library also includes an efficient API for connecting to external databases. Several technical solutions, such as pipelines, network sockets, or file systems, can be used with the APIs provided by the proposed framework to implement the interactions with external tools. For example, a reinforcement learning-based maintenance optimization algorithm (Zhao and Smidts, 2022) can be executed in a process running in parallel with the proposed framework. By using the APIs of the proposed framework, a well-formatted file can be generated, which includes all the parameters required by the optimization algorithm (e.g., the information on components and online monitoring data). The proposed framework can automatically prepare the required file and launch the algorithm. After the execution of the algorithm, the output result can be fed to the ontology framework through the APIs as well. For instance, the output file with the optimal maintenance activity can be parsed by the APIs and then recorded by the ontology repository. For the MMV, if the existing MMS is running remotely, i.e., running on another computer with network connections, an adapter can be implemented by using the APIs to feed information to the ontology framework. Meanwhile, the adapter can use the interfaces provided by the MMS to obtain the required information. In practice, any algorithms or tools providing automation interfaces can be integrated with the proposed framework.

It is worth noting that although the current version of the proposed framework provides the ability to interact with external databases or tools, some algorithms, such as the algorithms for fault prognosis, risk assessment, and decision-making, are performed manually for the case study system.

Information processing algorithms

This section introduced the information processing algorithms used by the proposed framework to collect information for various views defined by MuAMO and provide maintenance recommendations to system operators. Figure 10 displays the pseudocode of the algorithm. This algorithm will be executed periodically to change the maintenance strategies dynamically. The algorithm can be triggered using a fixed period (e.g., every second or every minute) depending on the type of the component being maintained or by specific events (e.g., new online monitoring data are received in interrupt-based systems). The functions used by the algorithms are introduced in Table 6. These functions are implemented by directly inquiring about the ontology repository or calling the interfaces of the views in MuAMO.

Table 6. Functions used by the algorithms

The maintenance optimization process algorithm also requires two additional functions: “Get_failure_information” for obtaining the failure information for the component being maintained and “Get_risk_information” for obtaining the system risk if the component being maintained is failed. The algorithms of these two functions are detailed in Figures 11 and 12, respectively.

The algorithm in Figure 11 uses list operations. For example, function “Create_empty_list” can create an empty list and function “Append_list” can append a set of variables into the current list.

Information queries

Based on the ontology repository and the algorithms introduced above, the real-time data related to the maintenance target system can be collected and recorded by the ontology framework. However, the collected data cannot directly be used by maintenance optimization models or be referenced by the analyst for decision-making (i.e., be used to answer the competency questions proposed in the “Step I. Determine the domain and scope of the ontology” section). Data query for select information of interest is required. As a de facto standard, the ontology provides SQWRL, an SWRL-based information query language (Horrocks et al., 2004) for eliciting data from ontology repositories. SQWRL provides basic arithmetic and Boolean operators which can be used to acquire data based on logic expressions. Generally, an ontology query engine, for example, HermiT (Glimm et al., 2014), can parse the SQWRL expressions and can derive the associated results.

This section builds the queries for answering the competency questions. It uses the format of SWRL for expressing the established queries. Due to the complexity of the competency questions, some of the questions are answered progressively, that is, one competency question is divided into several subquestions. After answering all these subquestions, the competency question can be finally answered. The following text details the queries created for each competency question mentioned in the “Step I. Determine the domain and scope of the ontology” section.

QA) To decrease the risk of the target system, what is the most efficient applicable maintenance activity?

This question is usually raised by maintenance analysts to prioritize the maintenance activities. However, since this question requires synthetic information from the different views of the proposed framework, the original question is divided into the following subquestions.

QA.1) Which components/subsystems need to be maintained in the target system?

The information required by this question can be acquired by identifying the components belonging to the feedwater system. The following query can be used.

$$ {\displaystyle \begin{array}{c} Component{\left(?x\right)}^{\hat{\mkern6mu} } Maintenable\_ Item\left(?x\right) has\_ component\left( SYSTEM,?x\right)\\ {}\to component\_ under\_ analysis\left(?x\right)\end{array}} $$

In the expression, the variable “SYSTEM” will be replaced by the name of the system considered for maintenance. The variable x will contain the components/subsystems that need to be maintained.

QA.2) What are the available maintenance activities for the target component?

This question can be answered by searching the maintenance activities whose target component is one of the target system’s components. Also, the input statement contains the expressions related to equipment and people since some of the maintenance activities require specific equipment or people to conduct them. The following query can be used.

$$ {\displaystyle \begin{array}{c} Maintenance\_ Activity{\left(?m\right)}^{\hskip0.35em } has\_ target\_\\ {} component\left(?m,?x\right) Component\_ under\_ analysis\left(?x\right) \\ {} Maintenance\_ Equipment\hskip0.35em \left(?e\right) Require\_ equipment\left(?m,?e\right)\\ {} sqwrl: count\left( has\_ instance\left(?e\right)\right)>=1 \\ {} Maintenance\_ Team\left(?t\right) require\_ staff\left(?m,?t\right) Sqwrl:\\ {} count\left( has\_ available\_ worker\left(?t\right)\right)>=1\to \\ {} applicable\_ maitnenance\_ activity\left(?x,?m\right)\end{array}} $$

It is worth noting that this query requires the answer of the previous question. We can see that the condition Component_under_analysis(?x) is one of the premises of this expression.

QA.3) What is each failure mode’s cost (risk)?

The cost associated with the occurrence of particular failure modes can be acquired from the connection relationship between the failure view and the risk view.

$$ {\displaystyle \begin{array}{c} component\_ under\_ analysis\left(?x\right) has\_ failure\_ mode\left(?x,?f\right) \\ {} has\_ failure\_ rate\left(?f,?q\right) cause\_ loss\left(?f,?l\right) \\ {} swrlb: multiply\left(?r,?q,?l\right)\to has\_ risk\left(?x,?f,?r\right)\end{array}} $$

In the expression, the risk is calculated by multiplying the failure rate and the financial loss (dollars/year). The variable f will be the failure mode, and the variable r will be the corresponding risk associated with such a failure.

QA.4) What is the MEMA?

Based on the answers from the previous subquestions, we can build the query for answering the competency question A. The MEMA is the one that decreases the risk of the target system in its current state the most. Assume that in the current state, the failure rates of the seal and the leaf spring are both one failure/year and that inspecting a component does not impact its failure rate, and replacing a component restores its failure rate to its initial value. Assume that the MEMA can be calculated using the following equation:

$$ MEMA= argmax\left(\frac{risk\ before\hskip0.35em ma\mathit{\operatorname{int}} enance- risk\ after\hskip0.35em ma\mathit{\operatorname{int}} enance}{ma\mathit{\operatorname{int}} enance\hskip0.35em \mathit{\cos}t}\right). $$

Then we can create the query expression below.

$$ {\displaystyle \begin{array}{c} component\_ under\_ analysis\left(?x\right) applicable\_ maintenance\_\\ {} activity\left(?x,?m\right) has\_ failure\_ mode\left(?x,?f\right) \\ {} cause\_ loss\left(?f,?l\right) has\_ current\_ failure\_ rate\left(?f,?c\right) \\ {} has\_ risk\left(?x,?f,?r\right) has\_ maintenance\_ cost\left(?m,?v\right) \\ {} swrlb: multiple\left(? cl,?c,?l\right) swrlb: substract\left(?s,? cl,?r\right)\\ {} swrlb: divide\left(?a,?s,?v\right) sqwrl:\mathit{\max}\left(?a\right)\to \\ {} most\_ efficient\_ maitenance\_ activity\left(?x,?m,?a\right)\end{array}} $$

The variable m will be the MEMA the framework can identify. And, the variable x will be the component that is the target component of the maintenance activity m.

QB) Considering maintenance costs and system risks, what is the most critical part of the target system/component?

The most critical part of a component can be defined as contributing the most risk to the system or leading to the most costly maintenance. In practice, the proposed ontology evaluates the criticality of a component by the sum of the risks and maintenance costs related to the component. By reusing the queries created for competency questions QA.1 and QA.3, the statement necessary for finding the most critical part of a component can be built as below.

$$ {\displaystyle \begin{array}{c} component\_ under\_ analysis\left(?x\right) has\_ composite\left(?x,?p\right) \\ {} applicable\_ maintenance\_ activity\left(?x,?m\right) \\ {} has\_ target\_ component\left(?m,?p\right) has\_ failure\\ {}\_ mode\left(?x,?f\right) has\_ maintenance\_ cost\left(?m,?v\right) \\ {} has\_ risk\left(?x,?f,?r\right) swrlb: add\left(?a,?r,?v\right) sqwrl:\mathit{\max}\left(?a\right)\to \\ {} most\_ critical\_ component\_ part\left(?x,?p\right)\end{array}} $$

In the output of the query above, the variable x will be the most critical component of the target system and the variable p will be the most critical part of component x.

QC) What is the best improvement to system safety in terms of all feasible maintenance activities for a given budget?

Generally, the improvement to system safety can be defined as decreasing system risk. Based on that definition, this question can be divided into the following subquestions:

QC.1) What are the feasible maintenance activities for a given budget?

The feasible maintenance activities can be obtained by checking the candidate activities in the MMV using the following query.

$$ {\displaystyle \begin{array}{c} component\_ under\_ analysis\left(?x\right) applicable\_\\ {} maintenance\_ activity\left(?x,?m\right) \\ {} has\_ maintenance\_ cost\left(?m,?v\right) \\ {} swrl: lessThanOrEqual\left(?v, BUDGET\right)\to \\ {} feasible\_ maintenance\_ activity\left(?x,?m\right)\end{array}} $$

After the execution of the query, the variable m will be the feasible maintenance activity. In the expression, the variable BUDGET will be replaced by the actual budget.

QC.2) What is the maximum improvement of system safety that can be obtained at this time?

By reusing the queries of competency questions QA.4 and QC.1, the best system safety improvements can be calculated using the following expression.

$$ {\displaystyle \begin{array}{c} component\_ under\_ analysis\left(?x\right) applicable\_\\ {} maintenance\_ activity\left(?x,?m\right) \\ {} has\_ failure\_ mode\left(?x,?f\right) has\_ risk\left(?x,?f,?r\right) \\ {} has\_ current\_ failure\_ rate\left(?f,?c\right) \\ {} cause\_ loss\left(?f,?l\right) swrlb: multiply\left(? cl,?c,?l\right) swrlb:\\ {} substract\left(?s,? cl,?r\right) sqwrl:\mathit{\max}\left(?s\right)\\ {}\to most\_ efficient\_ maintenance\_ activity\left(?x,?m,?s\right)\end{array}} $$

The value of variable s will be the maximum improvement to system safety based on the information recorded by the ontology framework. Table 7 summarizes the information queries provided for answering competency questions.

Table 7. Information queries provided for answering competency questions

Case study

In this paper, the proposed framework is verified using solenoid operated valves (SOVs) in a hardware-in-the-loop (HIL) experimental setup. SOVs are widely used in NPPs in pneumatic circuits that are utilized to control and operate important actuators, such as those used to move and position control rods. This section details the system structure and the components, the considered functions and the corresponding failure modes, the monitoring data and the available maintenance activities, and other required information for decision-making, generated from the proposed ontology and framework.

Figure 14 depicts the HIL experimental system. The experimental setup emulates the feedwater system on the secondary side of a pressurized water reactor. The target component, a solenoid-operated proportional flow control valve, acts as the feedwater flow control valve. The SOVs in the system are flow control valves and are not pressure control valves.

Figure 14. Hardware of the experimental system.

Components and structures

The major components of the solenoid valve used in our experimental setup are presented in this section. Figure 15 displays the structure and the components of the SOV under study. Table 8 presents the typical failure modes of solenoid valves considered in the case study. In the case study, the following assumptions are made to simplify the calculations related to risk assessment:

1. 1) Only one system failure is considered, which will cause a financial loss equivalent to $2E3.

2. 2) Any failure mode of the valve will cause the system failure with a probability 100%. This information is modeled by the proposed ontological framework.

Figure 15. Solenoid operated valve cross-sectional view and parts.

Table 8. Failure modes of the solenoid operated valve

Table 9 summarizes the measurements sampled from the target system and the SOV. The data are recorded by the classes defined in the monitoring view.

Table 9. Measurements for the solenoid operated valve

Maintenance activities

Table 10 summarizes the maintenance activities defined by the maintenance process view. It shows the assumed total cost and the work duration for each maintenance activity. The decision-making algorithm will reference this information to select the optimal maintenance activity.

Table 10. Maintenance activities for the solenoid operated valve

Results and achievements

By executing the information queries introduced in the “Information queries” section, we can acquire the outputs from the ontology repository to answer the competency questions raised in the “Step I. Determine the domain and scope of the ontology” section. Table 11 displays the ontology repository’s outputs which have been verified by expert judgment. In the results, the components’ names with the number 1 denote that they are instances of components, not the component classes.

Table 11. Results of the case study system for the competency questions

The answer to QA.1 includes all the components that need to be maintained in the target system. The answer to QA.2 includes the available maintenance activities for the target component “Valve_1.” According to the answer to QA.4, the MEMA is “replace the seal,” which decreases the risk by 9.9 (dollar loss per year/dollars of maintenance cost). Also, the most critical part of the solenoid valve is the Leafspring, shown by the answer to QB.

Assume that the failure of any part of the valve will fail the valve. According to the feasible maintenance activities identified by QC.1, the best system safety improvement can only be achieved by the activity “replace the whole valve,” which reduces the risk by 1980.

Discussion

This paper proposes an ontology framework for supporting the development of a maintenance optimization system. The proposed framework can facilitate the tasks that need to be performed during the development of every maintenance optimization system. These tasks are discussed below.

• • Using the framework for optimization model selection. A maintenance optimization model usually contains one or more optimization algorithms that require various inputs. For example, a maintenance optimization model for a feedwater system may require the flow rates through the pipelines in the system to be sampled in real time by different sensors, the predicted residual lifetime of the regulating valves from a fault diagnosis tool, as well as the risk of system failures from a risk assessment tool. One can use the proposed framework to quickly identify whether the requirements of the optimization algorithm can be satisfied. The identification can be achieved by using ontology query languages, for example, SPARQL (Pérez et al., 2006), or by defining the prerequisite rules using SWRL (Horrocks et al., 2004). The optimization algorithms with unsatisfiable requirements can be filtered out.

• • Using the proposed framework to implement a maintenance optimization model will be more straightforward than the traditional development process since the framework provides a standardized API that can supply the required information to the optimization model. As a result, the developers of the optimization model do not need to implement the functions related to data sampling and formatting, and the time for model implementation can be reduced.

• • As a data provider for the maintenance optimization model, the proposed framework can provide online data for the optimization model. Also, it can be configured to provide test data to the model for model evaluation. For example, the OMV can be configured to connect to a database that records a series of benchmark data. Meanwhile, if two optimization models are implemented based on the API provided by the framework, the framework can launch both algorithms using the same monitoring data, and their outcomes can be compared and evaluated.

Although the proposed framework itself cannot perform critical tasks required by system maintenance, such as system diagnosis and risk assessment, it provides various APIs that can be easily reused by external tools to provide the results of such tasks to the ontology repository. For example, by using the APIs provided by the component view, the system structure information represented by a system modeling diagram, such as piping and instruments diagrams (P&IDs), can be modeled and reused by other views. The interface developed for this view can be connected to an image identification tool to update the system components and structural information automatically (Gao et al., 2020). The monitoring view can search and select data sampled from real systems. External diagnosis or health management tools can use these data to perform diagnosis and prognosis. The RAV can interact with external risk analysis tools to acquire risk evaluation results. The view can provide information about the event trees, fault trees, and the distributions and probabilities for various events.

In the current version of the proposed ontology framework, the classes of failure modes and applicable maintenance activities are manually defined by domain experts. The classes of failure modes and the classes of maintenance activities are linked by the types of components, that is, specific failure modes are linked to specific types of components, and the same is true for the maintenance activities. In this case, the validity of failure modes and maintenance activities is ensured by expert knowledge. Domain experts can add failure modes for specific target systems to the ontology repository or identify the failure modes that can be reused. In the future, the conditions and constraints for validating failure modes and maintenance activities can be predefined using the ontology framework so that the ontology reasoner can automatically identify their applicability to various target systems.

In addition, it is worth noting that this paper describes a method for reusing existing ontologies and minimizing the modifications to the existing ontologies. However, conflicts between the classes in two different ontologies may exist. The existence of conflicts between two or more ontologies means that classes or properties given the same name in these ontologies may have different interpretations or that mistakes may exist in these ontologies. For example, the class “orange” can be a subclass of “fruit” in the fruit ontology but can also be a subclass of “color” in the color ontology. The proposed ontology integration method cannot prevent such semantic heterogeneity between existing ontologies. However, some ontology inference engines, for example, HermiT (Glimm et al., 2014), can detect these types of conflicts automatically.

Conclusion

This paper establishes a maintenance optimization ontology, the MuAMO, by using the methodology introduced for ontology development. To integrate ontologies incompatible with the same meta-ontology, a heuristic method to reuse the concepts and properties defined by existing ontologies was developed. By using the ontology MuAMO as a data repository for aggregating information and a series of interfaces interacting with these data sources, an ontology framework has been created as a data repository for aggregating information. The proposed framework can provide various required information for different maintenance optimization algorithms to evaluate the maintenance activities and select the optimal one. In this paper, a solenoid valve deployed in a feedwater system as the target component has been used to verify the proposed methodology and validate the developed framework. As an example use of the proposed framework, the results from the case study system demonstrated the feasibility and effectiveness of the proposed framework. Based on the current version of the ontology framework, several tasks can be undertaken to improve the proposed framework.

In the future, we will enrich the interfaces of each view in MuAMO and connect the framework to more third-party tools. Specifically, the ACV will be connected to an image processing tool (Gao et al., 2020), which can identify system components in P&IDs and automatically model system structures. The FFV and the OMV will connect to a fault diagnosis algorithm (Li et al., 2022) for component degradation prediction based on online monitoring data. Meanwhile, the RAV will interact with a probabilistic risk assessment tool, for example, SAPHIRE (Smith et al., 2016), for system risk assessment, and the DMV will be connected to a decision-making algorithm (Zhao and Smidts, 2022). Also, the MMV will be enhanced to communicate with MMSs developed for specific target systems (e.g., the ones in NPPs).