Ontology-Based Context Modeling in Physical Asset Integrity Management

Asset management is concerned with the management practices, technologies and tools necessary to maximize the value delivered by physical engineering assets. IoT-generated data are increasingly considered as an asset and the data asset value needs to be maximized too. However, asset-generated data in practice are often collected in non-actionable form. Collected data may comprise a wide number of parameters, over long periods of time and be of significant scale. Yet they may fail to represent the range of possible scenarios of asset operation or the causal relationships between the monitored parameters, and so the size of the data collection, while adding to the complexity of the problem, does not necessarily allow direct data asset value exploitation. One way to handle data complexity is to introduce context information modeling and management, wherein data and service delivery are determined upon resolving the apparent context of a service or data request. The aim of the present paper is, therefore, 2-fold: to analyse current approaches to addressing IoT context information management, mapping how context-aware computing addresses key challenges and supports the delivery of monitoring solutions; and to develop a maintenance context ontology focused on failure analysis of mechanical components so as to drive monitoring services adaptation. The approach is demonstrated by applying the ontology on an industrially relevant physical gearbox test rig, designed to model complex misalignment cases met in manufacturing and aerospace applications.


INTRODUCTION
Typical applications of internet of things (IoT) technologies amalgamate the ability to identify, sense, compute, communicate and sometimes actuate, for the purpose of monitoring and remotely controlling the environment (de Matos et al., 2020). According to a Statistica report. (2020), it is predicted that the amount of devices with Internet connectivity will exceed 50 billion by 2030. Such devices produce significant volumes of data which are communicated through networks, and upon processing enable better informed decision making and actions. One method of handling the high complexity of such volumes of data is by introducing context information management. Context is a key aspect in the process of leveraging information concerning situations and enabling applications to be adapted according to the perceived context (Pradeep and Krishnamoorthy, 2019).
Systems with context awareness are employed within IoT environments for the purpose of sensing the operational environment and for delivering an appropriate response to both the user and application (Perera et al., 2014). Such systems are capable of analyzing the data generated by IoT devices, generating a high-level of semantic organization of data and then converting it into context information. This information is subsequently utilized in determining an environment's status so as to drive appropriate responses. In general, the status of the environment is determined by a combination of circumstances, including users, applications, location, or devices (Abowd et al., 1999), which constitute the context information. As IoT technologies become more embedded in monitoring activities, there is a growing necessity to manage their context information in industrial environments. This entails gathering, modeling, reasoning, and disseminating context in order to efficiently manage the data generated by multiple devices and to ensure that they can be effectively integrated into enterprise systems. Nonetheless, data contributing to context information are often modeled or processed within the narrow scope of isolated subsystems, restricting interoperability. Moreover, even when similar systems for collecting context are applied in distinct settings, information is infrequently shared between them (Perera et al., 2014).
The ability to share context among different applications is a critical necessity for the IoT, making data shared between heterogeneous systems reusable in multiple applications (Ramachandran and Krishnamachari, 2019). Context information management has been recognized as a challenge for relevant research and early on Bernardos et al. (2008) developed a data fusion framework for context-awareness systems that included the following stages: (i) Obtaining context, (ii) processing context, (iii) reasoning and decision-making. Perttunen et al. (2009) have surveyed popular context reasoning and representation techniques and provided an overview of the requirements for context representation, arguing that such requirements were insufficiently covered in the literature regarding the interplay between efficiency, expressiveness, soundness, and completeness, with ontology-based approaches achieved improved scalability and reuse compared to other approaches. This finding is consistent with that of Bettini et al. (2010), although scalability of on-line reasoning with a large number of entities is raised as a significant challenge. This is the case when dealing with data of significant complexity and scale, as typically encountered in IoT applications (2020), making it important that the semantics of IoT data are captured by appropriate context modeling to gain valuable insights (Perera et al., 2014).
Context information management has largely dealt with the challenges of ubiquitous environments, as well as the data heterogeneity and services scalability. Nonetheless, while substantial research efforts have been devoted to context information management in web-based, mobile and ubiquitous computing, including IoT-enabled computing, little attention has been given to translate these advances to tangible progress in industrial monitoring services (Al-shdifat and Emmanouilidis, 2018). Context modeling in the literature is typically handled via ontologies. However, when dealing with monitoring services in manufacturing environments, developed approaches often lack expressiveness concerning the representation of the domain knowledge. To address such needs, this paper analyses requirements and produces a design for the components required to develop effective context-aware systems to enhance monitoring services in industrial environments. It then presents the development of a context resolution service focused on failure analysis of mechanical components so as to drive monitoring services adaptation. The paper is structured as follows. Section related work briefly discusses literature related to context information sharing and ontologies in maintenance and asset management. Section system framework and methodology presents the system framework and the ontology development process, based on established practice and maintenance vocabulary standards. An instantiation of the developed ontology is implemented for testing on an industrially relevant test rig and is presented in section implementation on a case study. Section results and discussion presents and discusses the ontology design and its implementation, including examples of context resolution results. The final section summarizes the key contributions of the paper and suggests potential further research pathways.

RELATED WORK
The following section presents a discussion on the basic concepts in the field of context-aware systems including context, contextawareness in IoT, the context information sharing, as well as the ontologies in maintenance and asset management.

Context Information Management
The concept "context-aware" system was originally proposed by Schilit and Theimer in 1994 stating that "A system is context-aware, if it uses context to provide relevant information and/or services to the user." Other early works have defined context as "any information that can be used to characterize the situation of an entity, an entity is a person, place, or object that is considered relevant to the interaction between a user and an application" (Abowd et al., 1999). Abowd and Mynatt (2000) specified the basic elements required for analyzing and understanding context, namely the five Ws (what, who, where, why, and when). According to Byun and Cheverst (2004), a system is defined as being context aware if it is capable of extracting, interpreting and using context information and its functionality can be adapted to the prevailing context of use. In the domain of asset and maintenance management, the early definition of context by Abowd et al. (1999) can be adopted and extended by specifying that context is relevant to the asset and its hierarchy, the user, the production or service business circumstances, as well as overall system and operating environment aspects (Emmanouilidis et al., 2019). Despite the generally acknowledged definitions of what is regarded as context awareness, a standard format and representation of the concept has not been established (Xu et al., 2014;Perera et al., 2015;de Matos et al., 2017). Various researchers have determined different typologies of context. Abowd et al. (1999) differentiated between primary and secondary context, in addition to conceptual and operational. Liu et al. (2011) stated that context can be classified as user, physical or networking. Table 1 provides a summary of the different approaches adopted for categorizing context.
According to Perera et al. (2015), the steps required for a system to deliver context information are acquisition, modeling, reasoning, and distribution which combined form the context lifecycle. In the acquisition step, the raw data are collected from sensors, databases or the surrounding environment. In the modeling stage, the data is brought into a particular representation so it can be converted into input for the reasoning stage. Various approaches have been described in the current literature for the modeling process, including key-value pairs, ontology, and markup schemes (Bettini et al., 2010;Snidaro et al., 2015). The semantic processing stage in the context lifecycle is the reasoning process, where different methods can be used for inferring context, such as such as supervised/unsupervised learning, rules, ontologies, probabilistic approaches, as well as data aggregation and fusion mechanisms (Perera et al., 2015). Hence, the context-awareness of a system is determined by its ability to utilize the context acquired via the context lifecycle to deliver beneficial information/services to users (Abowd et al., 1999). Several context-aware systems utilize context purely for decision support/making or direct distribution to the end user. Nevertheless, certain systems allow context information to be shared with other interested actors or subsystems. This is defined as context information sharing and represents one of key challenges in the field of context-awareness for IoT (Perera et al., 2015;Boavida et al., 2016).

Industry 4.0 and Context Interoperability in IoT
When considering IoT usage in industrial environments, the term Industrial Internet of Things (IIoT), or simply Industrial Internet, is employed, and is being considered as fundamentally linked to Industrie 4.0 (I4.0) (Jeschke et al., 2017). Comprising technologies such as IIoT, robotics/automation/control, additive manufacturing, simulation, cloud-based computing and platforms, industrial security, cognitive computing and artificial intelligence, mobility and wearables, big data and analytics, systems integration, augmented and virtual reality, as well as smart and new materials, I4.0 gives rise to new services and business models (Frank et al., 2019), driven by such technologies. Product Lifecycle Management (PLM) systems are particularly benefitting from such technologies to connect physical assets and products, processes, data, people and business systems (Keivanpour and Ait Kadi, 2019) exploiting product embedded sensor and intelligence capabilities, including product or process Condition Monitoring (CM) capabilities. Recent developments in IoT technologies have led to a renewed interest in context-aware computing. Context-awareness plays a central role in defining what data needs to be collected and how to be processed, as well as in determining what information and services are required to be made available to a consumer of data or services (Perera et al., 2014;Sezer et al., 2018). Context management is considered to comprise context acquisition, modeling, reasoning, and dissemination (Perera et al., 2014). Table 2 summarizes surveys of IoT context-aware systems from 2010 to 2020.
Context information can be provided in various different ways, including variations in format, length, type, and representation of the data (de Matos et al., 2020). Hence, there is a need to ensure that context sharing platforms offer context interoperability. Context-relevant data can be produced by IoT entities and context management needs to be handled through a context management information processing layer. This layer would be expected to handle context data produced from multiple sources, including third-party software. Therefore, context sharing functionality is facilitated by a context sharing platform. The platform is capable of creating semantic interconnections between domains via the sharing of context information. As IoT environments can be highly complex, context-sharing platforms must be capable of dealing with a range of situations and implement service adaptation mechanisms driven by context building blocks (de Matos et al., 2020). These building blocks can be categorized as Properties and Architectural Components. The former applies to predominantly software aspects of context sharing platforms, including Modeling, Reasoning, Dissemination, Processing, Interoperability, Privacy, Scalability, and Availability, as shown in Table 3.
Architectural considerations regarding enabling hardware for the deployment of a context sharing platform, include communication technologies, storage space, and processing layers. Furthermore, some building blocks are strictly related to the context sharing properties (e.g., Modeling, Reasoning, and Dissemination), which are those that are specifically required in industrial monitoring. There are a variety of different IoT platforms, frameworks, services and middleware that are capable of collecting, processing and analyzing sensor data. In this regard, various researchers (Perera et al., 2015;Mineraud et al., 2016;Sezer et al., 2018;Pradeep and Krishnamoorthy, 2019;de Matos et al., 2020) have produced surveys of such IoT platforms, frameworks, systems, prototypes, middleware, and various different techniques and some representative examples are listed in Table 4, showing also their context modeling, reasoning, and dissemination features.
While all the approaches deal with some form of context management, starting from acquisition and modeling, eventually actionable context needs to be domain-specific. In the application domain of asset and maintenance management, context strongly depends on assets and their hierarchy. Unless such context is captured, it is hard to convert IoT-generated data from industrial systems to actions. Therefore, it is important to create a representation that integrates qualitative and quantitative data, wherein data and service delivery is determined upon resolving the apparent context of a service or data request. The most common approaches to achieve this, as seen in Table 3, is through ontology-based modeling. An ontology formally represents knowledge through concepts and relationships that exist in a specific domain and are a key construct of the semantic web (Gayathri and Uma, 2018).

Ontologies in Predictive Maintenance and Asset Management
As the manufacturing environment is becoming knowledgeintensive and more dynamic, maintenance is becoming more and more crucial in Asset Lifecycle Management. The use of semantic technologies, particularly ontology-based modeling for predictive maintenance, has become an important research topic and thus many ontologies have been offered to promote knowledge representation and reuse within the context of predictive maintenance. Medina-Oliva et al. (2014) developed a knowledge model for fleet predictive maintenance to handle fleetwide contextual knowledge, arguing that fleet-wide Prognostics and Health Management (PHM) requires a knowledge-based system capable of handling contextual information. Thus, decision-making processes for diagnosis and maintenance are strengthened by semantic modeling, which deals the definition of concepts and relationships between them. In another example, an ontology was developed for the predictive maintenance in the wind energy domain and used as a basis for the identification and diagnosis of faults for monitoring the condition of wind turbines (Papadopoulos and Cipcigan, 2010). The proposed ontology model was used, by conducting ontology queries, to detect potential failures and their specific locations in the gearbox of the Wind Energy Converter (WEC). When considering the manufacturing domain, it is of interest to capture the functional impact of asset integrity level on the actual manufacturing process. Castet et al. (2018) presented an approach for capturing fault information in a modeling environment using ontology of fault management and a set of plugins designed to automatically extract two reliability artifacts, the FMECA and fault tree. FMECA offers a sound basis upon which to express the organizational and functional association between a manufacturing asset hierarchy and its linkage with the functional integrity of the production facility. In the same year, Nuñez and Borsato (2018) conducted another study proposing an ontological model called OntoProg, serving as a widely agreed data and knowledge representation scheme for diagnostic-oriented maintenance, capable of being used in different types of industrial machines, and a set of SWRL rules to improve the ontology's expressiveness were suggested. In another recent example of an ontology-based approach to predictive maintenance, fuzzy clustering is employed to infer the criticality of failures, while SWRL rules are employed for predictive reasoning for the transition between states of different criticality, without though applying context-specific modeling an reasoning (Cao et al., 2019). Ontological approaches to support maintenance management that employ industrial scenarios have been developed for a range of assets, including urban infrastructure (Wei et al., 2020), highway infrastructure (France-Mensah and O'Brien, 2019), Building Information Management (BIM) (Farghaly et al., 2019), transport infrastructure (Ren et al., 2019;Li et al., 2020), and railway infrastructure (Dimitrova et al., 2020). Table 5 summarizes of ontologies in maintenance and asset management.
The review of the related research work reveals two issues. Firstly, there is a missing link between knowledge constructs and context-dependent operational reliability-based services adaptation actions. Focusing on the asset context, relevant domain knowledge can be modeled in many forms but of particular interest are knowledge constructs relevant to reliability analysis, such as Fault Modes, Effects (and criticality) Analysis, FME(C)A. FMEA or FMECA models are however often utilized as a design-stage engineering study. Maintenance services, on the other hand, need to be invoked during the operating time and, thus, relevant information representations need to be enriched to enable dynamic context inference and the composition of contextually relevant services. Secondly, existing predictive maintenance approaches in the manufacturing domain are still limited to the deployment of condition monitoring systems for identifying the failure mode and effects analysis in mechanical components. Therefore, the resolution of asset context is needed to analyse mechanical systems and logically connect measurements, observed behavior and intended function, with machinery operating condition and faults. To this end, FMEA offers appropriate grounding for the baseline of the knowledge mapping. According to Keivanpour and Ait Kadi (2019), failure mode analysis based on FME(C)A is recommended to ensure that maintenance activities are consistent with established fundamental practiceoriented knowledge. The following section presents an ontologybased development to describe knowledge through concepts and relationships that exist in a specific domain.

SYSTEM FRAMEWORK AND METHODOLOGY
This section presents the design of a system framework to develop a maintenance context ontology focused on failure analysis of mechanical components so as to drive monitoring services adaptation. The proposed ontology for the context resolution mechanism is relevant to failure analysis of mechanical components, and the terminology and relationships between concepts are structured on the basis of relevant standards with a reliability-oriented knowledge grounding. A mechanism for reasoning is being utilized for the delivery of context resolution and the obtained context can introduce a metadata layer on data or events produced by either automation or human-driven means. An example of 6health management of rotating machinery is utilized to offer a basis for the domain context, but the actual upper level ontology expressiveness is such that can apply to a range of machines by extending it through more specialized or application specific detailed ontologies. The ontology is being utilized for the storage of knowledge relevant to fault diagnosis and reliability analysis through monitoring techniques. Hence, it is possible to query which type of approach for condition monitoring should be used and in what manner. Thus, queries can be made about what kind of condition monitoring technique that should be used and how. Additionally, inferences can be drawn in the

Contribution References
A formal ontology for semantics in maintenance platforms Production system An ontology to produce new knowledge in the field of industrial maintenance that supports decision-making in the maintenance process.

Karray et al., 2012
Ontology-based implementation of an advanced method for time treatment in asset lifecycle management Lathe machine Implemented a method for exploiting the characteristics of time in maintenance asset lifecycle management (ALM) systems.

Matsokis and Kiritsis, 2012
Ontology-based schema to support maintenance knowledge representation with a case study of a pneumatic valve Pneumatic valve A methodology for knowledge representation using ontology concepts is proposed to overcome the problems of heterogeneity and inconsistency in maintenance records. sense that it is possible to make a comparison between an obtained value and specific thresholds based on relevant ISO standards in order to determine whether the value can be categorized as Good, Satisfactory, Alert or Alarm. Therefore, if the recorded value is considered to be in the Alert category, the system diagnoses that a failure could occur and a maintenance notification is issued for the machine indicating that intervention is required. Subsequent to the identification of an alert notification, it is then necessary to connect it with diagnostic information of the mechanical part being investigated, which will allow the failure mode and the potential causes to be determined. Nonetheless, such simple threshold-based rules often fail to apply in practice and in view of that the ontological approach does not seek to replace actual diagnostics techniques, which may involve far more efficient and sophisticated data processing. Instead it acts as a meta-layer of knowledge to drive services adaptation, and as such could work in synergy with other techniques of data processing and condition monitoring approaches. The intended end result is that the proposed maintenance intervention is more directed, and tailored to the apparent context of a situation. The process was applied as follows: • A concept knowledge base is established and created on the basis of the professional expertise of mechanical engineers. The fundamental concept knowledge pertaining to the domain of condition monitoring is founded on professional expertise, associated studies and standard specifications. Extraction and representation of the necessary signal functions is then performed. • The knowledge is then transformed into ontology and SWRL rules. The ontology editor Protégé 5.5 along with its plugins (e.g., SWRL editor) are utilized in this stage. • Implicit knowledge is extracted from the knowledge base by the ontology management system according to the SWRL rule engine. • Identification of the source of the vibration is performed using the obtained signal as input and then conducting Pellet reasoning. Figure 1 provides more details about the system.

Maintenance Ontology Development
The development of ontology can be based on one of the numerous procedures described in the literature, including Uschold and King, Grüninger and Fox, Methodology, Ontology Development 101 (Noy and McGuinness, 2001) (OD1) and KACTUS. The OD1 is utilized in this study as it is broadly employed (Gong and Janssen, 2013;Lau et al., 2014;Nuñez and Borsato, 2018;Ren et al., 2019), has been demonstrated to be highly appropriate for maintenance modeling, and has been extensively documented for application in the Protégé environment. The OD1 initial step is to determine the scope and domain. In this phase, the focus of the maintenance ontology is on modeling failure analysis of mechanical components to answer queries regarding how faults manifest themselves and how they can be prevented or addressed, so as to adapt relevant diagnostics or maintenance actions in a Condition-Based Maintenance setting. Therefore, the domain of the model is Maintenance.
The next OD1 steps are to consider reuse and enumerate terms. In this regard, ontological models developed by other researchers should be considered to determine their adaptability to the current research proposal such as those proposed in Nuñez and Borsato (2018), Sanislav and Miclea (2015). Moreover, this phase involves the enumeration of all terms pertinent to the area of the ontology being developed. Therefore, the main terminology and the associated definitions are based on consolidated academic literature and mostly on established international standards, such as condition monitoring, diagnostics and maintenance (ISO, 2012(ISO, , 2017, vibration analysis (ISO, 2018), failure analysis (IEC 6030 0-1, IEC 6030 0-3-1), monitoring parameters: (ISO, 2011), asset management (ISO, 2014), and MIMOSA (www.mimosa. org) standards.
In the next phase, all classes and sub-classes are classified following a top-down approach. It starts with the most general definition of a domain concept and then continues with the more specialized concepts. In this context, the main class is of the Maintenance Ontology includes the subclasses Asset, FMEA_Technique and ConditionMonitoringParameters. Every such class has its own subclasses for example, subclass FMEA_Technique has subclasses: FailureEffect, FailureMode, PotentialCause, and Symptom. An example of class hierarchy is shown in Figure 2A.
The next steps in this process include the design of entities and properties. Entities are all the subjects of the studied domain; properties are verbs that clarify the relations between subjects and objects, or between-subjects themselves. Subsequent to defining the class hierarchy, it is important to determine the class relationships. They need to be accompanied by three distinct types of properties: object properties, data properties. The object attribute explains the associations among distinct classes. The data property explains the properties of certain occurrences both quantitatively and quantitatively. Figures 2B,C show the aforementioned object properties, data properties. The final stage is to create specific individual class instances within the class hierarchy, which involves: (1) selection of the class, (2) creation of an individual occurrence of the class, and (3) filling slot values. These instances are used in the representation of particular elements. Figure 2D presents class individuals.
Along with identification of the procedure that has been adopted, the development of ontology models requires tools that can support all activities in the development process. Such tools include TopBraid and OntoStudio, as well as open ones, such as the popular OntoEdit, HOZO and Protégé. Specifically, Protégé is the most dominant ontology publisher due to the fact that it is an open platform that offers plug-in extensibility as well as XML (S), OWL, RDF (S), and Excel support, along with graphic taxonomy, queries in SPARQL, rules in SWRL language, and a reasoner (Pellet). The combination of OWL/SWRL provides a more flexible ontology language for modeling knowledge domains with a greater degree of expressiveness than using OWL alone (Lawan and Rakib, 2019). The SWRL is a W3C recommendation that extends horn-clause rules to OWL. OWL has demonstrated significant expressive powers over other ontology languages as the recommended ontology language for the semantic web. While OWL ontologies provide simple, reusable and easy to understand domain knowledge models, they lack the declarative expressiveness offered by rules developed in SWRL.

IMPLEMENTATION ON A CASE STUDY
The applicability of the developed ontology model is shown by utilizing a real physical asset. Gearboxes have broad utilization in numerous applications such as machine tools, industrial devices, conveyors and essentially any form of rotatory power transmission equipment in which the torque  and speed requirements need to be changed. If such devices fail, the results can often be catastrophic accidents with serious consequences. Therefore, a proactive approach must be adopted that enables such components to be monitored in real-time utilizing predictive maintenance methods (Khan et al., 2019). In the present study, the technique of vibration analysis is approached. Techniques used for assessing the health of components based on vibration are regarded as applicable for numerous reciprocating and rotating machines (Giurgiutiu et al., 2001;Bajrić et al., 2011). A laboratory-based test rig was employed and data was collected from its operation, and maintenance records. This has been designed for emulating complex cases of misalignment, relevant to manufacturing and aerospace engineering assets.
In order to capture the operational health of the machine, the test rig must be analyzed, allowing for an understanding on how to best capture the degradation effect on the test machine. As stated in ISO/FDIS 17359:2002(E), which details the flowchart for starting the condition monitoring process, the start is to choose the machine components in the maintenance ontology. Then, the necessary functionality of each of the components is explained for the machine to operate correctly. Additionally, all failure modes, effects, causes, symptoms and measurement approaches pertaining to the machine components are inputted utilizing the FMEA method. Subsequently, the implementation of the FMEA method indicates the most suitable measurement locations and their limits for the measurement of values by employing the vibration analysis method for prediction, which are based on ISO (2002), ISO (2016), and ISO (2009). The most pertinent components along with the most appropriate measurement methods are identified by utilizing the FMEA classification, which assigns weights according to the highest severity (SEV), occurrence (OCC), detectability (DET), and risk priority number (RPN).

Failure Mode and Effect Analysis
Asset context must be resolved for the analysis of mechanical systems and to establish logical connections between measurements, perceived behavior and the desired functionality, and the operating health and defects. In this regard, Fault Modes and Effects Analysis (FMEA) provides a suitable basis for the baseline of the knowledge mapping (IEC, 2018) due to various reasons. First, the qualitive components renders it suitable for the abstraction of maintenance knowledge focused on reliability.
Second, the quantitative component allows maintenance tasks to be prioritized on the basis of measurements conducive to an approach based on risk. Third, its bottom-up structure allows failure to be assessed starting from the basic level of production systems; in other words, data are analyzed from machinery parts through to the overall system. The initial stage involves the determination of the specific aspects of the machine that have the potential to fail and then to comprehend the causes and effects of such failures (FMEA). Based on the study, it will become apparent where the data will be most accurate in highlighting the degradation of the machine being tested. Alongside the misalignment testing carried out on the machine, the rig can test the effects of loading through the dynamometer and the subsequent effects that loading will have on the system (Figure 3). Based on the FMEA Table 6 (del Castillo et al., 2020), the most frequent outcome of misalignment of the gearbox will be vibration and power transfer loss through gearbox, as revealed by the RPN values. Subsequently, the vibration is spread across the machine and is most pronounced in specific locations, namely the bearings, and it is possible to easily capture the transfer loss by calculating the RPN difference between the driving motor and the loading dynamometer. As determined by the FMEA analysis, the two potential failures that are identified as having the greatest level of severity if misalignment or loading occur in the system are degradation of the gear teeth in the gearbox (RPN 150) as well as the bearing degradation (RPN 140).
Wearing of the teeth is generally caused by misaligned gears, excessive loading and lastly, a lack of lubrication. Degradation of the bearings is caused by wearing of the teeth in the gears as well as the impact of gear vibration being transferred to the shaft and then to the bearings. If the shaft of the gear is short The bold values refer to components of high significance (RPN) in failure analysis. and hard, and the bearings are situated in close proximity to the center where meshing of the gears occurs, this can be a source of vibration, which can be measured by placing sensors at the bearings as shown in Figure 3.

RESULTS AND DISCUSSION
The aim of ontology-based context modeling is to produce a semantic organization of data so as to drive maintenance services adaptation. When users interact with systems in this regard, the proposed maintenance ontology can help them (e.g., maintenance engineers) to narrow down the list of options by providing answers to questions such as: • What are the common failures and diagnostic approaches for a given machine type? • Which physical parameters to measure/use?
• What is the recommended preventive or corrective action for a specific failure mode of an asset?
An example of a typical utilization scenario is that during condition monitoring queries could be raised to resolve the monitoring service context. For instance, this could be related to determining the failure modes of a part, the functional effect of a defect on the operation of the test rig, the measurement alternatives suitable for specific defects and parts, in addition to the relevant measurement parameters. In the context of the present study, SPARQL queries were designed for the resolution of these queries. SPARQL additionally allows the federation of queries across different sources of data. By applying the following query, it is possible to determine "what are the main components of the Test rig?" Figure 4 shows the results of a query to identify the main components of an asset type. These components are bearing, coupling, lubricant, rotor, seals, and shaft. Moreover, the present implementation allows a query in the maintenance ontology to resolve key analysis characteristics, such as components function, failure modes, causes, and effects. This query can be useful to a maintenance engineer in order to link faults to functional impacts, and other information to ensure the correct identification of the component being analyzed as shown in Table 7.
Another query can be applied based on FMEA to answer what are the common gearbox problems and diagnosis methods. For example, problems that arise in relation to gearboxes are misalignment, lubrication issues, bearing problems, gear teeth defects, thermal instability, and torsional and lateral vibration. Considering that the test rig under study was designed to study complex cases of misalignment in industrial machinery, the focus here will be on misalignment cases. Misalignment in gearbox arrangements can cause gear and bearing pitting, which eventually leads to complete failure. It may lead to vibrations and excessive loads that harm functioning components of the machine, such as bearings and oil seals. It is therefore important to detect and fix such issues to avoid incurring any unnecessary costs. As shown in Figure 5, this can take four forms: Axial misalignment; Offset or Parallel misalignment, when the centers of shafts are on different lines; Angular misalignment, when a motor shaft is at an angle to a driven component shaft; and Combination misalignment, when both angular misalignment and parallel misalignment occur.
After identifying the common gearbox problems, then it is important to identify parameters to be measured for fault detection. The developed ontology links physical measurement entities with appropriate measurement techniques. This allows to associate common faults with the physical asset and to match them with parameters or techniques appropriate for detecting the occurrence of such faults. For example, a component that has high significance in failure analysis is the bearing ( Table 8). A critical failure mode is gear tooth wear and the typical failure effects for this is partial tooth contact (Misalignment). Another query can be applied to determine failure modes, failure causes, failure effects, symptoms, and fault severity (SEV), but also to determine the faults with highest diagnostic potential (DGN) or faults which pose the highest impact risk. SEV and DGN scale from 1 to 10, with the higher number representing the higher seriousness or risk and an appropriate query can return the faults with the highest DGN (Table 8) or risk. Therefore, parameters such as SEV, DGN and DET from the FMEA technique can be used within the ontology model to enable queries which in turn can identify components or processes of priority for maintenance actions.
Real data collection from the shop floor or simulated data (with "hasCurrentValue" data property) can be used to infer the component's health status and trigger alerts for decision making, such as the prognosis of a failure and the scheduling of Condition Based Maintenance (CBM) actions. In this regard, the SWRL language is being used in object properties to construct  (lower level in asset hierarch) that includes an accelerometer acting as a transducer in the data collection process. The resulting assessed parameters can be for example the velocity of the vibration in RMS mm/s, with the measurement sites as defined by standard MIMOSA VB-00, while the operating zone limits based on the (ISO, 2009) standard. To determine the machine's health status and recommended actions, the following main SWRL rules are set: Let's assume that when the data for the rolling bearing part exhibits an RMS mm/s value between zero and ≤2.3, then it should display a "good" notification. When values that exceed 2.3 but are below 4.5 are detected, it should display a "satisfactory" notification; a value between 4.5 and 7.1 should trigger an "alert" notification, and values in excess of 7.1 should cause an "alarm" notification that will instantly terminate the machine operation. Given this, let's assume that a value of 4.7 mm/s RMS is recorded. This is fed through the ontology, activating the Pellet plugin reasoner in the Protégé ontology editor. The outcome will be that the component's health will be inferred to be set as "Alert, " producing a recommendation to "Schedule Conditionbased Maintenance. Moreover, once an ALERT warning has been issued, it is then important to associate it with the diagnostic information of the analyzed mechanical component, associating the identified the failure mode with potential causes (Figure 6). In this way, the maintenance intervention becomes context-depended and is therefore more focused and relevant to the identified context of the monitoring situation. While simple single-parameter threshold-based rules might be easy to interpret, they do not often hold in practice. Instead, more complex multi-parameter rules are more likely to apply. The reasoning process can replace simple rules with the activation of more complex decision functions which may be produced as a result of machine learning over monitoring historical data. The value of the described process is that it sits at a higher level of abstraction and can therefore work with different lower level computational rules.

CONCLUSION AND FURTHER RESEARCH
This paper presented the development of a context resolution service mechanism for industrial diagnostics, based on the design of a maintenance ontology focused on modeling and reasoning failure analysis of mechanical components. The maintenance ontology has been developed employing established methodologies and upon consulting a range of domainrelevant international standards. The ontology development was further applied on a physical mechanical transmission test rig. Thus, queries could be raised in terms of the resolution of the monitoring service context to determining the failure mode and its potential causes of the test rig, in addition to the relevant measurement parameters. Moreover, SWRL reasoning rules were used based on (ISO, 2009) for the evaluation of the data gathered, the prognosis of failure is being performed, sending a maintenance message for intervention in the machine. In this way, the maintenance intervention is more directed, ceasing to be exploratory. This highlighted the need for handling the whole context information management lifecycle and ontologies in maintenance and asset management to maximize the value delivered by physical engineering assets.
The outcomes of the work can be used in other industrially relevant application scenarios to drive maintenance service adaptation. While the application focus is quite specific, the ontology abstraction level is actually such that it could also be implemented on other application cases, as it offers a sound baseline for further customization or extensions. When serving different application scenarios, the derived abstract model developed with the process described in section system framework and methodology still holds, as the employed terms and relationships were developed employed established standards. However, after going through a similar process for deriving the application-specific part of the ontology as described in section implementation on a case study and the developed queries, as described in section results and discussion, additional needs can be identified, which may require the inclusion of additional entities, relationships, and queries development. This will be determined by going through an ontology assessment and evaluation cycle in the context of the new application scenario, especially regarding the ontology expressiveness and coverage. Nonetheless, this will affect largely lower abstraction level terms, rather than upper hierarchy classes and associated object or data properties. For example asset types and their associated terms if need be may be complemented by additional asset types. The higher level classes, object properties, and data properties will retain the structure of Figures 2A-C but the population of lower tier terms and individuals for such class structures will need to be developed for the additional asset types, as typically holds in managing ontologies. However, the example reasoning rules presented in Section results and discussion can be re-used but can be extended with additional ones to cover the coverage and expressiveness of the updated ontology.
Consequently, further research should be carried out to link the current ontology implementation with a live condition monitoring service, as well as to apply it to real industrial environments as an enabler of more efficient IoT-enabled monitoring services.

DATA AVAILABILITY STATEMENT
The original contributions presented in the study are included in the article/supplementary material, further inquiries can be directed to the corresponding author/s.