Abstract
In this paper, we present a domain-specific, open access, reference ontology (ROMAIN) for the maintenance management domain. We use a hybrid approach, based on a top-down alignment to an open source top-level ontology, the Basic Formal Ontology (BFO), and a bottom up focus on classes that are grounded in maintenance practice. We constrain the scope of the ontology to the classes that are unique to the maintenance management practice, such as maintenance strategy, degradation, and work order management, rather than modeling the entire domain of maintenance. This approach reduces the scope of the development task and enables reasoning to be tested at a manageable scale. ROMAIN provides a unifying framework that can be used in conjunction with other BFO compliant sub-domain ontologies, such as planning and scheduling ontologies. The proposed ontology is validated using real-life data in the context of a use case related to evaluating the effectiveness of maintenance strategy.
Introduction
The competitiveness and responsiveness of manufacturing firms depend, in part, on how effectively they maintain their assets and ensure the availability of their resources. Maintenance is defined as “the actions intended to retain an item in, or restore it to, a state in which it can perform a required function” (IEC, 2016, 2011). Almost all assets of any value need maintenance and, as a result, there has evolved organizational structures and processes to manage maintenance with theory and practice to support its delivery. Maintenance management practices are documented in Standards (IEC, 2016), textbooks (Kelly, 2006, 1997; Palmer, 1999) and by professional societies (SMRP, 2009; GFMAM, 2016).
Data are key to the effective and safe maintenance of assets over their life cycle. This data is generated by, and drawn from, various sources such as maintenance management systems, design documentation, original equipment manufacturer manuals, process control systems, third party service providers, risk management assessments and failure investigations (Morello et al., 2010), to name just a few. However, due to the heterogeneity of data sources and diversity of data types, unlocking the real value of data and discovering the useful patterns of knowledge embedded in the maintenance data has always presented a major challenge (Bendell, 1988; Karray et al., 2011; Knapp and Hasibether, 2011). Ontologies can effectively address this challenge by semantic annotation, integration, consistency checking and organization of data (Karray et al., 2010).
Nowadays most asset-owning organizations will have a Computerized Maintenance Management System (CMMS) whose data schemes conform to a common understanding of work flows in maintenance practice. As a result, the way maintenance work is managed across different sectors such as defense, manufacturing, and service, is remarkably consistent. The details of the work vary with the asset type but the modeling entities and workflow processes are common. This makes maintenance an ideal candidate for an ontology that can have wide-spread application as the classes used to describe the maintenance management process and information are commonly used by the maintenance community.
Over the last 25 years, groups in industry, academia, and on standards committees have developed ontologies for engineering and asset management applications. These works include maintenance concepts but do not focus on maintenance management practice and processes. As a result, there has been limited uptake by maintenance practitioners (Hodkiewicz, 2018). There is a need for a reference ontology in the maintenance domain that can serve as the overarching semantic model connecting various application ontologies related to maintenance. The work proposed in this paper is positioned to fulfill this need.
In this paper, we present a reference ontology for industrial maintenance management. The reference ontology developed in this work uses a top-level ontology. The development of ROMAIN started with identifying the general terms most commonly used in maintenance practice and continued with the representation of more complex entities in the domain. Although the ontology, in its current state, covers most of the key notions specific to the maintenance domain, it can be extended in order to take account of the technological and scientific advances. The rest of the paper is organized as follows. We start with the motivation involving a description of the maintenance management domain. An overview of the current state of the art in ontology practice is provided in Section 2, next followed by a critical review of previous work related to maintenance in Section 3. Section 4 is devoted to discuss best practices of ontology development. The development approach for ROMAIN is then described and the structure of the ontology is presented in Sections 5 and 6. We evaluate ROMAIN against its design principles and validate it with a use case related to measuring the effectiveness of maintenance strategy in Section 7. Finally, we discuss challenges and future directions.
Background of maintenance management
This section provides the definitions and the necessary background information related to some of the important entities in maintenance management. As all assets are likely to fail at some time, there exists a business function to maintain the asset so that the production process or service provided by the asset can continue. This function is called maintenance management. The maintenance management process follows a process such as that shown in Fig. 1. Key steps in this process are developing maintenance strategy and life plans, administration steps involving planning, procurement and scheduling, task execution, administration associated with cost and performance assessment and strategy optimization. The steps in this process that are specific to maintenance are shown as shaded. Non-shaded steps contain processes, such as planning, scheduling and cost management, that are commonly used in other functions in an organization.
Maintenance practitioner view of the management process, adapted from Coetzee (2004).
Maintenance management is not a core subject in many engineering curricula and the maintenance world is largely impenetrable to those who have not worked in it as it has its own tribes, language and customs (Reiman and Oedewald, 2004). With this in mind, core maintenance and work management concepts are explained in the following section. Italics are used to identify concepts that will be represented as classes in the domain ontology. These classes are drawn from maintenance practitioner texts and references (Stuber, 2016; Coetzee, 2004; Kelly, 2006; Palmer, 1999).
Each asset has a primary function, this describes the main reason(s) for owning or using the asset. It may also have a set of secondary functions due to the need to fulfill regulatory requirements and requirements concerning issues of protection, control, containment, comfort, appearance, energy efficiency, and structural integrity (SAE, 2011). The maintenance action performed on an asset depends on the function to be maintained and the consequence of a functional failure. Since the 1970s, the most common approach to developing an asset’s maintenance plan is a process called Reliability-centered Maintenance (RCM). In RCM, the emphasis is on identifying each functional failure and selecting an appropriate maintenance strategy to manage each failure mode. The output of the RCM process is the identification of maintenance strategies (IEC, 2011) and associated maintenance tasks for each maintainable item. A collection of strategies and the associated tasks over the life cycle is called a maintenance plan. The concepts described above for function, maintenance strategy, maintenance plan, and maintainable item are specific to maintenance and need to be represented in a maintenance domain-specific ontology.
There are six types maintenance strategies in RCM. These are a) condition-based, b) fixed interval restoration (also called scheduled restoration), c) fixed interval replacement (also called scheduled discard), d) failure-finding, e) run-to-failure, and f) design-out (also called modification) (Moubray, 2007). The strategy selected depends on failure behaviour and the consequence of failure. Following strategy selection, a specific maintenance standard work procedure and interval are developed and this information is stored in the CMMS. Some of the strategies, except run-to-failure and modification, are preventative or predictive in nature. Individual preventative tasks are triggered at the appropriate time by the CMMS and each instance is represented by a maintenance work order record (MWO). Corrective work is triggered by a failure event on a component resulting from a non-conformity. The observed failure is documented using a maintenance work notification as part of the work identification stage. Once work is identified, either through failure events or actions triggered by maintenance strategies, then the work is planned and scheduled. Planning involves the procurement of parts and the organization of personnel, tools, other resources and the availability of the asset. Once complete work can be scheduled. Finally, the value-adding step is when the work is executed by maintenance personnel. After execution work there should be analysis of the quality and effectiveness of the maintenance work and opportunities for improvement identified. We suggest that the processes of planning, scheduling, and execution are generic to many industrial processes. As a result they do not need to be developed specifically for this maintenance ontology. Instead existing ontologies that are aligned to the same top-level ontology can be used to represent these processes.
Maintenance management can be viewed through two different lenses. The first is the view of maintenance practitioners of the work management process described in the previous section. In this view, shown in Fig. 1, maintenance is a process in which work on many assets is identified, planned, scheduled, executed and analyzed. This view is seldom apparent to operators and owners and is almost entirely absent in maintenance ontologies built to date.
An asset-centric view of maintenance, commonly represented as a phase in one part of an asset’s life cycle.
The alternate view considers the requirements of a specific asset, how it should be maintained over its life, its reliability and the risk that its failure presents to the organization. This view, shown in Fig. 2, takes an asset life cycle perspective that is primarily of interest to operators and owners of assets (ISO, 2014), rather than maintenance management practitioners. Ontologies that mention maintenance usually have this perspective (Ebrahimipour and Yacout, 2016; Karray et al., 2012; Matsokis and Kiritsis, 2010; Otte et al., 2018). Examples include the Product Life Cycle Management Ontology proposed by Matsokis and Kiritsis (2010) and a more evolved version of this ontology focusing on the operating phase of the life cycle and integrating concepts related to the maintenance field such as alarms, events, and activities (Matsokis et al., 2010). Likewise, Karray et al. (2012) proposed IMAMO (Industrial Maintenance Management Ontology) as a modular ontology that decomposes the maintenance field to according stakeholders’ views. Another notable ontology is CDM-Core, a publicly available manufacturing ontology, developed according to condition monitoring data model from ISO13372 (ISO, 2012) to semantically annotate sensor data. The CDM-Core work focuses on an asset’s performance rather than on maintenance work management but has useful descriptions of quality measures and a detailed verification process (Mazzola et al., 2016). It is also to note that most of these ontologies do not use any axioms which prevents them from being used effectively for reasoning and consistency checking services.
Ruiz et al. (2004) developed a semi-formal ontology that represents products, roles, activities, processes, workflow, and actions related to software maintenance. Software failure modes and maintenance processes are different from those of physical assets. Therefore, this work is not considered further here. Other ontologies in the maintenance domain have been built for specific use cases such as for failure modes and effects analysis (Ebrahimipour et al., 2010) and maintenance on a pneumatic values (Ebrahimipour and Yacout, 2015).
None of the ontologies mentioned above use a top-level ontology. We observe that when individual groups develop domain ontologies that are focused on their specific local needs, the resulting ontologies are incompatible, isolated, and non-sharable. These problems are widely recognized in the ontology sphere, where it is commonly assumed that they can be (or even are already being) addressed by the use of sophisticated ontology mappings or similar technology (Arnold and Rahm, 2014). In our experience, ontologies developed independently and on the basis of distinct sets of ontology development principles (or even on the basis of no principles at all) remain in almost every case unmapped. Moreover, even where mappings are created, they are rarely able to be updated in the needed ways because the ontologies on both sides of the mapping-relation are themselves being changed independently and on asynchronous cycles. The result is incremental decay of almost all existing mappings. We believe that the use of a top-level ontology as well as a set of shared principles provide a common overarching framework that ensures consistent development of ontologies across communities of researchers and ontology developers such as the case of OBO Foundry in the biomedical domain (Smith et al., 2007).
There were some efforts related to development of the top-level ontology for process plant design engineering in the 1990s. This was driven by the oil and gas and chemical industries. The resulting ontology is documented in the ISO Standard 15926 (ISO, 2003) and described by Batres et al. (2007). The ISO 15296 Standard resulted in a number of applications relevant to the process plant design phase (Batres et al., 2014) but has not resulted in the development of a domain-specific ontology for maintenance management activities.
As part of manufacturing ontology suite, a Basic Formal Ontology (BFO; Arp et al., 2015) compliant ontology of maintenance was proposed in the scope of CHAMP project (Otte et al., 2018). Because the main focus of CHAMP project is on manufacturing processes and entities, the coverage of maintenance in this ontology is limited and the maintenance terminology used drawn from less technical and reliable sources such as Wikipedia. It is not apparent that there has been a review of the maintenance classes against maintenance standards and practice.
Ontologies have been widely used for knowledge representation as they provide a common vocabulary for modeling a specific domain by capturing knowledge in a structured and formal way. Gruber (1995) defined ontology as ‘an explicit and formal specification of a shared conceptualization’. The quality and viability of an ontology depends on the methodology followed for ontology development. Also, the requirements for an ontology is affected by how the ontology is positioned in the stack of ontologies ranging from foundational ontologies to application ontologies. In this section, an overview of different types of ontologies is provided to set the stage for positioning the proposed maintenance ontology as a reference ontology. Best practices for ontology development are presented next. One of the novelties of the proposed ontology is conforming with a top-level ontology. Therefore, the benefits of using top-level ontologies are discussed toward the end of this section.
Types of ontologies
Several classifications are presented in the literature to differentiate ontologies based on their level of formality and generality. Top-level ontologies are generic ontologies that can be viewed as ontologies describing the top-level classes that can be used for building other ontologies. They enable interoperability between domain ontologies that incorporate the same top-level ontology (Noy, 2004), thus facilitating data integration and knowledge reuse. Examples of foundational ontologies include the Suggested Upper Merged Ontology (SUMO; Pease, 2006), the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE; Masolo et al., 2002), the Basic Formal Ontology (BFO; Arp et al., 2015), the Unified Foundational Ontology (UFO; Guizzardi and Wagner, 2010), Yet Another More Advanced Top-level Ontology (YAMATO; Mizoguchi, 2010) and ISO15926 (ISO, 2003). A comparison between some of the previously mentioned top-level ontologies can be found in the work by Mascardi et al. (2007). In contrast, domain ontologies are only applicable to specific domains with a specific point of view. They describe the vocabulary related to a particular area of knowledge (such as biology, environmental sciences, maintenance, etc.) and use classes introduced in the top-level ontology. A reference ontology brings together the existing domain ontologies by providing canonical and precise definition of the common entities used in the domain. Reference ontologies focus on rich and axiomatic representation of the intended meanings of common terms in a domain (Andersson et al., 2006). For this reason, reference ontologies often go through several rigorous quality checks according to principled methodologies. Reference ontologies are typically non-proprietary and non-implementation-specific and can be adopted as a sort of standard in a community to create application ontologies (Falquet et al., 2011). Application ontologies are specializations of reference ontologies and they are created to accomplish some specified local tasks or applications.
Best practices in ontology building
According to Simperl et al. (2010), most ontology development works are based on an unprincipled approach to ontology engineering which results in non-interoperable and inconsistent ontologies. For the purpose of construction of any ontology, many works (Arp et al., 2015; Arpirez et al., 1998; Gruber, 1995), elaborate clearly principles to respect in order to design useful ontologies. Many of these principles turn on the fact that, since ontologies are built to be shared between actors, it is beneficial if the ontologies used in a given domain share a common upper layer of well-defined terms (Smith, 2006). This upper layer should be domain neutral, since its aim is to represent the most general categories of entities and the most general relations within and between them (Arp et al., 2015). The categories taken together must provide the means to define classes whose instances can be found in any realm of reality. According to Smith and Ceusters (2010), a reference ontology should cover the terminological content of the settled portions of given scientific discipline. In practice the ontology building process is more efficient if key concepts are defined according to a top-level ontology first rather than developing the ontology from the bottom up and then trying to align it retrospectively to a top-level ontology. It is also important that each ontology should have an is-a hierarchy having the structure of a directed rooted tree. Terms in the ontology should be defined in a consistent manner. Finally, the ontology must be available to be used by all potential users with few constraints.
Value of alignment to a top level ontology
When multiple maintenance ontologies are developed in relative isolation from each other by different communities, disconnected information silos will be created. To ensure that different application ontologies employ comparable and mutually-understandable definitions and knowledge constructs, they need to share a common top-level formal ontology. The use of a top-level ontologies facilitates the alignment between several domain ontologies and promote greater data interoperability through conformity to a common semantic model. Top-level ontologies also play the same role as libraries in software programming tasks. These libraries of defined classes and relationships can be reused thereby reducing development time. Using a top-level ontology also enables more effective quality assurance and governance when developing ontologies. The usage of top-level ontologies for integrating information and sharing knowledge among heterogeneous sources has been motivated in various related works (Baumgartner and Retschitzegger, 2006). Top-level ontologies have been used in various domains including situation awareness, pervasive systems (Stevenson et al., 2009), biomedical information systems, government and US military system (Semy et al., 2004), emergency management (Elmhadhbi et al., 2019) and manufacturing (Otte et al., 2018).
Basic Formal Ontology (BFO)
BFO is a top-level ontology, which has been introduced to support information retrieval, analysis and integration in diverse domains. BFO is at the core of the Open Biological and Biomedical Ontology (OBO) foundry,1
The Industrial Ontologies Foundry (IOF)2
For ROMAIN, we consider the use of BFO as it has already been used successfully in OBO Foundry for providing a common ground for several interoperable ontologies and it is in the process of becoming an ISO Standard (ISO 21838-2). Additionally, BFO is sufficiently small and covers classes to model functions and roles, which are necessary for engineering knowledge representation. Also, it is quality controlled through aggressive review and reuse by a sizable community of users. ROMAIN imports portions of BFO compliant mid-level ontologies such as Common Core Ontologies (CCO; CUBRC, 2014) and Information Artifact Ontology (IAO; Ceusters, 2012).
The structure of BFO 2.0.
As shown in Fig. 3, BFO 2.0 consists of two main categories of entities: continuants and occurrents. Continuants are entities which continue to exist through time while maintaining their identity and have no temporal parts but are associated with a history. A history names an entity belonging to the realm of occurrents (which can have temporal parts). Occurrents are entities that occur, happen, unfold or evolve with time. BFO:occurrent can be either an entity that unfolds itself in time, or it is the instantaneous boundary of such an entity. Table 1 summarizes key categories encountered in BFO as defined by Arp et al. (2015).
BFO’s classes definitions
This section provides more details about the proposed maintenance ontology in terms of objectives, requirements, and competency questions.
ROMAIN objectives
The scope of the current version of the ontology is limited to those classes and relationships needed to represent various entities related to the maintenance management process as described in Section 2.
ROMAIN requirements
According to what is discussed in the previous sections, the key requirements of the ROMAIN ontology are listed as follows:
The ontology has to be aligned with a top-level ontology and reuses classes from mid-level ontologies. The ontology has to capture the core notions related to the domain of maintenance management. The ontology has to use the established terminology of the maintenance management domain. The ontology has to follow the design principles for ontology development.
Competency questions
Grüninger and Fox (1995) proposed competency questions (CQs) as a technique for defining the ontology specifications. These CQs consist of a set of questions, stated in natural language, that the ontology must be able to answer. Below are some of the examples of the CQs that ROMAIN, and its derivative application ontologies, should be able to answer:
How many breakdown work orders were executed? How many replace orders were executed before the expected replacement interval What is the total cost of failures on the maintainable item Did any scheduled restorations occur before the target interval of What is the cost of the work done initiated by an inspection?
ROMAIN structure
This section describes the core classes of ROMAIN. Figure 4 illustrates the structure of the ontology using some of its main classes. Descriptions of the various classes and their relationships are given in the sections below. We note that the prefix ‘ROM’ is used to identify ROMAIN classes.
The class diagram showing the relationships between some of the continuants, occurrents, and information entities.
Before introducing ROMAIN classes, we introduce the used relations in order to well understand the definitions of these classes and their proprieties. There are two groups of relations in the proposed ontology. The first group is composed of the relations specific to ROMAIN and the second group is composed of the generic relations imported from other external ontologies. The Relations Ontology (RO; Smith et al., 2007) in particular is used extensively. RO is a collection of relations intended primarily for standardization across ontologies in OBO Foundry. RO is developed in the context of this Foundry initiative and, therefore, it is in compliance with BFO. Table 2 summarizes all relations used in ROMAIN.
Terms used for ROMAIN’s relations
Terms used for ROMAIN’s relations
Continuants are the entities that continue or persist through time, such as objects and their functions and qualities. There are three types of continuants in BFO, namely, generically dependent, independent, and specifically dependent continuants that are discussed separately in the context of maintenance management in this section. The definitions of the ROMAIN’s generically dependent continuants, independent continuants, and specifically dependent continuants are provided in Table 3, Table 4, and Table 5 respectively.
ROMAIN generically dependent continuants
ROMAIN generically dependent continuants
ROMAIN independent continuant
ROMAIN specifically dependant continuant
Independent continuants do not depend on other entities for their existence. Examples of independent continuants in ROMAIN include the machines, equipment, devices, or components that become the subjects of maintenance strategies and actions. They are considered to be instances of Artifact class in ROMAIN. An Artifact, a class imported from CCO, is an object that is designed by some agent to realize certain functions. An Artifact is an asserted class that can assume different roles in maintenance scenario and become an asset, a component, or a maintainable item as shown in Fig. 5. These notions are further defined in the following sections.
Asset. An Asset, as an independent continuant, is an Artifact that has potential or actual value to an organization (ISO, 2014). Asset is treated as a defined class in ROMAIN. It is formally defined as an Artifact that bears an Asset Role for an organization.
Component. A Component is an Artifact that bears a Component Role. A Component Role is a role that is borne by an Artifact when it become a part of another artifact, to provide a particular function.
Maintainable item. A Maintainable Item is an artifact when it bears the Maintainable Item Role in the context of a maintenance strategy. An Asset can be a Maintainable Item or it can be composed of one or more maintainable items. Each Maintainable Item has one or more functional failures. A single Component can also become an instance of Maintainable Item. The selection of what is or what is not a Maintainable Item is a decision of the maintenance group and a result of maintenance strategy development process. It depends on the resources and capabilities available at a specific site. For example, they may choose to rebuild pumps, in which case the maintainable items will be the bearings and other items that make up the pump. Or they may choose to send the pump to an external rebuild shop in which case the pump is the maintainable unit.
Different roles an artifact can bear in the domain of maintenance.
A specifically dependent continuant (SDC) is an entity that depends on other independent continuants for its existence. Quality, function, and role are sub-types of this SDC class. Functions, in particular, are directly used when representing a functional failure in an artifact since a failure is the termination of the ability of an artifact to perform a required function. A failure is often a consequence of some change or degradation in one or more qualities of the artifact or its parts. A failure can be attributed to one or more nonconformities. A nonconformity is a deviation from a requirement. It is one of the core classes in ROMAIN and is hence described in more detail below.
Nonconformity. In general, nonconformity is non-fulfillment of a requirement or expectation. In ROMAIN, Nonconformity is formally defined as a specifically dependant continuant that inheres in a material entity and deviates from a design specification. It can be a loss of quality, function, or capability in an item that results from a degradation process. Each nonconformity can also trigger other degradation processes that may cause more nonconformities in the same bearer or other external bearers. For example, reduced traction in a tire (degraded function = functional nonconformity) can be the result of worn tire treads. In this example, “shallow tread” is a physical change or a degraded quality that is the basis for the functional nonconformity in the tire and “tread depth” is a quality borne by the tire that changes during the course of “wear process”. Both “shallow tread” and “reduced traction” can be regarded as instances of nonconformity class in connection with specific design requirements. Also, it should be noted that nonconformity is a defined class since it is not an inherent characteristic of a quality or function.
Generically dependant continuants
In ROMAIN, the Information Content Entity (ICE) class, a subclass of generically dependent continuant, is used for different purposes as shown in Table 3. Descriptive, designative, and directive ICE are the three sub-types of ICE in ROMAIN that are imported from CCO. Descriptive ICEs are used to describe various entities such as maintenance strategies, actions, work orders, and notifications. Directive ICEs are used to describe plans and procedures, such as maintenance plan, through a set of prepositions. Maintenance Work Order Record is an example of a descriptive ICE that describes a desired Maintenance Action. It is also used to record the actual action taken and captures the costs and resources required and actually used in the execution of the maintenance action. Figure 6 shows the main fields of a Maintenance Work Order Record. While there are many data fields associated with a single maintenance work order record, the ones listed in this figure are the most common fields. For example, most work order records contain data fields that correspond to start date and system status code that are considered to be sub-types of date identifier and code identifier, respectively. Maintenance Notification is a descriptive ICE that describes an observed Nonconformity.
Data fields associated with a maintenance work order record.
Processes and events are the main types of occurrents in ROMAIN as shown in Table 6 and Fig. 7.
ROMAIN occurrent
ROMAIN occurrent
The occurrents related to degradation and failure processes.
Process of degradation. Artifacts can undergo a change in their specifically dependant continuants. The Process Of Degradation is a process in which a desired quality, function, or capability is lost over time or an undesirable quality, function, or capability is gained over time. The output of the Process Of Degradation is a Non-conformity that may or may not be observable. When a Non-conformity inheres in an artifact, then the artifact enters the State Of Degradation. When an item is in State Of Degradation, it doesn’t necessarily mean that the item is failed. However, degradation might lead to failure.
Failure event. In general, an event is treated as a process in BFO. A Failure Event is a process that precedes a State Of Failure. When a Component is in State Of Failure it is unable to perform its intended function. The relation between an event and a state is inspired here by the point of view presented by Galton (2012), in which a state can be initiated or terminated by an event. It should be noted that failure event is not a temporal region to specify the moment that failure happens. Rather, it is a process that occurs at some point in time or during a time interval. A failure event occupies a temporal region, either zero-dimensional or one dimensional. If the failure event is instantaneous, then it occupies a zero-dimensional temporal region and if it takes place during an interval, then it occupies a one-dimensional temporal region.
Triggering event. Triggering Event is a process. For example, it might be that a preset maintenance time interval has been reached, resulting in initiation of a maintenance process as shown in Fig. 8. This figure also demonstrates how a fixed-interval repair strategy, as a directive ICE, can prescribe a triggering event.
Relationships between a maintainable item, maintenance strategy, and maintenance action.
Axioms represents that facts that are always true in the domain. In ROMAIN, different types of class axioms, including equivalent, subclass, and disjoint class axioms, have been used to impart more formality to the ontology. Table 7 shows some examples of class axioms implemented in ROMAIN. The axioms are represented using Manchester Syntax from OWL 2.0 as it is a more compact and readable representation.
Some examples of class axioms in ROMAIN
Some examples of class axioms in ROMAIN
Ontology verification is the ontology evaluation which compares the ontology against the ontology specification document (ontology requirements and competency questions cf. Section 5) thus ensuring that the ontology is built correctly (Suarez-Figueroa and Gómez-Pérez, 2008). In other words, it allows us to answer the question “are we producing the ontology right?”. Ontology validation is the ontology evaluation that compares the meaning of the ontology definitions against the intended model of the world aiming to conceptualize. In other words, it permits to answer the question “Are we producing the right ontology?”. Hence, in order verify and validate a reference ontology as ROMAIN, we estimate that we need to consider a real industrial context and real data set. In the following section, we examine the competency questions listed in Section 5.3 according to the maintenance strategy effectiveness use case by using real-life data.
Use case: Maintenance strategy effectiveness
Our motivating question is to determine how effective the selected maintenance strategy is in practice. Having an effective maintenance strategy will reduce unanticipated events leading to improved uptime, reduced costs and more effective use of maintenance resources. Common manifestations of ineffective strategy are assets failing before their scheduled restoration or discard times and assets being replaced or restored while they are still functional. In addition, the execution of the strategy can be ineffective. For example if assets with on-condition tasks are failing unexpectedly then the on-condition task is obviously not effective at detecting the deterioration. Once ineffective tasks are identified, engineers can investigate and understand why the strategy is ineffective. Currently the process to investigate maintenance strategy effectiveness is triggered by observations by maintenance personnel after an unexpected failure event. The investigation, usually done by an engineer or maintenance planner, requires access to data in a number of locations. For example, specific work order records, preventative maintenance strategy and work history in the CMMS (all stored in different tables), failure investigations in Excel or Word files, RCM analysis (also usually in Excel file). It can take days or even weeks to pull together the right data and perform the analysis. A major issue is that most of the data is stored as unstructured, free text. As a result some pre-processing of the unstructured free text using natural language processing or rule-based methods may be required.
The data for this maintenance strategy evaluation use case comes from the CMMS used by an operator of Heavy Mobile Equipment (HME), one of the most expensive maintainable items is the engine. We have records of all tasks executed on the engines of four identical HME assets in their first 18,000 operating hours. We show an extract of these records in Fig. 9. We aligned the data schema with ROMAIN classes and then we manually instantiated this part of data via the Protégé editor in order to use it in our experiments.
All work order records associated with work on the engine of heavy mobile equipment EQ1 over its operating life to 23,000 hours.
In this table, columns 1, 5, 6, 7 and 8 are as-downloaded from the CMMS. Data in columns 2, 3 and 4 have been added by the engineer to assist with analysis. While the data represented may seem straightforward to analyze, the engine is only one of many maintainable units on this asset, and operators can own, tens to thousands of assets that might benefit from maintenance strategy effectiveness analysis. Therefore, automation of this process is an inevitable necessity.
The competency question ‘how many breakdown orders were executed?’ is straightforward and would be usually done by an engineer generating a pre-configured report for EQ1 engine from the CMMS, add in columns 2-4, and then use PivotTables in Excel to filter the data. This exercise then needs to be repeated for each sub-system of interest each time the analysis needs to be done. Some engineers will use Excel macros to help. In contrast, the SPARQL query for this first competency question is presented in Fig. 10, with its associated result (the SPARQL query language can be used to express queries across diverse data sources). Breakdown orders are triggered by failure events, which are zero-dimensional temporal regions. Therefore, counting the number of breakdown orders comes down to counting the number of failure events, expressed in the request in Fig. 10.
SPARQL query for first competency question.
The competency question ‘did any scheduled repairs or restoration occur before the target interval of
SPARQL query for second competency question.
The ability to write a single SPARQL query which can be run for a list of assets at different functional locations over the existing methods is significantly more efficient and transparent to current engineering practice. As mentioned earlier, the current approach is to have an Excel spreadsheet and pivot table for each query. Version control is difficult to manage and the number of Excel sheets quickly grows to be unmanageable. Not to mention that the process of cutting and pasting, organizing and making pivot tables is laborious and prone to human error.
The SPARQL queries presented in this section have been run on a version of ROMAIN containing the work orders presented in Fig. 9. The results presented in Fig. 11 (WO16, WO5, WO14) refer to the 17th, 6th, and 15th lines of Fig. 9.
In evaluating the ROMAIN ontology we consider the requirements listed in Section 5.2. The ontology is aligned with a top-level ontology, the BFO. Therefore, it can be aligned and extended with classes from BFO compliant mid-level ontologies such CCO and IAO as shown in Fig. 12. This figure also shows how BFO-aligned ontologies for activities in the maintenance management process that use processes such as planning, scheduling and costing, can be tailored to maintenance by reference to ROMAIN concepts.
A mapping of the relationships between BFO-compliant ontologies to enable development of an ontologies for maintenance management activities. [The arrow sense shows the sense of import, e.g. CCO imports BFO, and ROMAIN imports CCO.]
The ROMAIN ontology captures core notions and terminology related to maintenance management as demonstrated by the alignment to authoritative maintenance literature (Coetzee, 2004; Kelly, 2006; IEC, 2011, 2016) as well as maintenance practitioner input. Finally the ontology follows the design principles discussed above.
The main challenge in the development of a BFO-conformant ontology for maintenance has been the absence of tried, tested and accepted BFO-aligned classes and relations for the engineering domain. In 2017, an international group of volunteers started the Industrial Ontology Foundry (IOF) with the objective of developing open and principles-based reference ontologies for the manufacturing domain. While work on this is underway, the group has not yet reached the point of agreeing on some of the classes that are used in the ROMAIN ontology described here. As a result, the ROMAIN authors have made judgments based on views in the IOF community that have not yet stabilized.
One challenge has been the use of the class of maintenance action and whether this is an Information Entity as in a description of the work to be done, or a process in the doing of the work. In ROMAIN we place Maintenance Action in the occurrent section of the ontology but describe the work to be done in a Maintenance Work Order Specification as a directive information entity.
Another challenge has been related to defining a condition or state of a component. In maintenance we have the notion of a component degrading. Maintenance is defined as the “actions intended to retain an item in, or restore it to, a state in which it can perform a required function” (IEC, 2016). Hence maintenance actions are dependent on the state of the component and the effect of this state its ability to perform a required function. In ROMAIN we have defined two states, a State of Failure and a State of Degradation. These are sub-classes of process class. Transition into a State of Degradation is represented by a process described by a Triggering Event. The triggering event class proved to be important in resolving issues around describing this transition. The transition between a State of Failure and a State of Degradation remains challenging as it depends on defining a function and the level for that required function. For example, one person may decide that the tire tread should be 0.4 mm deep but another that 0.8 mm deep is necessary. A tire tread depth of 0.6 mm will be regarded as in a State of Degradation by the first but a State of Failure by the second. We expect dealing with transitions to be an area of fertile discussion in the future. For ROMAIN, the main challenge has been the immature status of the application of the BFO as a top-level ontology in engineering. While we are committed to the importance of exploiting foundation ontologies in our work, there are challenges in BFO concerning some aspects such as the definition of Generically Dependent Continuant, mereology and constitution. All of these challenges have been bought to the attention of the BFO community.
Defining the notion of nonconformity also presented a challenge when developing the ontology. Nonconformity is the violation of both articulated and unarticulated requirements. However, representation of unarticulated requirements is not possible as they are not specified in design specifications and technical documents. Therefore, we had to limit the formalization of the notion of nonconformity to explicit requirements only. Additionally, nonconformity is a multifaceted entity as it can be an undesired quality or function. Therefore, we had to directly classify it under Specifically Dependant Continuant such that it covers different types of nonconformities. Perhaps application ontologies may need to create more specific classes of nonconformity depending on their needs. Finally, in many cases, nonconformity is realized when an item lacks a function but stating ‘A lacks B’ is difficult due to the constraints imposed by a realist approach. There are workarounds for this situation but it needs to be stated outside of OWL since it involves instance-to-class relations (Ceusters et al., 2007).
The subject of causality has always been a challenging subject for ontologists and they have adopted different approaches for handling this subject philosophically and ontologically (Galton, 2012). In the domain of maintenance, proper formulation and elucidation of the notion of causality is essential for effective root-cause analysis. Usually conjunction of multiple states of degradation may cause the maintainable item to enter the state of failure. Defining causality links between various states, processes, and events need further analysis. Also, there are different types of causal relations such as affecting, enabling, and facilitating between various entities that need to be delineated formally when creating a reference ontology for maintenance.
Like others before us, developing a coherent set of axioms has proved challenging. These have to be selected carefully as there are many hidden dependencies in maintenance management. These will be more fully considered in future work.
One of the unique aspects of this project was including a maintenance expert in the development team. As a results, the semantics of the ontology was aligned early on with the established standards and models in the field. One of the pitfalls of most ontology development projects is involving domain experts towards the last stages of design process only for test and validation purposes. We used GitHub as the platform for collaborative ontology development. The issue tracking mechanism of GitHub was particularly useful for suggesting revisions and tracking changes. The ontology is available on github.3
This work presents the first building blocks of ROMAIN, a BFO-compliant reference ontology for maintenance management. We intend to expand this work further while making it open for others to develop a set of ROMAIN compliant modules covering other processes and applications in maintenance. Extension of this initial work will allow the community to move towards an expanded reference ontology for maintenance management. It is intended to help stimulate developments in maintenance-related domain ontologies considering using BFO as a top-level ontology (as explained in Fig. 12). One of the strengths of the adopted methodology for ontology development in this work was relying on real-life maintenance data for testing and evaluating the ontology. We believe conforming to the vocabulary that is widely used by maintenance professionals and practitioners is a major catalyst for widespread acceptance and uptake. As the ontology evolves, some of the less generic classes of the ontology might be moved to the application-specific extensions of the ontology, thus leaving the core classes application-agnostic.
Footnotes
Acknowledgements
Authors would like to thank members of the IOF (Industrial Ontologies Foundry) community for their many useful comments.
Melinda Hodkiewicz thanks the BHP Fellowship for Engineering for Remote Operations and the Australian Research Council through the Industrial Transformation Research Program (Grant No. IC180100030) for their support.