Juan José Montero Jiménez

Rob A Vingerhoeds

Bernard Grabot

Sébastien Schwartz

Juan José Montero Jiménez

B Juan

José Montero Jiménez

An ontology model for maintenance strategy selection and assessment

Keywords: Maintenance strategy, Ontology, Knowledge base, Knowledge reuse

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

Maintenance, as defined by the standard BS EN 13,306 (European Committee for Standardization, 2017), is the "combination of all technical, administrative and management activities throughout the life cycle of an asset in order to maintain or restore it to the state where it can perform the intended functions." Maintenance exists since the first humans substituted the broken parts of their first tools, and it has evolved along with the increment of the complexity of artificial assets. Today it plays a vital role in keeping technical systems in optimal operating conditions. Within maintenance management activities of modern industrial systems, engineers need to select maintenance strategies so to carry out the technical maintenance actions. These maintenance strategies are directly linked to triggering events such as a failure (corrective maintenance), a safe operating time interval (preventive maintenance), or an abnormal symptom (predictive maintenance) that launches a maintenance action. Selecting the right maintenance strategy can be a complex task. It depends on several factors, such as the detrimental effects of an unforeseen failure, the maintenance costs, the maintenance personnel skills, and the access to technological tools to carry out the most advanced maintenance actions [START_REF] Emovon | Hybrid MCDM based methodology for selecting the optimum maintenance strategy for ship machinery systems[END_REF]. Information from different sources should be assessed to perform the right maintenance strategy selection, such as Failure Mode, Effects and Criticality Analysis (FMECA), a cost-benefit-risk analysis, Computational Maintenance Management Systems (CMMS). Besides, a selected strategy is often not assessed over time to confirm its effectiveness or suitability. Smart Decision Support Systems (DSS) can be developed to help engineers in such complex tasks. These smart DSS can be tenance systems to reach a safer, more reliable, and more efficient operation of technological systems.

The rest of the paper is organized as follows: "Sect. Maintenance strategies" introduces the topic of maintenance strategies, the selected taxonomy for maintenance strategies used in OMSSA, and the maturity model of the evolution of the maintenance strategies. "Sect. Ontology engineering" is dedicated to ontology engineering and the methodology used to develop OMSSA, based on the alignment to a toplevel domain-neutral ontology to facilitate its future reuse. "Sect. Ontologies in maintenance" summarizes the related studies on ontologies in the maintenance domain and analyses their limitations for addressing the current trends of maintenance strategies. The requirements and vocabulary sources for OMSSA are introduced. "Sect. Ontology for Maintenance Strategy Selection and Assessment (OMSSA)" explains the most important terms and relations for maintenance strategy management using a graphical representation for different parts of the model. "Sect. Evaluation and discussion" is dedicated to the verification and validation of the ontological model, as well as its illustration on a case study. "Sect. Conclusion and future work perspectives" concludes this paper by presenting the final remarks and perspective for future work.

Maintenance strategies

Maintenance strategies are part of maintenance management. They aim to establish how and when maintenance action should be performed to restore or maintain a specific artifact, component, or system into its nominal operational state. Maintenance strategies are often established by experts who know the different failures that a system can encounter, taking into consideration the likelihood and the detrimental impacts (human lives, environmental damage, costs, production losses) of each failure occurrence. One classic approach to establish maintenance strategies is the Failure Modes, Effects, and Criticality Analysis (FMECA) (International Electrotechnical Commission (IEC), 2018), in which a maintenance strategy is assigned to each failure mode of each component of an equipment.

Maintenance strategies can be divided into three groups depending on the triggering event of the maintenance action: corrective maintenance, preventive maintenance, and predictive maintenance:

• Corrective_maintenance is triggered by a failure. However, there is an important difference between a run-to-failure strategy and a maintenance action produced by an unexpected failure. The second one cannot be considered as a strategy as it was not planned [START_REF] Hodkiewicz | Rethinking maintenance terminology for an industry 4.0 future[END_REF]. It is important not to developed on the basis of a well-structured vocabulary framework. The definition of concepts, attributes, and relations among concepts can help to structure the knowledge around maintenance strategies, allowing their better selection and assessment.

For this aim, the current study proposes an Ontology model for Maintenance Strategy Selection and Assessment (OMSSA). From the practical point of view, the objective of OMSSA is to provide a vocabulary structure that can be used for the development of smart agents such as DSS to help engineers in the selection, assessment, and even in the implementation of maintenance strategies. From the scientific point of view, the OMSSA contribution can be seen as a structured meta-knowledge representation in the domain of maintenance strategies.

Ontologies are formal, explicit descriptions of concepts in a domain of discourse, the properties of each concept describing its features, attributes, and restrictions [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF]. One of the most common goals in developing ontologies is "sharing a common understanding of the structure information among people and software agents" [START_REF] Gruber | A translation approach to portable ontology specifications[END_REF][START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF]. However, there are also several other motivations to create ontology models, such as enabling reuse and analysis of domain knowledge or making domain assumptions explicit. Ontologies are powerful tools for knowledge representation. The described concepts are represented by classes, while the properties represent the relations between the terms. An ontology with individual instances for its classes constitutes an ontology-based knowledge base [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF][START_REF] Qin | An ontology-based semantic retrieval approach for heterogeneous 3D CAD models[END_REF]. This knowledge base can be used for several purposes in the artificial intelligence field. For example, it can provide a formal terminology framework allowing to perform reasoning based on semantic rules.

OMSSA provides a formal terminology framework in maintenance strategy selection and assessment, considering not only traditional approaches but also the current trends towards the use of advanced diagnosis and prognosis tools to trigger maintenance actions. Its development is part of a bigger research project in knowledge reuse for maintenance systems. For the OMSSA, the taxonomy of corrective maintenance, preventive maintenance, and predictive maintenance has been selected to classify the maintenance strategies. These three terms have been widely used in the research community and across the industry [START_REF] Emovon | Hybrid MCDM based methodology for selecting the optimum maintenance strategy for ship machinery systems[END_REF][START_REF] Kothamasu | System health monitoring and prognostics-a review of current paradigms and practices[END_REF][START_REF] Montero Jimenez | Towards multi-model approaches to predictive maintenance: A systematic literature survey on diagnostics and prognostics[END_REF]. Even when a good combination of the three strategies is vital to keep a technical system in nominal operation [START_REF] Montero Jimenez | Enhancing operational fault diagnosis by assessing multiple operational modes[END_REF], there is a trend to implement proactive techniques to avoid unforeseen failures that can affect a technical system operation. For OMSSA, special attention is given to the current trends in maintenance management towards the implementation of predictive main-confuse a corrective strategy with an undesired failure. The undesired failure is actually a sign that preventive or predictive strategies assigned to the failed component and should be re-evaluated.

• Preventive_maintenance actions are triggered by fixed time recommendations coming from safety operating time intervals or preventive scheduled stops of an item. Classic approaches such as Reliability Centered Maintenance (RCM) provide a set of strategies based on preventive action such as failure finding, fixed time restoration and fixed time replacement [START_REF] Moubray | RCM II: Reliability centered maintenance[END_REF]. • Predictive_maintenance strategies propose an alternative to preventive actions. They aim at triggering the maintenance actions based on the condition of a machine. Predictive maintenance is carried out by specialized models or tools that help maintenance engineers for an intelligence-based decision-making process to trigger maintenance actions. Classic approaches such as RCM summarize these strategies as "condition-based," providing a limited insight on how these strategies are actually developed. Recent trends in maintenance show that predictive maintenance strategies can have three types of triggering events: early fault detection, health/degradation threshold overshoot, and future failure forecasting. These three triggering events could affect the scheduling of maintenance actions based on the condition of the item. Anticipating failures allows the optimization of maintenance schedules as the maintenance actions will be triggered accurately when needed [START_REF] Montero Jimenez | Towards multi-model approaches to predictive maintenance: A systematic literature survey on diagnostics and prognostics[END_REF]. Condition monitoring quality is an important issue for predictive maintenance strategies [START_REF] Castaño | Quality monitoring of complex manufacturing systems on the basis of model driven approach[END_REF]. It is important to ensure accurate monitoring so that the recorded data can be used to train the specialized models that carry out the diagnosis and prognosis tasks.

From corrective maintenance to predictive maintenance, there is an evolution in the implementation of maintenance strategies, from the simplest ones to the most advanced. This evolution can be represented by a maturity model. The more advanced the strategy, the more benefits it could bring, but also the higher the implementation cost and the complexity. The final step in this maturity model is the strategies based on prognostics which remain a challenge for their implementation and are often included in the Prognostics and Health Management (PHM) discipline [START_REF] Montero Jimenez | Towards multi-model approaches to predictive maintenance: A systematic literature survey on diagnostics and prognostics[END_REF]. Figure 1 shows the proposed maturity model for maintenance strategies considering the triggering event.

Ontology engineering

Several specific methodologies exist for ontology development that are not simply interchangeable: two different Fig. 1 Maintenance strategies maturity model methodologies will not lead to the same final ontology. [START_REF] Keet | An introduction to ontology engineering[END_REF] presents an extensive comparison of the different methodologies and how they should be selected depending on the objectives of the ontology. As OMSSA aims at formalizing the knowledge of a specific domain, the selected methodology is a variant of "Ontology development 101" [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF]. The main reason why this methodology was selected is because of its capability and simplicity for building new ontologies by reusing terms from top-level ontologies. Having a top-level ontology improves the interoperability of ontologies and thus facilitates their future reuse. For OMSSA, the selected top-level ontology is the Basic Formal Ontology (BFO) [START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF]; International Organization for Standardization (ISO) 2020a, 2020b). To facilitate the alignment to BFO, some mid-level reference ontologies can be used. These ontologies provide a set of terms and relations that are common among different but related knowledge domains. For OMSSA, the alignment to BFO is performed using the Relation Ontology (RO) and the Common Core Ontologies (CCO) as these ontologies provide a good set of terms and relations to model ontologies in the industrial domain.

This section explains the different "blocks" used for OMSSA development. OMSSA was developed using the current version of the platform Protégé (Stanford University, 2020). This platform supports the latest specifications of the OWL 2 set by the World Wide Web Consortium.

Ontology development 101

"Ontology Development 101" is a seven-step iterative methodology used to create ontologies [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF]. Each step is explained hereafter:

1. Determine the scope of the ontology, meaning the main goal for which the terminology framework will be created. At this point, important aspects such as the ontology domain or the intended use of the ontology must be defined. To do so, a set of "competency questions" can be proposed to delimitate the ontology scope. Competency questions are a set of questions that an ontology-based knowledge base should be able to answer, emulating the way an expert would answer [START_REF] Grüninger | Methodology for the design and evaluation of ontologies[END_REF]. 2. Consider reusing existing ontologies. This step is vital to ensure the alignment of the new ontology with related ontologies that already exist. Some terms and relations can be retrieved from these existing ontologies.

For OMSSA, some ontologies are being completely reused (imported) as upper-level ontologies (BFO, RO, CCO), and some important terms and relations linked to OMSSA scope have been extracted from other domainspecific ontologies (see Sect. Ontology engineering). 3. Enumerate terms. Here, the main terms related to the selected scope are listed. A classification of these terms is not needed at this step, as it will be performed in the following steps. 4. Define the classes. The first classification of the enumerated terms is performed to define the classes of the new ontology. Classes are the means to represent the different entities in ontologies. They must be written in the singular form. 5. Define properties of classes. Here, the internal structure of concepts is described. The properties of the classes represent the links among the classes. Verbs in third-person conjugation are often used to represent these properties. 6. Define constraints. The classes and properties among these classes can have several constraints, such as for example value type, allowed values, and cardinality. 7. Create instances. This last step aims at instantiating the new ontology. Once the ontology has individual instances for its classes, it becomes an ontology-based knowledge base. So, for many reference ontologies, the instantiation does not take place as they are intended to be as generic as possible. Sometimes, this instantiation is done for validation purposes, and later the ontology is published without the specific instances.

(International Organization for Standardization (ISO) 2020a, 2020b). BFO has been successfully used by the Open Biological and Biomedical Ontology (OBO) Foundry [START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF]. BFO is also used along with the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) by the Industrial Ontologies Foundry (IOF) to develop proofof-concept ontologies [START_REF] Karray | ROMAIN: Towards a BFO compliant reference ontology for industrial maintenance[END_REF][START_REF] Sanfilippo | Formal ontologies in manufacturing[END_REF]. The future reuse and alignment of OMSSA to IOF ontologies motivated the selection of BFO as top-level ontology. BFO starts from the most basic class entity, divided into two main subclasses: continuant and occurrent [START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF]; International Organization for Standardization (ISO) 2020a, 2020b; [START_REF] Rodrigues | What to consider about events: A survey on the ontology of occurrents[END_REF]. Continuants refer to entities that continue to exist through time, for example objects, functions, and qualities. Occurrents refer to entities that occur, meaning that they are spread not only in space but also in time; for example, processes belong to this class. Based on these two main entities, BFO proposes a set of domain-neutral classes that can be used to model any domain-specific ontology. Figure 2 shows the BFO 2.0 structure, which is a stable version since 2015 [START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF]. In the current study, continuants are represented in blue and occurrents in green.

Building an ontology using a top-level ontology such as BFO could be complicated because all new domainspecific classes must be clustered under domain-neutral classes. These upper-level classes have their own properties and constraints that are inherited by the domain-specific classes. Some consistency issues might arise when creating the relations at the lower levels of the ontology. Nevertheless, having a top-level domain-neutral ontology promotes more important data interoperability and thus enables ontology reuse (International Organization for Standardization (ISO), 2020b).

Reuse of relation ontology and common core ontologies

Relation Ontology (RO) [START_REF] Foundry | Relation ontology (RO)[END_REF] and Common Core Ontologies (CCO) (Rudnicki, 2020a[START_REF] Rudnicki | Common core ontologies[END_REF]) are midlevel domain-neutral BFO-compliant ontologies. RO provides domain-neutral relations among different classes, from which more specific relations can be derived in a specific domain. CCO is composed of eleven ontologies that have as objective the representation and taxonomy integration of generic classes and relations across all domains of interest. Within CCO, the following ontologies are found: Information Entity Ontology, Agent Ontology, Quality Ontology, Event Ontology, Artifact Ontology, Geospatial Ontology, Time Ontology, Units of Measure Ontology, Currency Unit Ontology, Extended Relation Ontology and Modal Relation These steps can be iterative. Often, missing terms are identified in later steps of ontology development. This leads to the iteration of previous steps to make sure that all classes, properties, and constraints are properly defined for the new identified terms.

BFO as a top-level ontology

BFO is a top-level ontology that serves as starting point for the development of other reference ontologies and/or domain-specific ontologies [START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF]; International Organization for Standardization (ISO), 2020b). It serves as a generic framework that offers a set of domain-neutral classes in which more specific terms can be clustered. Using a top-level ontology is advisable when developing domainspecific ontologies as it facilitates the interoperability with other related ontologies that use the same terms and relations Ontology (Rudnicki, 2020a). The import structure of CCO in its version 1.3 is presented in Fig. 3.

In maintenance management, many concepts can be clustered in the CCO class Information_Content_ Entity. This class includes pieces of information used to describe, designate, or direct other entities. For maintenance, the concepts under this CCO class are used to describe the maintainable items attributes, condition data, costs, models, specifications, among others. To model all these information entities and the phenomena they describe in real life, OMSSA directly imports the Information Entity Ontology, the Artifact Ontology, and the Event Ontology from CCO. Due to the import structure of CCO, the Time Ontology, Geospatial Ontology, and the Extended Relation Ontology are indirectly imported from CCO, and consequently, RO and BFO are also imported.

among different class properties. The sub-properties proposed in OMSSA help to distinguish the difference between two similar relations. The relations used in OMSSA, including their definition and the graphical representation in the current study, can be found in the Appendix.

Ontologies in maintenance

Ontologies describe the knowledge of a specific domain through a formal representation of concepts and relations [START_REF] Nuñez | OntoProg: An ontology-based model for implementing Prognostics Health Management in mechanical machines[END_REF]. The use of ontologies can simplify the data exchange and interoperability among dissimilar systems, serving as a framework for answering queries about that data [START_REF] Cao | Towards a core ontology for condition monitoring[END_REF][START_REF] Panov | Ontology of core data mining entities[END_REF]. Ontologies are often built upon the World Wide Web Consortium (W3C) standards such as the Ontology Web Language (OWL) and are often used to formalize vocabulary for the semantic web [START_REF] Antoniou | A semantic web primer[END_REF][START_REF] Lu | ManuService ontology: A product data model for service-oriented business interactions in a cloud manufacturing environment[END_REF][START_REF] Nuñez | OntoProg: An ontology-based model for implementing Prognostics Health Management in mechanical machines[END_REF][START_REF] Talhi | Ontology for cloud manufacturing based product lifecycle management[END_REF]. Ontologies provide a terminology framework that allows information from a specific domain of knowledge to be processed by a machine. Ontologies have already been used in the maintenance domain. Formal terminology frameworks have been developed to support tasks such as maintenance management, condition monitoring, and prognostics, and health management.

IMAMO (Industrial MAintenance Management Ontology) [START_REF] Karray | A formal ontology for industrial maintenance[END_REF] presents a domain ontology for industrial maintenance management. The main goal was to establish a common and shared terminology set for maintenance support systems. The methodology used for its development is METHONTOLOGY [START_REF] Fernandez | Methontology: from ontological art towards ontological engineering[END_REF]. The authors used UML to graphically represent the selected terms and their relationships. IMAMO reasoning assessment was performed using the PowerLOOM tool. IMAMO integrates and reuses terms from other ontology models such as the SMAC-model [START_REF] Matsokis | An ontology-based model for providing semantic maintenance[END_REF] and the MIMOSA-CRIS model [START_REF] Mimosa | Open system architecture for condition-based maintenance (OSA-CBM)[END_REF]. Maintenance strategies management is not included in the IMAMO approach.

An ontology-based model for prognostics and health management of machines OntoProg, is presented in [START_REF] Nuñez | An ontology-based model for prognostics and health management of machines[END_REF] and [START_REF] Nuñez | OntoProg: An ontology-based model for implementing Prognostics Health Management in mechanical machines[END_REF]. The scope of these ontologies is to detail the initial phase of Prognostics and Health Management (PHM) to support intelligent decision systems. These systems can potentially be developed to provide health condition of machines and support smart manufacturing. The ontology model was built following the "Ontology Development 101" [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF] with the OWL2 language (the current version of the Ontology Web Language) using the Protégé OWL editor. These ontologies reuse accurate terms from maintenance standards and norms that are also used in OMSSA. These ontologies It is important to mention that by importing the Information Entity Ontology, the "aboutness" paradigm to represent data properties is adopted for OMSSA. In contrast to UML, where attributes are listed inside each class, the "aboutness" paradigm represents these properties as separated classes. These classes are linked to the main class with the relation CCO: isAbout. This facilitates the management of data properties by machines [START_REF] Smith | Aboutness: Towards foundations for the information artifact ontology[END_REF].

As for BFO, CCO and RO allow having a mid-level set of domain-neutral ontologies that facilitate the alignment of core or application ontologies. Having this set of mid-level ontologies aligned to BFO improves the interoperability of core and domain ontologies such as OMSSA with those of the industry domain that share the same structure. BFO and CCO serve as a generic ontology development structure to ensure uniformity in the use of generic terms.

Relations in OMSSA

One of the important aspects of ontologies concerns the object properties that gather the relations among the different classes. As mentioned in the previous section, the Relations Ontology RO and the extended relations ontology from CCO are implemented as a basis to represent the relations of the different classes for OMSSA. It is important to mention that more specific relations could be used depending on the ontology domain but are contained as sub-relations of those in the RO or the Extended Relation Ontology from CCO.

Using these generic relations prevents inconsistency in the ontology. These relations are intended for specific types of BFO classes. Several inconsistencies might arise when developing the ontology. For example, the relation "precedes" can only be used to relate two occurents. In this context the assertion "a fault precedes the failure" cannot be directly proposed because a fault is considered as a continuant while the failure is an occurrent (definitions and classification of the terms are presented later in this article). To solve this inconsistency, a faultcan be linked to another occurrent which is degradation using the relation "participates in", and the class degradation process is linked to the class failure with the relation "precedes". The assertions to link all these terms become "a fault participates in the degradation" and "the degradation precedes the failure". Having this fixed set of generic relations demands a deeper understanding of the terms of the ontologies. It turns out to be a complex task to link all terms in the ontology, but it also allows a better and more complete analysis of the used classes and their actual relations. It helps to identify missing terms and to prevent inconsistency in the ontology.

Only a few domain-specific relations have been added in OMSSA. They concern sub-relations of other domainneutral object properties imported from RO and CCO. The added relations help to avoid inconsistency or ambiguity are domain-specific and focus only on PHM, and thus, they leave the maintenance strategies terminology out of scope.

A core ontology for condition monitoring, CM-core, defines a basic set of concepts to understand the condition monitoring domain [START_REF] Cao | Towards a core ontology for condition monitoring[END_REF]. Such a core ontology serves as a basis for other domain ontologies that can be used in several applications. It also builds upon the "Ontology Development 101" [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF] and uses UML to represent the ontology. As for the previous two ontologies, it focuses only on condition monitoring, which is part of current trends for maintenance strategies but not presented as such in CM-core. ROMAIN [START_REF] Karray | ROMAIN: Towards a BFO compliant reference ontology for industrial maintenance[END_REF] Another related work is presented in [START_REF] Lupp | Template libraries for industrial asset maintenance: A methodology for scalable and maintainable ontologies[END_REF], in which template libraries are suggested to build an ontology for the evaluation of maintenance strategies. This research is oriented on a novel methodology to build and maintain modular ontologies using maintenance strategies assessment as the use case. The terminology applied to describe the use case does not cover the current trends in maintenance strategies.

As part of a multidisciplinary effort to construct open access ontologies that can be used for industrial purposes, the Industrial Ontology Foundry (IOF) has been created in 2016 (IOF, 2020). Within the IOF, there is a specific group working for maintenance management. At the moment of the creation of OMSSA, no stable versions of the ontologies from IOF were available. However, IOF ontologies are BFO compliant and use some mid-level reference ontologies that have been considered for OMSSA. This will allow a future alignment of OMSSA to other IOF ontologies. The top-level and mid-level ontologies reused in OMSSA are presented in chapter 4.

The above-mentioned ontologies have at least one of the following limitations:

• Their scope does not cover maintenance strategies or present a limited scope where important concepts for maintenance strategy selection are not considered. • Their maintenance strategy taxonomy does not include the current trends in predictive maintenance. This leaves behind concepts that are currently important when selecting maintenance strategies. • Their development framework does not consider the alignment to a top-level domain-neutral ontology which complicates their reuse and/or interoperability with other related ontologies.

OMSSA aims at covering the gaps in the above-mentioned ontologies by fulfilling the following requirements:

• Capture the core notions related to the maintenance strategies. • Consider the current trends in maintenance strategies.

• Be aligned with a top-level domain-neutral ontology.

• Use the established terminology by norms, standards, and domain experts of maintenance strategies.

Given this research opportunity, the scope for the OMSSA was defined as maintenance strategy selection and assessment. As part of the ontology scope delimitation, a set of competency questions are proposed. These questions can be used for the model evaluation as they serve as a fidelity measure of the model with real-life phenomena [START_REF] March | Design and natural science research on information technology[END_REF]. Maintenance experts would be able to recommend a specific strategy to address a specific failure mode of an item or asset. The following competency questions are proposed to delimit the OMSSA scope:

1. What are the failure modes associated with an item or asset? 2. What is the cause of a failure mode? 3. What is the criticality of a failure mode? 4. What is the recommended maintenance strategy for a failure mode? 5. What is the triggering event specification for a specific maintenance action? 6. What is the benefit of implementing a specific maintenance strategy? 7. What is the risk of implementing a specific maintenance strategy?

As terms sources for OMSSA, several maintenance standards (European Committee for Standardization, 2017; International Electrotechnical Commission (IEC), 2018; International Organization for Standardization (ISO), 1997(ISO), , 2003(ISO), , 2012a;;[START_REF] Mimosa | Open system architecture for condition-based maintenance (OSA-CBM)[END_REF], expert knowledge and existing related ontologies have been consulted. Special attention is given to the terms that are aligned to BFO, as it is selected as the top-level ontology for the current model. An identifier has been assigned to the most relevant sources of terms. These identifiers are summarized in Table 1 and later used in the following section for traceability purposes of OMSSA terms.

Ontology for maintenance strategy selection and assessment (OMSSA)

Maintenance management trends are now more oriented towards the analysis of data to establish the right moment to trigger maintenance actions based on the condition of the maintainable system. The condition is a quality that is normally used to describe the capabilities of an item to fulfill itsfunction. Condition can be described by four different values: nominal, degraded, critical, and failed [START_REF] Ramasso | Prognostics in switching systems: Evidential Markovian classification of real-time neuro-fuzzy predictions[END_REF]. For each item, there must be a specification to be able to assess its current condition:

• Nominal_condition refers to the range of parameters in which the item is intended to operate. • Degraded_condition refers to an item that can perform its intended function but is not within the nominal operation parameters. • Critical_condition is a sub-class of degraded_condition in which the item has over-shot the safety degradation thresholds, and a failure is imminent.

• Failed_condition refers to the complete impossibility of the item to perform its intended function after a failure.

Figure 4 shows a generic example of the evolution of the health/degradation of an item. The horizontal axis represents the life cycle of the item, and the vertical axis is an index that represents its health or degradation, for example, the reliability. The time in which the item works within the limits of nominal_condition is described by a process that ends when a fault appears. The fault will affect the item operation, accelerating its degradation. Within the accelerated degradation process, there is a safety degradation threshold that defines the starting point of the critical_condition. The safety degradation threshold is imposed by a safety operating margin to prevent the actual failure. Table 2 summarizes the definitions for all terms in Fig. 4.

Condition is described by the condition_data, which is at the same time the input for other processes to determine the triggering events for maintenance actions (see Fig. 5). These processes are carried out by a predictive_maintenance_system and can be used to detect incipient faults (fault_detection), assess degradation until a specific threshold (degradation_ threshold_overshoot), and forecast the remaining useful life of the item or one of its components (failure_forecasting).

Nevertheless, there are two other triggering events that do not use advanced predictive maintenance techniques but cannot be ignored: the failure of the item and a fixed_time_recommendation prescribed by a preventive_maintenance_plan.

Having a clearer idea of the different triggering events presented in Fig. 5 and the maintenance_strategy taxonomy introduced in "Sect. Maintenance strategies", the next step allows setting the relations between the triggering events and the maintenance strategies. Figure 6 shows these relations in which a corrective_maintenance strategy is related to a failure, a preventive_maintenance strategy is related to a fixed_time_recommendation, and a predictive_maintenance strategy is related to fault_detection, degradation_ threshold_overshoot, or a failure_forecast. These relations will allow classifying the different maintenance actions in the different maintenance strategies. Table 3 summarizes the concepts presented in Figs. 5 and6.

The maintenance_strategy_development_ process is composed of different analyses and technical developments (see Fig. 7). There should be at least one maintenance_strategy for each failure_mode of an item. Failure modes and their impacts must be well known so that the most suitable strategy could be suggested. The Failure Mode, Effects and Criticality Analysis (FMECA) (International Electrotechnical Commission (IEC), 2018) is often used to assess the impact of failure modes of an item, their potential causes, risks (effects), and criticality [START_REF] Zhou | A research on intelligent fault diagnosis of wind turbines based on ontology and FMECA[END_REF].

The FMECA can be used as the starting point for the maintenance strategy development. Several proactive strategies can be suitable to address a failure_mode, starting with fixed time recommendation and coming to a precise failure prognostic. The selection of the most suitable proactive strategy depends on the technology readiness for each application, on the operational context, the implementation cost, and the potential benefits and risks of implementing predictive maintenance. FMECA has a report (represented as OMSSA class) composed of the CCO: Information Content Entities explaining the different aspects that have been considered to select a specific maintenance strategy. Among these information entities, one can find the functional_failure of anitem, the failure_mode, the cause_of_failure, the failure_effect, the criticality, and failure_likeliness. The instances for all these entities are compulsory to be known when selecting a maintenance strategy using a FMECA.

A Cost-Benefit-Risk_Analysis is a complementary method that is used to assess the suitability of a strategy when several options are possible; especially when it includes the implementation of specialized systems for health monitoring, fault detection and identification, health assessment, and failure forecast that represent an the FMECA and the CMMS. One of these data is the maintenance_cost that has been accumulated by an item in a specific interval of time; it is likely to justify the implementation of new maintenance strategies by the reduction of these costs.

The most advanced strategies that aim at performing accurate diagnosis and prognosis on the item rely on specialized tools, methods, and systems for decision support. These tools or systems demand engineering work for their design and implementation. That is why a technical development process is also included as part of the maintenance strategy development. oThe engineering work performed in this process leads to a preventive_maintenance_plan and/or a predictive_maintenance_system, depending on the item to be maintained and its operational context. important initial investment but are also attractive in terms of potential benefits. As [START_REF] Saxena | Requirements Specifications for Prognostics : An overview[END_REF] explains, a Cost-Benefit-Risk_Analysisis vital to justify the implementation of more advanced maintenance strategies. As for FMECA, the Cost-Benefit-Risk_Analysis has a corresponding report class in OMSSA. This report contains important information content entities that are considered to select a new maintenance strategy, especially when justifying the transition of existing preventive strategies to predictive ones or when upgrading the type of predictive strategy. Among these information content entities, one can find the implementation_benefit of the new strategy, its relatedimplementation_risk, andimplementation_cost. It is important to mention that for the Cost-Benefit-Risk_Analysissome data should be gathered from other sources such as As it can be seen, the maintenance strategy development has many interdependencies among the different engineering activities. It is important to point out that there are other factors that can affect the development of a maintenance strategy and are not part of these engineering processes, such as production policies or authorities' regulations. These can be seen as "external" dependencies as the maintenance engineer may not directly intervene on them. These external dependencies are included in OMSSA in the class maintenance_strategy_dependency.

Once the maintenance_strategy is selected to address a failure_mode of an item, a maintenance_action is specified in which the expected triggering_event will be defined. This specification can be later compared to the actual triggering_event of a maintenance_action that is normally recorded in a work order report. This comparison between the specification and the report helps to validate and assess the maintenance_strategy over time. A knowledge base created with OMSSA can store all the maintenance strategies assigned to the components of an item, some queries on the maintenance records can automate the assessment on the proposed strategies allowing to re-adjust or change the strategy when it is no longer suitable. Figure 8 shows the classes and the relations that can be used to assess the maintenance_strategy for a given Fig. 7 Relations for the maintenance strategy development process Fig. 8 Relations between the classes to assess maintenance strategies tion aims at providing evidence of the consistency of the model, meaning that it fulfills the technical requirements for its development. The validation provides evidence that the model when in use, fulfills the objectives for which it was developed.

As OMSSA was developed using the Protégé editor, the verification can be carried out using one of the reasoners embedded in the editor. Different reasoners can be installed and used to verify the model's consistency. These reasoners can be configured to verify different aspects of class inferences, object property inferences, data property inferences, and individual inferences such as hierarchy, domain, range, and conflicting disjoint assertions [START_REF] Nuñez | OntoProg: An ontology-based model for implementing Prognostics Health Management in mechanical machines[END_REF]. It is important to make sure that when establishing relations among classes and instances, there are no contradictory or duplicated statements. The HermiT OWL reasoner [START_REF] Glimm | HermiT: An OWL 2 reasoner[END_REF], embedded as a Protégé plug-in, was used to verify OMSSA consistency. During the verification process, several inconsistency alarms were detected, forc-failure_mode. For OMSSA purposes, the concepts related to the work orders reports have been imported from ROMAIN (see "Sect. Ontology engineering") as it already offers a complete set of information content entities that can be used to describe a maintenance_action. OMSSA reuses these ROMAIN classes and aligns them to the newer version of CCO (version 1.3). An important class incorporated in OMSSA as part of the maintenance work order report is the Triggering_event_report. Table 4 summarizes the definitions of classes related to FMECA, cost-benefit-risk analysis, and maintenance reports used for maintenance strategies selection and assessment.

Evaluation and discussion

The evaluation of the model is composed of two main steps: verification and validation. The definitions of verification and validation are derived from (INCOSE, 2015). The verifica- Cost-benefit-risk analysis A BFO: process, which is part of the strategy development process, it aims at evaluating the implementation of a more advanced maintenance strategy for an item compared to the current one. It considers the failure risk, the cost, and the benefits of its implementation 12, 13, 14

Cost-benefit-risk analysis report A CCO: report subclass. It carries the information content entities that describe the result of an OMSSA: Cost_benefit_risk_analysis To validate its functionality, OMSSA was populated with the information of a generic FMECA based on a real air compressor. This 10HP air compressor supplies 10 l/s of air at 8 bar to a pneumatic cutting machine. The FMECA was developed by maintenance experts who determined the failure modes, their causes, effects, and criticality for all the air compressor components. These variables led the experts to suggest suitable maintenance strategies. As OMSSA was instantiated with the air compressor case study, it becomes a knowledge base on maintenance strategies for an air compressor [START_REF] Musen | Ontology development 101: A guide to creating your first ontology[END_REF].

To measure OMSSA fidelity to the real world, the ontology-based knowledge base (meaning the instantiated ontology) should be able to answer questions like an expert would do [START_REF] Grüninger | Methodology for the design and evaluation of ontologies[END_REF][START_REF] Heravi | Ontology-based standards development: Application of OntoStanD to ebXML business process specification schema[END_REF][START_REF] Raad | A survey on ontology evaluation methods[END_REF][START_REF] Steiner | Validating domain ontologies: A methodology exemplified for concept maps[END_REF]. To do so, the competency questions used to delimit the ontology scope can be used as a guideline. Validation of the knowledge modeling is performed by answering these competency questions with ing the restructuration of several relations among OMSSA classes. The model presented in "Sect. BFO as a top-level ontology" corresponds to a stable version with no inconsistency warnings from the reasoners.

Once the verification of the model is fulfilled, the validation process to assess the fidelity of the model with its initial application requirements takes place. For OMSSA, the scope is limited to maintenance strategy selection and assessment. Ontologies are meant to be vocabulary frameworks for practical applications. It is important to understand how it can be integrated into practical applications [START_REF] Ferrer | Towards the Adoption of Cyber-Physical Systems of Systems Paradigm in Smart Manufacturing Environments[END_REF]. Figure 9 shows the principle of the implementation of OMSSA in practical applications. OMSSA can be retrieved directly from its online repository and is aimed to be instantiated with information from different sources such as FMECA, cost-benefit-risk analysis, or CMMS engineering information, among other sources of data. Once the ontology is populated, it becomes a knowledge base of a specific domain that can be used by smart agents such as Decision Support Systems (DSS). There exist ontology libraries that can be used to integrate the different components of the system. For example, the OWL API [START_REF] Horridge | The OWL API: A Java API for OWL ontologies[END_REF] provides a Java-based platform to create the interfaces between the ontology and the data sources and between the SPARQL queries on the instantiated ontology. To do so, the SPARQL plug-in for Protégé was used [START_REF] Redmond | SPARQL Query tab for Protégé[END_REF].

As part of the SPARQL queries writing, a set of prefixes for OMSSA and all reused ontologies for its development (BFO, CCO, and RO). It simplifies the writing of the SPARQL queries for OMSSA validation. Table 5 summarizes the proposed prefixes for OMSSA validation using the SPARQL queries.

The air compressor is composed of four main items that are instantiated as: compressor_unit_1, electric_motor_1, drying_unit_1, and transmission_1. To illustrate the applicability of OMSSA, the first competency question (What are the failure modes associated with an item or asset?) will be answered by querying the instantiated OMSSA to obtain all failure modes related to the electric_motor_1. The result of the SPARQL query showed all registered failure modes for the electric motor (see Table 6 and Fig. 10). The other competency questions (questions 2 to 7 in the Ontologies in Maintenance section) are related to each failure mode. A query was performed to answer these competency questions for the failure mode Crank_damage (see Table 7 and Fig. 11). This query allowed to show the cause_of_failure, the criticality, the maintenance_strategy, and the expected trig-gering_event to perform the maintenance_action of changing and7 will help validate the consistency of the modeled knowledge in the ontology. It is important to point out that OMSSA is not only limited to FMECA classes but also modeled the knowledge for the maintenance strategy assessment and upgrade to more advanced strategies. To do so, OMSSA contains classes that can be instantiated from CMMS and cost-benefit-risk analysis reports and other engineering information sources.

The four requirements proposed for OMSSA development have been satisfied. The first requirement established in Maintenance Ontology Section for OMSSA was to "capture the core notions related to the maintenance strategies". By performing these query-based tests, the consistency of the vocabulary related to maintenance strategies in OMSSA was validated. OMSSA includes the vocabulary related to advanced strategies triggered by diagnostics and prognostics; this validates the proposed requirement for OMSSA related to include the current trends in maintenance strategies. As OMSSA uses BFO as top-level ontology, CCO as mid-level ontologies, and its scope is limited by competency questions inspired in the domain knowledge, the proposed requirement related to OMSSA alignment is also met. As the terms for OMSSA were extracted from standards and norms and domain experts for maintenance strategies, the requirement with regards to the vocabulary sources for OMSSA is also satisfied.

OMSSA covers important terms related to the maintenance strategy selection and assessment, allowing the implementation of intelligent decision support systems that can perform automated tasks in the maintenance strategy domain. For example, ontologies enable the processing and sharing of knowledge that can be used at different tasks of Case-Based Reasoning (CBR) systems, such as representing the input problem, enhancing similarity assessments, case representation, case abstraction, and case adaptation with data from FMECA, cost-benefit-risk analysis reports, CMMS, among other types of engineering data sources, to provide enough information that can be used in maintenance strategy selection and assessment. OMSSA validation was performed using information from FMECA of an air compressor to instantiate some of the OMSSA classes. Using the competency questions as a guideline to perform some SPARQL queries on the knowledge base allowed to retrieve information and answer the questions as experts in the field would do. The classes and relations modeled in OMSSA provide an overview of the knowledge around maintenance strategies that was not fully covered before. Instantiated OMSSA can be used as a terminology framework for the creation of smart decision support systems in the domain of maintenance strategies. For example, these smart DSS could emulate the experts' reasoning by implementing rules or cases extracted from the ontology to assign maintenance strategies, assess the assigned ones, and justify the implementation of more advanced strategies based on accurate diagnosis and prognosis.

As part of the perspective of future work, a comparison can be performed between the smart agents developed with OMSSA for maintenance strategy selection and established methodologies such as Multi-Criteria Decision Making Methods (MCDM). OMSSA can also be extended and used as a reference ontology for a more specific ontology of predictive maintenance systems design. This terminology framework can serve as a protocol for a smart decision support system for the design of predictive maintenance systems.

Conclusion and future work perspectives

The present study has considered the most important terms and the semantic relations among them in the maintenance strategy domain. All these terms and relations were used to build an ontological model called OMSSA (Ontology model for Maintenance Strategy Selection and Assessment) using the methodology "Ontology Development 101". OMSSA is aligned to a top-level ontology (BFO) through some mid-level domain neutral ontologies (CCO). This alignment allows OMSSA to comply with standardized ontology development practices, which facilitates its future reuse. The ontology model was verified using semantic reasoners to prove its consistency among the different terms.

A concept of the implementation of OMSSA for practical applications was proposed. OMSSA aims to be instantiated

RO: has quality

For types E and Q where E is a type of Entity and Q is a type of Quality, E has quality Q if and only if for every instance e of E there is some instance q of Q such that e "has quality" q. Here "has quality" denotes the primitive instance level relation.

Inverse of quality of

has Qualit y --------→ CCO: is about A primitive (i.e. undefined) relationship between an information entity and some entity in About -----→ CCO: is subject of The inverse of is about, which relates an Entity to some Information Content Entity is Subject O f ---------→ OMSSA: is subject failure effect A CCO: is_subject_of sub-property to define the relationship between a failure mode and a failure event is Subject O f ---------→ OMSSA: is subject of failure likeliness A CCO: is_subject_of sub-property to define the relationship between a failure mode and its likeliness to happen is Subject O f ---------→ RO: prescribes For all classes T1 and T2, if T1 prescribes T2, then there is some instance of T1, t1, that serves as a rule or guide to some instance of T2, t2 (if T2 is a type of BFO: occurrent) or that serves as a model for some instance of T2, t2 (if T2 is a type of BFO: continuant)

Fig. 2 Fig. 3

 23 Fig. 2 Basic Formal Ontology structure, based on (International Organization for Standardization (ISO) 2020b)

Fig. 4

 4 Fig. 4 Condition evolution over the item life cycle

Fig. 5

 5 Fig. 5 Relations among the different triggering events

Fig. 9

 9 Fig. 9 Implementation of OMSSA for practical applications

Fig. 10

 10 Fig. 10 Answer to the SPARQL query on Table 6

→

  RO: bearer of A relation between an independent continuant (the bearer) and a specifically dependent continuant (the dependent), in which the dependent specifically depends on the bearer for its existence bearer O f ------→

  implementation risk A RO: prescribes sub-property to define the relationship between a technical project plan and its implementation risk prescribes -------→ OMSSA: prescribes implementation benefit A RO: prescribes sub-property to define the relationship between a technical project plan and its implementation benefit prescribes -------→ OMSSA: prescribes implementation cost A RO: prescribes sub-property to define the relationship between a technical project plan and its implementation cost prescribes -------→ RO: describes For all classes T1 and T2, if T1 describes T2 then there is some instance of T1, t1 that presents the characteristics by which some instance of T2, t2 can be recognized or visualized describes ------→ RO: has output A relation between a processual entity and a Continuant such that the presence of the Continuant at the end of the processual entity is a necessary condition for the completion of the processual entity has Out put -------→ RO: is input of Inverse of has input, a relation between a processual entity and a Continuant such that the presence of the Continuant at the beginning of the processual entity is a necessary condition for the start of the processual entity has I ut put O f ---------→ RO: has part A core relation that holds between a whole and its part has Part -----→ OMSSA: has action specification A RO: has_part sub-property the represents a relation between a maintenance strategy and its maintenance action specification has Part -----→ OMSSA: has triggering specification A RO: has part sub-property the represents a relation between a maintenance strategy and its triggering event specification has Part -----→ RO: has function A relation between an independent continuant (the bearer) and a function, in which the function specifically depends on the bearer for its existence has Function ---------→ RO: precedes A relation between two occurrents. Occurrent x precedes occurrent y if and only if the time point at which x ends is before or equivalent to the time point at which y starts preceeds ------→ RO: participates in A relation between a continuant and a process, in which the continuant is somehow involved in the process partici patesin ----------→

  is a Reference Ontology for industrial MAINtenance, compliant with the Basic Formal Ontology (BFO 2.0) (See Sect. BFO as a top-level ontology)[START_REF] Arp | Building ontologies with basic formal ontology. Building Ontologies with Basic Formal Ontology[END_REF] International Organization for Standardization (ISO) 2020a, 2020b). It aims at giving a standard vocabulary framework for maintenance management inspired by Reliability Centered Maintenance (RCM) strategies. The strong point of ROMAIN is the alignment with BFO, which is a toplevel domain-neutral ontology. It allows the alignment of application ontologies with upper-level domain and reference ontologies. ROMAIN offers a robust set of classes for CMMS data, for example, the classes to define maintenance work orders records that describe maintenance actions. Many of these classes are reused in OMSSA since ROMAIN and OMSSA are BFO compliant. However, ROMAIN has a limited set of concepts related to maintenance strategies. ROMAIN aligns to a classical RCM classification for maintenance strategies, and the concepts involved in the selection of such strategies are not presented.

Table 1

 1 The identifier for the terms sources

	Reference	Identifier Reference	Identifier
	(European	1	(International	10
	Committee for		Electrotechnical
	Standardization		Commission (IEC)
	2017)		(2018)
	(Montero Jimenez	2	(International	11
	et al., 2020)		Organization for
			Standardization
			(ISO) (2012b)
	(Nuñez & Borsato,	3	Saxena et al. (2010)	12
	2018)
	(Karray et al., 2012)	4	Keller et al. (2001)	13
	(MIMOSA, 2001)	5	Kacprzynski et al.	14
			(2002)
	(Karray et al., 2019)	6	Rudnicki (2020a)	1 5
	(Arp et al., 2016)	7	I N C O S E( 2015)	1 6
	(International	8	Rudnicki (2020b)	1 7
	Organization for
	Standardization
	(ISO) 1997)
	(International	9	Protter (2005)	1 8
	Organization for
	Standardization
	(ISO) 2003)

Table 2

 2 Definitions for important classes to describe the condition of an item

	Class	OMSSA Formal definition

Condition

A BFO: quality sub-class that an OMSSA: item bears. It qualifies the operation state of the item. It states the operational parameters of the item described by OMSSA: condition data and prescribed by OMSSA: condition specification 1, 6 Condition data A CCO: Descriptive Information Content Entity that consists of a set of propositions that describes OMSSA: Condition

Table 3

 3 Definitions of the terms in Figs.5 and 6

	Class	OMSSA Formal definition

Table 4

 4 Definitions of classes related to FMECA, cost-benefit-risk analysis, and maintenance reports used for maintenance strategies selection and assessment

	Class	OMSSA Formal definition	Based on (see Table 1)
	Cause of failure	A CCO: Descriptive Information Content Entity that describes the	1, 10, 11
		cause of a failure mode. It is about a CCO: Cause that can lead to an
		OMSSA: Failure

Table 5

 5 Prefixes to perform SPARQL queries on OMSSA PREFIX rdf: < http://www.w3.org/1999/02/22-rdf-syntax-ns# > PREFIX owl: < http://www.w3.org/2002/07/owl# > PREFIX rdfs: < http://www.w3.org/2000/01/rdf-schema# >

	PREFIX xsd: < http://www.w3.org/2001/XMLSchema# >
	PREFIX OMSSA: < http://www.semanticweb.org/j.montero-
	jimenez/ontologies/2020/7/OMSSA# >
	PREFIX bfo: < http://purl.obolibrary.org/obo/ >
	PREFIX ro: < http://www.obofoundry.org/ro/ro.owl# >
	PREFIX exro: http://www.ontologylibrary.mil/CommonCore/
	Upper/ExtendedRelationOntology#
	PREFIX ieo: < http://www.ontologylibrary.mil/CommonCore/Mid/
	InformationEntityOntology# >

Table 6

 6 SPARQL query to answer the first competency question on Compressor Unit 1

SELECT ?item ?FailureMode WHERE{ ?item rdfs:label "Compressor Unit 1" ?item OMSSA:has_failure_mode ?FailureMode}

Table 7

 7 SPARQL query to answer the competency questions for the failure mode "Crank damage"

	SELECT ?item ?FailureMode ?Cause ?Criticality
	?MaintenanceStrategy ?TriggeringSpecification
	WHERE{ ?item exro:has_function ?Function
	?item OMSSA:has_failure_mode ?FailureMode
	?FailureMode rdfs:label "Crank damage"
	?FailureMode OMSSA:is_subject_of_failure_cause ?Cause
	?FailureMode OMSSA:is_subject_of_criticality ?Criticality
	?MaintenanceStrategy ieo:is_About ?FailureMode
	?MaintenanceStrategy OMSSA:has_maintenance_action
	?MaintenanceaAction
	?MaintenanceAction OMSSA:has_triggering_specification
	?Triggering Specification}
	Specification}
	the oil. Answering simple queries such as those in Tables 6

Table 8

 8 Relations used in OMSSA

	Definition
	Relation

Acknowledgements

The authors want to acknowledge the contribution of M.Eng. Carlos Piedra Santamaría from Tecnológico de Costa Rica for providing the FMECA analysis applied on the air compressor that was used as a case study for OMSSA validation.

Data availability OMSSA can be accessed by the following link: https:// github.com/jjmj128/OMSSA.

Declarations

Conflict of interest Juan José Montero Jiménez, Bernard Grabot, Rob Vingerhoeds and Sebastien Schwartz declare no conflict of interest for the current study.

Appendix

See Table 8. [START_REF] Prentzas | Combinations of case-based reasoning with other intelligent methods[END_REF]. Some examples of ontological-based similarity retrieval applications can be found in [START_REF] Fernández | Semantically enhanced Information retrieval: An ontology-based approach[END_REF][START_REF] Qin | An ontology-based semantic retrieval approach for heterogeneous 3D CAD models[END_REF]. The knowledge represented in OMSSA can be used to develop a smart system that can deal with the management of maintenance strategies, selecting the strategy to address different failure modes of an item, and assessing over time the efficiency and accuracy of the selected strategy. The creation of such reasoning among the OMSSA classes is out of the scope of the current article. As mentioned, OMSSA is part of a bigger research project in knowledge reuse for maintenance decision support systems. An extended version of OMSSA has already been used to support a DSS that uses CBR principles to select the suitable model or algorithm to implement predictive maintenance strategies given a specific use case [START_REF] Montero Jiménez | Enhancing predictive maintenance architecture process by using ontology-enabled case-based reasoning[END_REF]; OMSSA plays an important role in the semantic similarity computation which is needed for the CBR retrieve engine. This also validates the applicability of OMSSA for practical implementations, not only supporting the maintenance strategy selection but also helping in the implementation of advanced strategies oriented to perform accurate diagnostics and prognostics of productive assets.

The structured methodology followed to develop OMSSA allows its alignment to other BFO-compliant ontologies, such as for example, those that are currently under development by the Industry Ontology Foundry. It is important to point out that ontologies evolve over time as knowledge in the different domains also evolves. The structured method used to develop OMSSA helps in the traceability of classes and relations, facilitating its future maintenance and update.