An ontology for maintenance activities and its application to data quality

2.1.Maintenance

Maintenance is defined by an International Standard as “the actions intended to retain an item in, or restore it to, a state in which it can perform a required function” [20]. We note from this that the notion of an action or activity is central to the concept of maintenance.

In mature maintenance organisations, each maintainable item has an associated maintenance strategy. The maintenance strategy determines what work should be done, when to do it and at what level in the asset hierarchy it should be performed. Deciding on maintenance strategy is a well established process based on failure modes and effects analysis and reliability centred maintenance (RCM). These are described in international standards such as [21,52]. The ‘what strategy?’ decision is informed by factors such as the safety, environmental, production or cost consequences of an item’s failure, whether loss of function is technically and cost effective to observe, and how long it takes from observation of deterioration to failure event. RCM decision-logic guides the user towards one of the following strategies: a) use based, also known as fixed interval restoration/repair/inspect strategy, b) strategy based on condition monitoring and inspections, c) failure-finding and d) run-to-failure [17]. Colloquially, these are classified into preventative and corrective maintenance strategies, with preventative including fixed interval work and periodic inspections such as condition monitoring and corrective covering failure finding, run-to-failure, and work arising from preventative tasks. The notions of preventative and corrective strategies are relevant to the reasoning used in this paper.

2.2.Review of previous ontology work on maintenance activity terms

There is increasing interest in automating tedious data processing tasks that require the input of experienced people and in being able to automatically process equipment maintenance and failure data using ontologies for decision support to standardise the decisions made when analysing the data [15,33,42,46]. Interest is high in industries such as defence, aerospace, oil and gas, and manufacturing and this is compelling groups to come together to consider standardisation as they recognise the scale of the task and the challenge of going it alone. In 2021 the ISO/IEC 21838-1 for Top Level Ontologies [26] was issued alongside ISO/IEC 21838-2 Standard [27] describing Basic Formal Ontology (BFO). Standardisation of a further two top level ontologies, Descriptive ontology for linguistic and cognitive engineering (DOLCE) and TUpper is in progress. This standardisation process is a key plank in industry acceptance of ontologies. There is a surge of activity to develop industry-relevant, domain specific ontologies, that are aligned to one of these Top Level Ontologies. Of relevance to this paper is the work of the Industrial Ontology Foundry (IOF) and their work to publish a domain ontology for manufacturing aligned to BFO. The IOF promotes a principles-based approach to the design of ontologies for design, maintenance, supply chain, production, and lifecycle management of equipment. A number of the terms and relations necessary to support description of maintenance activities are already formalised in the IOF [59].

While there have been a number of papers published on maintenance ontologies these have, in the main, been developed using a top down approach. Some have tried to capture maintenance in general [30,35] while others have focused more specifically on various processes in maintenance such as maintenance work management [19], failure modes and effects analysis [16], fault classification from warranty records [48], modelling maintenance strategies [38], and in criticality assessment [44]. Dealing with real-life maintenance data has not been the primary motivation for ontology development. Instead, conceptual models have dominated with limited use cases selected to support and illustrate specific reasoning and conceptualisation challenges. There have been some exceptions. For example, in the automotive industry, Rajpathak and General Motors have used natural language processing and ontologies to extract data from hundred of thousands of unstructured warranty records [46,48,49] and there is similar interest in the analysis of safety data from accident databases [57]. In the oil and gas industry, there is emerging work on using ontology patterns to ingest instance data from MWOs and failure modes and effects analysis records into ontologies for use in reasoning about the effectiveness of maintenance strategy for a complex operating asset [32].

When looking for previous ontology work specifically on maintenance activity classes we located a list of 16 drawn from a data set of 654 activities/tasks for a wire harness assembly case study [41]. However, these activities are defined using natural language phrases such as ‘laying cable flat’ and ‘inserting into the tube or sleeve’ and can be used only in their specific case study. The activity classes identified are not generic to maintenance in general.

2.3.Maintenance work order records

A MWO record is generated every time work is done, or needs to be done, on an asset. MWO records are the only digital record of maintenance events for the life history of an asset. Hundreds of thousands of these MWOs are generated every year in asset intensive organisations. In a MWO record the primary interest to the reliability engineers are the fields described in Table 1. The functional location is the asset identifier, the work order description contains the unstructured text of interest in our work, the work order type identifies if the work is preventative or corrective, and there are fields for the start and end dates and various budget and actual costs. Other fields, not shown, include metadata for the record. The information contained in MWOs is the only record of what maintenance work is done when, to what item, and how much it cost.

2.4.Natural language processing of maintenance work orders

The reader will note from Table 1 that there is no dedicated fields for key information such as “what specific item needs work?”, “what work needs to be done?”, “why does it need to be done?”. The answers to these questions have to be inferred from a 4–8 word sentence captured in the ‘Work description’ field. A typical example, drawn from [13] is ‘change out leaking engine’. This phrase is illustrative of MWOs in general in that it contains an activity word ‘change out’, a state or problem word ‘leaking’ and an item identifier ‘engine’. Work to develop pipelines to separate the words in these MWOs into classes using natural language processing is very active [7,13,42,46,55,62]. Once extracted, the information in these activity, item, and state fields is being used for visualisation and analysis to support a number of maintenance and reliability decisions [3,48,53,54]. However, one challenge for all users is the large number of terms in all these classes resulting from synonyms, misspellings, different tenses, abbreviations, and jargon.

Work on defining classes for types of maintenance activity in ontology is limited. There is a list of 10 maintenance action codes (inspection, servicing, adjustment, alignment, resetting, replenishing, coating, repair, replace, overhaul) produced by [28] but the selections on the list are not justified nor the terms fully described. A Bag-Of-Words approach on a corpus of 690,000 MWOs identified 103 maintenance terms but acknowledged that many terms such as service that can be a noun or a verb were missed [13]. There was no attempt to group these terms into manageable groups. The raw data arising from these works are not freely available and the resulting lists of classes are not clearly defined. So instead we turn to lists available in the engineering standards literature.

2.5.Lists of maintenance activity terms from international standards

In this work we draw on two international standards, ISO 14224 (2016) and ISO 15926-4, for their maintenance activity terms and definitions. The terms, definitions, and their alignment between the two standards is shown in Table 2. The following sections briefly introduce the two standards.

2.6.Distinguishing between maintenance activity terms

The descriptions for maintenance activities drawn from ISO 14224 and ISO 15926-4 are outlined in Table 2. In these descriptions we can see there are two motivations for a maintenance activity. The first is to ‘change (or restore) the state’ of the item. The second is a ‘discovery’ process to determine if work is required. Under the ‘change of state’ notion, either: a) the state of the item is known to be deteriorated and needs restoration, e.g., for repair, adjust, and corrective replacement; or b) work is required as a result of pre-determined strategy at a predetermined interval regardless of the state of the item, e.g., preventative replacement, fixed interval calibration, test and service. Under the ‘discovery’ notion, the state of the item is unknown, but a problem is suspected. The state of the item needs to be determined, e.g., by a diagnostic activity such as a test or inspection.

However, we note that these two standards do not agree on several of the term definitions or the same set of terms. For example, the terms calibrate, maintain, troubleshoot and renew appear in ISO 15926-4 but not in ISO 14224. Conversely, the terms refit, service appear in ISO 14224 but not ISO 15926-4. The term overhaul in ISO 14224 is superficially defined as an ‘overhaul’ and in ISO 15926-4 as ‘repairing or restore to satisfactory working order’ which is only distinguished from repair – defined in ISO 15926-4 as ‘bringing an item back in its original state or in a revised design state’ – by someone being able to separate between an item in ‘satisfactory working order’ or ‘original or revised design state’. What is meant by a ‘revised design state’ is not clear. The definition for refit is only in ISO 14224, and described as ‘bringing back acceptable appearance’ rather than a function, which adds another level of ambiguity by the introduction of the word ‘appearance’.

Fig. 1.

Classification workflow capturing logic to distinguish between maintenance activity terms.

To move forward in the presence of this partial agreement on terms and their definitions in the ISO 14224 and 15926-4 Standards, we have captured general concepts in Table 2 in a the classification workflow shown in Fig. 1. In this workflow, diamonds contain questions for the users to answer and depending on the yes/no answer, an inference about the nature of the activity is shown in a parallelogram. In developing this we focus on information of potential value to reasoning as follows:

4.1.Developing notions for maintenance activity terms

4.2.Discussion on elucidations for the core activity terms

In this section, we discuss the elucidations given in Table 7 and the ontological choices underpinning these elucidations. These elucidations draw on our previous work on Maintenance State to help distinguish between activity types [68]. This work on maintenance state describes terms that are used in these elucidations such as operating state.

First, we describe the elucidation for the replace activity. This elucidation describes a situation where there are two material artifacts (a and b) that have functions of the same type, F. When the replace activity occurs, a is a continuant part of a system before the replacement, and b is a continuant part of the system after the replacement. This is true whether a whole piece of equipment is replaced (i.e. a pump) or only part of a system is replaced (i.e. a pressure switch). A critical part of this description is that both the item to be replaced (a) and the item to be installed (b) both fulfil the same function when installed as part of a system. In other emerging developments such as ISO CD/TR 15926 Part 14 [25], there is the concept of a functional object and the relation functionalPartOf to support this, while the work of [29] applies functions in DOLCE [5] with a role-based approach incorporating elements of social roles [34], conventional-system components [14], and the role-concept, role-player, role-holder triad of [36]. In BFO, there is no such concept as ‘functional object’ and the BFO concept of ‘role’ differs such that it is difficult to distinguish where the replaced asset sits in a functional breakdown (as opposed to a physical breakdown). For our purposes, we believe it is sufficient to say that the function of the asset is of the same type for both a and b, without being specific as to the level of granularity of that type within the functional breakdown (i.e., ‘pumping’ vs. ‘pumping at P101’). Finally, we acknowledge that the idea of replacement is a deeply philosophical problem and raises many questions about identity [11]. However, for the replacement of a limited number of components such as that performed during a replace maintenance activity, this elucidation assumes that the identity of the whole (i.e., the system s) remains unchanged.

The semi-formal description for a repair activity describes a process that improves the “ability of an item to perform its required function”. For this, and for the maintenance terms that follow, we draw on our previous work on the notion of maintenance state [68]. In this work, we model the states in which items do not have the ability to perform functions (i.e., participate in a process that realizes a specific function). We achieve this through a disables object property where some state disables a function realising process. Furthermore, we determine that in maintenance, when an item is installed, but does not have the ability to perform its required function, it is in a degraded state or a failed state. Otherwise, the item is in an operating state and can perform all of its functions. Given this work, we describe a repair activity as a situation where there is a material artifact m that participates in this activity and has some function f. Before the repair activity, m is in some degraded state or failed state s (i.e. a state that disables f). After the repair activity, m is in an operating state. Using our modelling of state, we have been able to model changes of state and their implications a result of a replace activity.

An inspect activity is described as a process to estimate the ability of an item to perform its required function. Since an item’s state determines its ability to perform its required function, as described previously, this elucidation describes an observation process o in which the item’s state s is examined. Note that from a maintenance perspective, an item’s ability to perform its required function is not something that is measured (or estimated) on a continuous scale. Instead, the item is either able to perform its function or it is not. Therefore, we believe an observation of the item’s state (failed, degraded or operating) is sufficient to model an inspect activity.

An inspect activity differs from a diagnose activity in one crucial aspect. In the SME natural language description, an inspect activity is defined as “periodic”. This means, that a preventative maintenance strategy is defined that determines at what intervals an item should be inspected. Note that we consider each instantiation of a preventative maintenance activity to be prescribed by the maintenance strategy once it occurs due to its predefined nature. A full definition of maintenance strategy and how it relates to activity types and their individuals is reserved for future work. A diagnosis, in contrast to an inspect, is a corrective action to determine “the cause” of a failure (and is not scheduled). Note that even though an action is corrective, it may still be described in a maintenance strategy in the case of a Run-to-Failure corrective maintenance strategy. This distinction between corrective and preventative activities is crucial to our application-level ontology described in Section 5 as, for example, inspect and diagnose are otherwise difficult to distinguish. A key differentiating aspect between inspect and diagnose is when the observation process occurs relative to when the fault is known, which is not something that is generally captured by the data nor an ontology.

An adjust activity is a process that involves changing the state of an item but with no change to the ability of the item to perform its function. This means that adjust activities are performed when an item enters a ‘sub-optimal’ state, i.e., a state where some aspect has gone out of tolerance but not to a degree that it leads to failure or degradation. The elucidation for an adjust activity looks very similar to a repair activity as they are both corrective actions involving a change of state. The difference is that a repair activity requires the item to be in a failed state i.e., unable to perform a required function). An adjust activity is performed on items that are still functional but have been observed as being “out of tolerance”, as per the SME natural language description in Table 7. The resulting work is corrective. Therefore, we introduce two sub-classes of operating state (extending our work in [68]). We model s1 as a sub-optimal operating state (i.e. where equipment is out of tolerance) and s2 as an optimal operating state. As with an inspect activity and a diagnose activity, the difference between an adjust activity and a service activity is that an adjustment is a corrective action, and a service occurs at periodic intervals and is aligned with a preventative maintenance strategy.

The final maintenance activity type is a calibration activity. This is defined as a task involving testing and adjustment of instrumentation to assess and restore its function. In our elucidation, we define a calibration activity similarly to a repair activity, but the item can be in a functioning, degraded or failed state before the activity. What distinguishes a calibration from other activity types is that it is performed on instrumentation. Therefore, in the elucidation, we say that the material artifact m plays a control and monitoring role r. This relationship is important for our use case in Section 5, as we distinguish calibrate activities by their membership in a Control and Motoring subunit of the centrifugal pump. Finally, a calibrate activity is preventative as prescribed by some part of a preventative maintenance strategy (as with service and inspect activities).

4.3.Reference ontology implementation

Fig. 2.

A conceptual diagram of the maintenance activity reference ontology with example links to synonyms (synonyms are listed in Table 6).

The reference ontology is implemented in OWL and is available at https://github.com/uwasystemhealth/Paper_Archive_Maintenance_Activity in the file maintenance-activity.owl. A conceptual diagram of this reference ontology is shown in Fig. 2 (where “C” is a class and “@” is an annotation property). In the ontology, there are two classes, Maintenance Activity and Supporting Activity. These activities are a subclass of BFO:Process. The core maintenance activities and supporting activities that were identified in Section 4.1.1 are classes in the ontology and have their SME natural language description, semi-formal description and elucidation stored as annotation properties. The other terms that formed part of each grouping (i.e. align and amend as members of the adjust group) are stored in an annotation property, synonym. “Synonym” is defined in the IOF as “an alternative label (designation) used for the resource in some community” [22]. While it could be argued that the words listed as synonyms are not “true” synonyms with one another in an English language sense, the maintenance community11 interprets these words in the same way. Therefore, for our maintenance activity reference ontology, this is an appropriate annotation property to use.

5.1.Competency questions

The application-level ontology is designed to perform a specific reasoning task to meet a real industrial need. The work order data described in our use case (Section 3), contains seven distinct activity words. These are adjust, calibrate, diagnose, inspect, repair, replace, and service. For data quality purposes, we want to determine if the activity term classified by the ontology is consistent with activity term classified manually by a subject matter expert based on information in the MWO. The competency questions that we use to assess this ontology are:

5.2.Application-level ontology implementation

This ontology was developed making use of the reference ontology described in Section 4. The ontology consists of eight modules, as shown in Fig. 3. A description of each of these modules is contained in Table 8. This ontology can also be found on GitHub at https://github.com/uwasystemhealth/Paper_Archive_Maintenance_Activity. In the following sections, we will discuss the key ontological choices made in the development of this ontology.

We have developed a set of modular, inter-operable ontologies aligned to a top-level ontology (BFO) guided by the processes described in [65]. The diagram in Fig. 3 should be read from top to bottom, first BFO is loaded in Protege, then the IOF Annotation Vocabulary followed by the IOF Core Ontology. The five remaining ontologies are needed for the work in this paper but are reusable in other ontological work. For example, an Asset List, a Pump Functional breakdown description, a list of Maintenance terms and the structure of a maintenance work order are represent generic information that is re-usable. They are currently minimalist ontologies that meet the needs of the use case as the focus of the paper is not the asset classes nor breakdown structures. The only ontology specific to the addressing of the use case questions in this paper is the Maintenance Activity Classification Rules. Should users want to apply this data quality ontology to another asset class, they potentially only need to extend or replace the Asset List, Pump Functional breakdown, and Maintenance Activity Classification Rules ontologies.

Fig. 3.

Import structure of application-level ontology for assessing MWO data quality.

5.2.1.Work order records and information content

Fig. 4.

A conceptual diagram of information content entities for work order records in the application-level ontology.

At the core of this application-level ontology is an Information Content Entity, the MWO Record. In this section, we will explain our choices in modelling a MWO Record and its information parts (i.e. Material Cost, Labor Cost). A conceptual diagram of the information content entities in the application-level ontology can be found in Fig. 4 (where “C” denotes a Class, “I” denotes an Individual and “P” denotes a property). Note that we are choosing not to use the Information Artefact Ontology as a reference ontology, as it does not contribute to the ontology for this use case; however, the classes utilised in our ontology are compatible with it.

As shown in Table 5, a MWO Record has multiple fields (or MWO Data Items that contain information relevant to the MWO. To capture the information contained in these fields, we have added a new object property called refers to that is a sub-property of is about. If an Information Content Entity refers to an entity, then it uses, evokes, or references the entity or concept in some way that is not necessarily descriptive, designative, nor prescriptive.

In this ontology, refers to is used in several cases including:

• – Where a Descriptive Information Content Entity, e.g., a MWO Record or MWO Data Item, references an asset in a functional location; the functional location tag field of the record cannot be a designative entity in this case as the designation of the functional location (and/or the asset installed in the location) comes from elsewhere, the field merely contains a value that matches the designation of the location/asset and, hence, refers to it. This could be a Referential Information Content Entity; however, we do not yet introduce such a class. Moreover, the field cannot be said to describe the functional location/asset as it is describing an aspect of the work order process/activity, by identifying a primary participant in the process/activity.

• – Where a Descriptive Information Content Entity such as a MWO Data Item, is deduced to be referencing an entity or concept, e.g., the work order record description field having been identified (through the NLP pre-processing) as referring to a specific activity type, which is reconciled from the textual form used in the description and the terms associated with the different activity classes.

Finally, we are choosing not to link the MWO Record (as a generically dependent continuant) entities to their concretizations in the originating database. Instead, we provide only an abstraction/normalisation over the records stored in an actual database. We take for granted, at the moment, that there is an originating database and, hence, some specifically dependent continuant (i.e., the physical datum) and the common independent continuant to which both the datum and the MWO record relate.

5.2.2.Activity terms identified with NLP

Fig. 5.

A conceptual diagram of NLP identified properties for work order descriptions in the application-level ontology.

As discussed, the goal of this application-level ontology is to check if the activity described in the MWO’s unstructured text field matches the information in the rest of the ontology. To achieve this, we store the NLP Identified Activity from Table 5 as an annotation property on the Maintenance Work Order Description. A conceptual diagram of this pattern in shown in Fig. 5 (where “L” represents a ‘Literal’ property value). We represent this information in annotation properties because they represent assumed knowledge resulting from an entity recognition algorithm applied to the specific field. Thus we cannot assert this knowledge as individuals in the ontology without a detailed ontological analysis, which is not necessary for our use case.22 We use the information stored in this annotation property to infer the NLP identified activity type in the maintenance activity reference ontology described in Section 4. We achieve this inference using punning of the property and activity types, and a SWRL rule that compares the normalised text value of the annotation property against the synonyms of the activity classes. We reconcile term and activity type within the ontology noting that the synonym terms in each group and associated label may be updated in the ontology based on an organisation’s profiling of their own data. The SWRL rule is illustrated in Fig. 6.

Fig. 6.

SWRL rule reconciling NLP extracted activity term with the ontology. Elements representing variables have names beginning with a question mark (‘?’).

Using the inferred maintenance activity, we can then compare the NLP identified activity to the result of the workflow in Fig. 1. The rules for which are discussed in Section 5.3. If there is no NLP Identified Activity, the MWO record is considered to refer to an Unspecified Activity. We acknowledge that MWO records with an Unspecified Activity lead to records being considered ‘non-matching’ in the comparison; however, beneficial analysis can still result by flagging such records for review by an engineer. In the following section, we will describe how the NLP Identified Item and the NLP Identified subunit are used to gain further information about the true activity performed in the work order.

5.2.3.Items and subunits

To realise the logic contained in the workflow in Fig. 1, we need to know the type of equipment being worked on (or, more specifically, which subunit from Table 4 the item fits into). In the MWO structured data, there is a functional location field (a Functional Location Tag in our ontology). For all of the work orders in this use case, the Functional Location Tag refers to a Pump System (a centrifugal pump and other equipment e.g, motor, values, instrumentation necessary to perform the pumping function). The Pump System and other item classes are defined as IOF Core Material Artifacts, which is a BFO Object class. In our ontology, a Pump System has its (functional) subunits (e.g. the Control and Monitoring System) as continuant parts at all times. The subunits, modelled as Engineered System classes under the BFO obect aggregate hierarchy, have continuant parts at some time, e.g., the Control and Monitoring System having further continuant parts such as a Pressure Switch and other types of instrumentation. This is a minimal representation of the asset’s functional breakdown structure, which we do not address further as it is not the focus of this paper and is a complex topic to address in BFO. A conceptual view of items and subunits in the application-level ontology is shown in Fig. 7. For reasoning purposes, the item and subunit classes are punned to individuals and matching values for the object property kindOf are inferred by the classification. The equipment items are parts, the classes for which are contained in the Asset List Ontology module while the equipment’s classes membership in a subunit is captured in the Functional Breakdown Ontology (as described in Table 8) – the punning and kindOf property are separated into the Maintenance Activity Classification Rules module.

Fig. 7.

A conceptual diagram of items and subunits in the application-level ontology.

The only structured information in the MWO record that indicates the item being acted upon is the Functional Location Tag. Since this is not at the right level of granularity to perform our analysis, we rely on our entity recognition algorithm, and some subsequent analysis, to identify the specific item and subunit. For the purpose of this analysis, we use a simple mapping from the item type to subunit type. The breakdown structure of centrifugal pumps identified in Table 4 has a unique subunit type for each maintainable item type. Using the NLP Identified Item (model shown in Fig. 5), we can utilise the subunit information in the rules to identify possible participants of the activity, i.e., the item individuals at the part level, and further use this to infer a classification for the maintenance activity that was performed on the item.

5.3.Maintenance work order execution processes and activities

Thus far, we have shown how we model the structured information from the work orders as Information Content Entities. Subsequently, we have shown how we infer the expected maintenance activity that was performed on the item (from the NLP Identified Activity). Finally, we have shown how we use extra data from our unstructured text by storing the item being acted on and the item’s subunit. In this section, we show how we use this information to realise the logic shown in Fig. 13 and infer the type of maintenance activity that was likely to have been performed. If the type of maintenance activity identified through analysis of the description does not match the inferred maintenance activity classification, we assume that the MWO data is not of a high quality and requires further human attention.

The conceptual diagram in Fig. 8 shows how we model the inference of the activity type and its relation to a MWO record. In the figure, our Maintenance Work Order Record (MWO-2) describes some Maintenance Work Order Execution Process, following the structure of the ROMAIN ontology [30]. This execution process represents all the activities that are carried out to execute a MWO (and is contained in the Maintenance Work Order Ontology from Table 8). This execution process has the Maintenance Activity to be classified as an occurrent part. In the case of an activity that was not actioned, the classification is applied to the execution process and not the activity. This is because the activity cannot really exist if the activity to be classified was not actioned, but other parts of the process may have been. This way the individual for the unactioned activity could be removed if desired.

Fig. 8.

A conceptual diagram of maintenance work order execution processes and activities in the application-level ontology.

The actual maintenance activity classification is inferred using SWRL rules that capture the logic of the workflow shown in Fig. 13. To support this inference, there are several supporting elements, including additional classifiers and rules, that surface information used by other rules or for subsequent querying. The primary rules and supporting elements are captured in the Maintenance Activity Classification Rules module, described in Table 8.

5.3.4.SWRL rules

In total there are 13 rules for classifying activities according to the leaf nodes of the workflow (Fig. 13), 4 additional rules inferring intermediate classifications, and 2 rules for final comparison of classification to the NLP Identified Activity type. Figure 9 illustrates a simple rule for identifying the corrective maintenance branch of the workflow.

Fig. 9.

Rule for inferring the Corrective Action classification based on the information in the MWO record.

Intermediate classifications cannot be fully relied upon due to some of the activity classes falling under both corrective and preventative maintenance categories. This application ontology does not address the ontological concern of the activity individual being a corrective or preventative occurrence, it merely uses the classifications as indicators. Therefore, the actual maintenance type of the associated MWO record is relied upon to ensure that the final classifications are on the correct path of the tree where activity classes that may be of either category are involved. Capturing it in a rule also makes it easier to reuse the pattern in other, more complex, rules. Figure 10 illustrates a subsequent terminal rule that identifies the activity as repair or replace, alongside a marker classification indicating that it is uncertain as it cannot fully distinguish between the repair and replace activity types.

Fig. 10.

Rule inferring the Repair or Replace classification, including the marker classification Uncertain Activity, based on the information in the MWO record.

The rule for the final cross-check for matching the activity classification is shown in Fig. 11.

Fig. 11.

Rule inferring the match between a concrete activity classification and the NLP Identified Activity type.

Querying the classifications with SPARQL Using the inferred information, the inferred activity classifications can be queried including, but not limited to, all inferred activity classifications, activity classifications matching the NLP Identified Activity information, uncertain activity classifications, and non-matching activity classifications. Of particular interest are the non-matching, including uncertain, activity classifications. Due to the constraints of OWL DL and SWRL, retrieving the non-matching activity classifications leverages the Inferred Type Matches Work Order Description class and SPARQL negation to match the non-existence of the pattern in which it occurs. An example query is shown in Fig. 12.

Fig. 12.

SPARQL Query for retrieving the activities that did not match the NLP Identified Activity type.

The query identifies all the activity individuals that have an inferred activity classification, a Maintenance Activity class, that does not match that class indicated by the NLP Identified Activity. As output, it includes the classifications of the activity individual as well as the activity class associated with the MWO record (via the NLP Identified Activity property). The latter part of the query is optional so as to include results where the activity class associated with the MWO record is missing, in case there is an error in the process. Such a query allows an engineer to review the non-matching, including uncertain, classifications against what was written in the MWO record; they can then take action to rectify errors to improve the data quality.

6.1.Classification results for each maintenance work order

Table 9 is used to identify data quality issues in each record. The table shows for each record a) the activity term in the original MWO unstructured text, b) the classification by a subject matter expert (SME), and c) the activity classification inferred by the ontology and rules. The 5th column shows the agreement between the SME and the ontology as Yes (Y), No (N) and Partial (P). The Partial is used to capture the situation when the ontology identifies two possible activities, one of which was identified by the SME, for example repair or replace and adjust or diagnose. The 6th column captures whether a data quality issue has been identified by comparing the SME classification to the activity term in the original text.

6.2.Confusion matrix results

A summary of the data quality issues identified by the ontology is shown in a Confusion Matrix in Table 10. For the 36 records in this pump MWO data set from 2012–2020, 20 records (55%) were identified by both the ontology and the expert as having data quality (DQ) issues. There were 14 records with no DQ issues and 2 records in which the ontology and the expert disagree. An analysis of the identification of maintenance activity class by the ontology compared to the class described in the original (NLP-processed) record is shown in Table 11.

6.3.How did the ontology perform for on the competency questions?

All original records with terms repair, replace or remove were identified as repair or replace by the ontology and expert. One record (17) uses the verb install in the original record, this leads the expert to classify this as a replace activity whereas the ontology classifies this an ‘adjust or diagnose’. The reasoning from the expert is that the work order could be describing a situation in which the old unit was removed (based on an earlier work order) and this work order is to install a new one as part of a replacement activity. There is no material cost associated with this. This could be because the material cost was charged on the original work order associated with the removal task. This could be resolved with access to more information not available here. The ontology flags this as a data quality issue but the expert does not.

This is discussed in Section 7.1.

There is high agreement between the expert and ontology with the original text on the activity service with the exception of one record (19) when no work was actioned.

This is discussed in Section 7.1.

7.1.What worked well?

Identifying texts with no data quality issues: There are 16 texts that the expert identifies as having no data quality issues. In 14 of these cases (88%) the ontology agrees.

Assigning an activity when no activity is identified in the original text: One of the main issues in the original text is the absence of a verb describing the desired activity. This occurs in 12 records (33%) in this corpus. This is a common issue in maintenance work orders given there are two reasons for work order generation. As mentioned earlier the first reason is an instruction to perform work to ‘change (or restore) of state’ for the item and the second reason is a discovery process to determine if work is required. It is the latter that often lacks a verb as shown, for example, in record 1 “pressure switch undersize”. There is considerable value in being able to infer what maintenance activity is likely to have been actioned to correct this situation. In this the ontology performs well with 100% agreement with the expert.

Reclassification of calibration: The action of calibration involves the “testing and adjustment of instrumentation to assess and restore function” as per Table 7. Calibration is an action prescribed as part of a preventative maintenance strategy. However, on 4 occasions in this data set the work order required corrective work on instrumentation to adjust and restore function. The technician use the word “calibrate” in the original text but the expert and ontology recognise that this is incorrect as the work done is corrective. There is business value in being able to identify these situations using AI, as they indicate, in this case that there should be a preventative maintenance task scheduled for calibration but since there is not, the necessary action is being done in a reactive rather than proactive fashion.

7.2.What could be improved?

Distinguishing between repair and replace for corrective actions: For many of the work order classifications, there is insufficient evidence to distinguish between two of the activities (i.e. Repair or Replace and Adjust or diagnose) without more asset and site specific information. It would be possible to include additional reasoning between repair and replace based on the material cost. If the material cost is equal to the cost of a new unit then the activity would be replace, if not, then it would be a repair. Other options would involve considering the parts assigned to the maintenance work order to see if these parts included, say, a pressure switch (as a replaced component) or not. This would require adding new classes capturing the parts used and resources consumed in the activity. If the parts included a pressure switch, for example, then we could reason that a replace activity had occurred. If not, then the activity would be considered a repair. The parts list associated for each MWO number is captured in a separate table in the database. While these improvements could potentially produce a more generalised approach, this data was not available for the construction of our application-level ontology.

Disambiguation of equipment subunits for complex equipment examples (i.e. complex pumps): In this paper we have worked with a use case on a centrifugal pump. In the process industries there are a number of equipment classes that have well defined taxonomies of functional subunits and maintainable items. For example, heat exchangers, compressors, pumps, and turbines. CMMS systems in different organisations are set up to use these hierarchies when they have to share data for reference data sets [23]. While the equipment subdivision in Table 4 is fit-for-purpose for standard centrifugal pumps, some specialist pumps might also include a separate pressurized lube oil pump system. Records of maintenance work on these can be difficult for an engineer to disambiguate as there are two pumps in the system and a number of seals, some on the main pump and others on the lube pump. Our focus in this work is on the data quality of the standardised equipment classes which make up the majority of assets in process plants and not on the specialised (and often may be expensive one-of-a-kind) assets. For the latter we recommend that specialist engineers continue to manually review the MWOs. Future work may also investigate means of flagging the ambiguity for review by engineers, potentially with a suggestion of the most likely candidate.

Disambiguation of Semantic Synonyms for Activities: In this work we have mapped each of the semantic synonyms to one activity class, as shown in Table 6. While this allows us to move forward with supporting data quality work right now we recognise there could be additional information incorporated into this mapping activity and this will be the subject of future collaborative work in both the NLP and ontology communities. For example, we have mapped install to the replace activity group. We do not know if it is a like-for-like replacement from the information we have in this case study. We have accounted for future work in this area in the elucidation for the term replace shown in Table 7. This would allow reasoning to be developed for information about the parts that were replaced and the parts installed, when this information is available.

Handling of temporal aspects of activities: For the current use case we have elided complex reasoning on the temporal nature of the activities. The approach is successful in applying limited information from MWO records to classify the activities; however, it leaves elements, such as the actual participants of the activities, as representative (or possible) participants, as opposed to actually linking the activities to the parts and items involved in the activities. Furthermore, the start and end date/times are not currently attached to the activity individuals, only the MWO records. As additional information is made available and integrated, further reasoning could be performed to tie the two together. This is another avenue of future work.

Technical Limitations and Assumptions: the evaluation of the ontology was performed using commonly adopted Semantic Web tools for research and development. These tools exhibit a less than desirable execution time for reasoning over the ontology – approximately one minute per MWO record. We assume that this is due to technical limitations in their implementations and that production grade Semantic Web databases and tooling would perform much better. If not, other alternatives could be implemented following the same conceptual pattern as illustrated in this paper: e.g., using SPARQL CONSTRUCT queries to realise inferred relations, or translate into a logic programming language for rule execution and reasoning if necessary.

7.3.What insights did we get into maintenance activity classification

One insight gained in this work is the value of determining if maintenance activities are corrective or preventative. This information is contained in the work order type field in Table 5. When writing elucidations for the terms in our reference ontology, we found that SME natural language descriptions for some activities (derived from descriptions given in international standards), diverge only through the word “periodic”. For example, a service activity is a periodic adjust activity. This means that service activities are aligned to a preventative maintenance strategy, and adjust activities are not. This insight informed a key part of the reasoning in the application-level ontology. This insight is consistent with the need for reliability engineers to know if preventative work is being done or not as a check of compliance with maintenance strategy.

Another insight is the importance of an item’s state in distinguishing between activity types. To realise this, we link our elucidations to our previous work on Maintenance State [68]. For example, we determined that before a replace activity, an item is in a Degraded State or a Failed State, meaning that the item’s “ability to perform its required function” (as per the semi-formal description) is impaired. After the replace activity, the item is in a Operating State as its required function has been “restored”. However, the state of an item is not changed throughout an adjust activity. We have used this to distinguish between a repair and adjust activity from an ontological perspective. However, in practice, there is a grey zone between what some would call an adjustment and others a repair. This is worth considering in future work.

In our use case and this application-level ontology, we do not have an item’s state information available to us (as condition and performance data is captured in a different data base, not generally in a MWO record). However with the increased emphasis on condition monitoring on assets and process instrumentation of systems this information could be available but would need data from data bases beyond the CMMS. Future work should look at how to use this process and condition data to assist with the decisions being made in this application-level ontology. Digital twins will have to be able to incorporate changes in state resulting from maintenance activities in their models.

7.4.Choice of upper ontology

In Section 4.2 we discussed the limitation we encountered with using BFO for the notion of functional object and its associated hierarchies. The concept of an asset having both a functional and a physical hierarchy is central to engineering design and systems engineering [4]. In early design, operation and reliability engineers pay significant attention to the functional perspective, identifying what desired and secondary functions are required and how these functions are fulfilled. Functional units, in engineering, are usually associated with desired levels of performance. As the design life cycle proceeds towards manufacturing then physical and structural consideration get increasing attention. Design for maintenance also considers the physical structure of the system, subunits and maintainable items. For ontologies to be applied to industry data, the models and reasoning must be able to accommodate both functional and physical perspectives. The development of an ontological understanding of functional hierarchy is still an ongoing research line with relevant work available from [4,5].

The authors of this paper are part of IOF Maintenance working group and this relationship was the primary reason for selecting BFO as the upper ontology. Our interest is in understanding performance of this upper ontology on a range of use cases requiring reference and application ontologies and the use of real industry data, and using these experiences to encourage further development of BFO. We are also interested in how other ontologies perform and are active also in using the emerging ISO/CD TR 15926-14 ontology for maintenance data [16].