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, Reference Noy and Mcguinness2017). 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, Reference Smith1998), the suggested upper merged ontology (Niles and Pease, Reference Niles and Pease2001), and the descriptive ontology for linguistic and cognitive engineering (Gangemi et al., Reference Gangemi, Guarino, Masolo and Oltramari2003). Since most of the reused ontologies are compatible with BFO, the proposed framework will also be built based on BFO (Smith, Reference Smith1998).

Since some of the ontologies do not use BFO (Smith, Reference Smith1998) 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 $ .

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 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.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., Reference Horrocks, Patel-schneider, Boley, Tabet, Grosof and Dean2004) 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.

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., Reference Glimm, Horrocks, Motik, Stoilos and Wang2014). (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., Reference Diao, Pietrykowski, Huang, Mutha and Smidts2022), ROMAIN (Karray et al., Reference Karray, Ameri, Hodkiewicz and Louge2019), and information artifact ontology (Ceusters, Reference Ceusters2012). 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.

Tools and interfaces

The proposed ontology is implemented using Protégé (Musen, Reference Musen2015), 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., Reference Horrocks, Patel-schneider, Boley, Tabet, Grosof and Dean2004) 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, Reference Lamy2017). 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., Reference Glimm, Horrocks, Motik, Stoilos and Wang2014) 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, Reference Zhao and Smidts2022) 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., Reference Horrocks, Patel-schneider, Boley, Tabet, Grosof and Dean2004) 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., Reference Glimm, Horrocks, Motik, Stoilos and Wang2014), 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