1. Introduction

Proceedings of the Workshops of I-ESA

Ontology for Maintenance Work Management

Melinda Hodkiewicz

Emily Low

Caitlin Woods

caitlin.woods@uwa.edu.au 0

Farhad Ameri

ameri@txstate.edu 1 0 The University of Western Australia , 35 Stirling Hwy, Crawley, 6009 , Australia 1 University of Texas , Austin , USA

2020

Maintenance work management is a transactional process relying heavily on an army of planners, schedulers and engineers to identify, prioritise, plan, schedule and analyse work. Much of the work is repetitive but each work order and asset needs individual attention as knowledge about the asset, its operation and maintenance performance is stored as semi-structured or unstructured text in a variety of relational database systems and Excel spreadsheets. There are no standards for the naming of fields in these systems, making data extraction a manual effort. The ability of ontologies to semantically align these fields and to use reasoning to check that the content of fields is appropriate could transform the maintenance work management effort by reducing human effort and errors. This paper describes the ongoing work of the Maintenance Working Group of the Industrial Ontology Foundry (IOF) to develop a set of core notions specific to maintenance work management and aligned to the top-level ontology Basic Formal Ontology (BFO) and the new IOF ontology. maintenance work management, reference ontology, Industrial Ontologies Foundry 0000-0002-7336-3932 (M. Hodkiewicz); 0000-0003-1576-7442 (E. Low); 0000-0001-7829-7674 (C. Woods)

1. Introduction

the maintenance ecosystem. includes additional use cases.

Proceedings of the Workshops of I-ESA 2020, 17-11-20, Tarbes, France EMAIL: melinda.hodkiewicz@uwa.edu.au (M. Hodkiewicz); emily.low@uwa.edu.au (E. Low);

2. Use Case

Data necessary for maintenance work management planning and execution is stored in many places. Much of the transactional data related to maintenance work management is stored in data and sensor values are stored in other separate systems. Provided that the data needed is in the relational database, queries on the data are possible. However, there are many fields to choose from (often more than 200) and no standards for selecting and naming fields. This is further complicated when there are multiple companies involved. This is often the case with maintenance contractors, OEMs and service suppliers who have their own CMMSs and other systems (with bespoke taxonomies and naming conventions) that are required to interface with their client’s systems for planning, scheduling and reporting purposes.

2.1. Use Cases Descriptions

Asset and component identification: Each machine (or other asset) of significant value has a machine identifier (serial number). Many field names are used to describe this such as serial_no, asset_id, ID, asset number, Asset Num and MachineID. An asset or, in the case of rotable items, different assets, can be located at any one time in one or more physical locations. The physical location where maintenance work takes place is called the functional location and is variously described as FL, Floc, Location and FuncLoc amongst others. The existence of multiple names for the same physical asset and functional location causes headaches for maintenance contractors, suppliers and the increasing number of organisations that provide cloud based services to multiple clients. This is further complicated when different taxonomies are used. The taxonomy used by the OEM (by serial number and product type) can result in components or maintainable items (and their roles) being identified differently to the way they are in the customer database. Checking alignment of fields across the systems is often done manually and there are no easy ways to do automated semantic checks that the fields are indeed aligned.

Event and failure code use validation: Maintenance and reliability engineers use items from lists in order to standardise how events and states are coded for data collection. Examples include failure mode codes (e.g. fail to open, abnormal vibration). It takes considerable manual effort by engineers to look at the other fields in the record to check and see if the correct code has been applied. For example, are codes appropriate given the maintainable item and maintenance strategy type (e.g. scheduled replacement, on condition)? This manual reasoning could be replaced by automatic reasoning. For example, you cannot have an electric short on a fan belt or piping.

Proceedings of the Workshops of I-ESA 2020, 17-11-20, Tarbes, France EMAIL: melinda.hodkiewicz@uwa.edu.au (M. Hodkiewicz); emily.low@uwa.edu.au (E. Low); caitlin.woods@uwa.edu.au (C. Woods); ameri@txstate.edu (F. Ameri) 0000-0002-7336-3932 (M. Hodkiewicz); 0000-0003-1576-7442 (E. Low); 0000-0001-7829-7674 (C. Woods) ️©

2020 Copyright for this paper by its authors.

Maintenance event context identification: Downtime accounting systems (DAS) are used in many production systems such as chemical plants and mining operations. The operators create a record in the DAS every time an asset stops or operates at a reduced rate. When there is a failure event it is desirable to link the DAS record with the maintenance notification for analytics purposes. However, currently there is no common key and hence human reasoning is required. Access to the DAS record provides links to the process control system and thus to the operating status of the machine and the sensor data for the circuit in which it is operating. The maintenance notification provides links to the history of maintenance work order records which document maintenance tasks, as well as the maintenance plan and the maintenance schedule so checks can be made to see if there was a structured maintenance task in place. Collectively, this data is necessary for understanding the context of failures with a view to predicting future events. Currently, collating this is largely a manual exercise.

2.2. Competency Questions

OEM or Maintenance Contractor questions • What are the life cycle costs of machines owned and operated by our customers? • In what operating environments are our machines being deployed? • What are the most common failure modes experienced by the assets we have sold, or are servicing? • Are the failure mode codes in the unstructured corrective maintenance work orders appropriate for the maintainable item that they are assigned to? • What work orders generated from fixed interval structured maintenance task specifications are overdue? • What were the production circumstances (in DAS and production systems data) associated with the maintenance notification of machine X on date Y?

2.3. Relevant Terms

The top-18 terms relevant to the Maintenance Working Group of the IOF can be found in Table

3. Term Definitions and Axioms

The subject matter expert (SME) definitions, formal definitions, and first order logic (FOL) axioms for a selected subset of the Maintenance Working Group of the IOF top-18 terms can be found in Table 2.

2020 Copyright for this paper by its authors. [3] Functional location [9] Maintenance notification [15] Material product produc[4] Machine identifier [10] Maintenance schedule list [16] Restoring function pro[5] Machine maintenance

[11] Maintenance strategy [17] Maintenance notification plan [6] Maintainable item type record [12] Maintenance work order [18] Structured maintenance [13] Structured maintenance task specification [14] Material product production process plan tion process cess trigger trigger

[7] Maintainable item role [2] Failure mode code

[8] Maintenance task The classes described in Table 1 are captured in a Protégé file available at https://github.com/ uwasystemhealth/IOF_Maintenance_Working_Group_Public/tree/IESA-2020-snapshot. We use the prefix MNT, which stands for maintenance. This MNT ontology uses classes imported from the IOF ontology described in [3]. Figure 1 shows the class diagram for the classes detailed in continuant, occurrent and information content entity classes of the BFO. For more details on relations between MNT classes and specific BFO and IOF classes we refer the interested reader to the Protégé file just mentioned.

2020 Copyright for this paper by its authors. Proceedings of the Workshops of I-ESA 2020, 17-11-20, Tarbes, France EMAIL: melinda.hodkiewicz@uwa.edu.au (M. Hodkiewicz); emily.low@uwa.edu.au (E. Low); caitlin.woods@uwa.edu.au (C. Woods); ameri@txstate.edu (F. Ameri) 0000-0002-7336-3932 (M. Hodkiewicz); 0000-0003-1576-7442 (E. Low); 0000-0001-7829-7674 (C. Woods) ️©

2020 Copyright for this paper by its authors.

5. Discussions

Several ontological quandaries are still under discussion as this maintenance ontology is developed. Failure event is an obvious example. We think that there is a need to differentiate between two kinds of failure event. The first kind, included in this paper, occurs when a failure event results in the termination of a process. The second kind (definition to be covered in future work) occurs when there is deviation from a desired output, for example partial loss of pumping ability without total failure of the pump. Other challenges are associated with the sequencing of activities and events in the maintenance work management process where there are different sequences and activities depending on whether work is unexpected (a maintenance notification following a failure event) or a planned process as part of maintenance strategy. Future work will concentrate on these areas.

Acknowledgments References

The authors would like to acknowledge funding from the BHP Fellowship for Engineering for Remote Operations – supporting community projects in areas in which BHP operates. [1] AS IEC 60300.3.14, Dependability management Application guide - Maintenance and main2019. ️©