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.

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.

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’.

OPEN IN VIEWER

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

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 artifactm 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 processo in which the item’s states 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

OPEN IN VIEWER

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 community1

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:

Is the information in a MWO record indicating a replace activity (through various terms) consistent with the expectations of such an activity? Specifically, are the activities associated with MWO records described by ‘replace’ terms classified by the replace activity type?

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.

OPEN IN VIEWER

Fig. 3.

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

5.2.1. Work order records and information content OPEN IN VIEWER

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 OPEN IN VIEWER

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.2

²

Note that the OWL implementation provided does not use annotation properties due to errors occurring in the use of the tools. Repeated savings of the file would cause the annotation properties to shift into data or object properties in ways that would break the outcomes of the reasoning. So, the authors defined them as data/object properties to avoid such recurring issues. We assume that different tools would not demonstrate the same issues and the properties could be defined as annotation properties as described here.

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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.

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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.

OPEN IN VIEWER

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.

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.

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.

8. Conclusion

There is significant opportunity to use ontologies as an integral part of the data cleaning process for maintenance work order records. This paper focuses specifically on data quality checks on what maintenance activity was performed based on information contained in the MWO. Understanding these maintenance actions on a specific piece of equipment is analogous to a doctor being able to determine all the procedures and prescriptions a patient has had from historical medical records. In doing so, we cannot afford to rely only on the words used by the data generator to describe the activity. There are too many different people involved over the years in generating these records and they come from a wide range of backgrounds. As a result, to confirm the activity that was actually performed, engineers have to check if these activity words are consistent with data in the other fields of the MWO record. The ontology in this paper performs this check. The results are promising with the reasoning able to identify several data quality issues in the MWOs. The challenges for the ontology in making a final distinction between classes such as replace or repair and adjust or diagnose for corrective work order types are the same as for the engineers. In both cases additional information is required. The elucidations for each of the seven maintenance activity terms also reveal shortcomings, from an ontology perspective, with the descriptions for some of these activity terms in both the ISO 14224 and ISO 15926-4 standards.

The generation of instance data for the reasoning in the application-level ontology is dependent on having a suitable NLP pipeline. Work in NLP for MWOs is an active area of research. While the pipeline used here is state of the art for extracting activity and item information, we expect additional instance data and relational data to be available soon. This will assist with refining the reasoning of the application-level ontology presented in this paper. The combination of both NLP and ontologies for an industrial use case is an additional contribution to the literature for this paper. Further a number of the modular ontologies created for this project are re-usable for other use cases, namely the work order ontology, functional breakdown pump ontology, asset list ontology, and maintenance activity reference ontology.

The ontology community has a tendency to regard processes as failures if they perform in a less than perfect way. In the case of improvements in data quality of MWOs the task is so huge and laborious and the consequences of poor data quality so difficult to quantify and yet significant that any automation and standardisation is a worthwhile improvement. This work is a stepping stone to the use of ontologies for cleaning and processing maintenance work orders in industry. A necessary step in the digitisation journey modern industry players are now on.