predictive diagnosis based on a fleet-wide ontology approach
TRANSCRIPT
Accepted Manuscript
Predictive Diagnosis based on a Fleet-wide Ontology Approach
Gabriela Medina-Oliva, Alexandre Voisin, Maxime Monnin, Jean-Baptiste
Leger
PII: S0950-7051(13)00400-0
DOI: http://dx.doi.org/10.1016/j.knosys.2013.12.020
Reference: KNOSYS 2716
To appear in: Knowledge-Based Systems
Received Date: 15 February 2013
Revised Date: 16 December 2013
Accepted Date: 20 December 2013
Please cite this article as: G. Medina-Oliva, A. Voisin, M. Monnin, J-B. Leger, Predictive Diagnosis based on a
Fleet-wide Ontology Approach, Knowledge-Based Systems (2013), doi: http://dx.doi.org/10.1016/j.knosys.
2013.12.020
This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers
we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and
review of the resulting proof before it is published in its final form. Please note that during the production process
errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.
Predictive Diagnosis based on a Fleet-wide Ontology Approach
Gabriela Medina-Oliva1, 2, Alexandre Voisin2 Maxime Monnin1, Jean-Baptiste Leger1
1 PREDICT 19, Avenue de la Forêt de Haye, CS 10508, 54519 Vandoeuvre-Lès-Nancy, FRANCE [email protected]
[email protected] [email protected]
2 Centre de Recherche en Automatique de Nancy (CRAN), Université de Lorraine, UMR 7039 CNRS-UHP-INPL, Faculté des Sciences-1er Cycle - BP239, 54506 Vandœuvre-lès-Nancy Cedex – France
ABSTRACT
Diagnosis is a critical activity in the PHM domain (Prognostics and Health Management) due to its impact on the downtime and on the global performances of a system. This activity becomes complex when dealing with large systems such as power plants, ships, aircrafts, which are composed of multiple systems, subsystems and components of different technologies, different usages, different ages, etc. In order to ease diagnosis activities, this paper proposes to use a fleet-wide approach based on ontologies in order to capitalize knowledge and data to help decision makers to identify the causes of abnormal operations. In that sense, taking advantage of a fleet dimension implies to provide managers and engineers more knowledge as well as relevant and synthetized information about the system behavior. In order to achieve PHM at a fleet level, it is thus necessary to manage relevant knowledge arising from both modeling and monitoring of the fleet. This paper presents a knowledge structuring scheme of fleets in the marine domain based on ontologies for diagnostic purposes. The semantic knowledge model formalized with an ontology allowed to retrieve data from a set of heterogeneous units through the identification of common and pertinent points of similarity. Hence, it allows to reuse past feedback experiences to build fleet-wide statistics and to search “deeper” causes producing an operation drift.
Keywords: Ontologies, knowledge capitalization, knowledge reuse, maintenance, diagnostic.
1. INTRODUCTION
Nowadays, the high competitiveness faced by industrial enterprises requires higher performances, such as higher quality of products/services, lower costs, sustainability, etc. (Kleindorfer et al., 2005). This way, the importance of maintenance has increased due to its key role in improving system availability, performance efficiency, products quality, etc. (Alsyouf, 2007). These requirements promote the evolution of maintenance strategies from a “fail and fix” to “predict and prevent” approach. This new vision is supported by condition-based/Prognostics and Health Management (PHM) maintenance strategies (Iung et al., 2009). Despite this proactive approach, failures still occur. To minimize the effects of unexpected system failures, there is an increasing demand for improving fault diagnosis efficiency techniques in industrial machines (Lei et al., 2008) (Zio et al., 2008). In that sense, in complex domains such as the naval one, it can be difficult, especially for junior maintainers and even for experts, to generate the required hypotheses about the causes of failures or abnormal behaviour (e.g. symptoms occurrence) to resolve the unexpected situation (Moss et al., 2010). The resolution of these situations requires knowledge about the degradation mechanisms of different components built on several technologies (mechanical, electrical, electronic or software natures) (Verma et al., 2010) whose behaviour can vary over the different phases of their lifecycle and usage condition (Bonissone and Varma, 2005). In order to improve PHM processes for large and complex systems such as power plants, ships and aircrafts, one possible approach is to take advantage of the “fleet” dimension. This dimension can provide more knowledge and data to improve diagnostic and prognostic models (Monnin et al., 2011b).
2
A fleet shall be viewed as a set of systems, sub-systems and components. In this paper, the naval domain is addressed. Hence, in the following, a unit of a fleet will be considered as a system (e.g. ship), a sub-system (e.g. propulsion or electric power generation) or component (e.g. diesel engine, shaft...) depending on the target object. To be in accordance with the need of improving PHM at the fleet level, an original methodology is proposed in this paper wherein individual knowledge (of each unit) is capitalized for reuse purpose. The reuse knowledge is used order to improve PHM activities such as predictive diagnosis, which will serve as example in the last part of this article. To take advantage of the individual knowledge at the fleet level, a semantic model is proposed for the PHM activities in the naval domain. The added-value of this paper is to represent and structure in a semantic model the knowledge arising from the different PHM processes as well as from the domain of interest (in this paper the naval domain). Usually, applications using ontology in the PHM domain only focus on knowledge of a specific PHM process and for a single component (i.e. knowledge for diagnostic of an electric motor). This way different categories of concepts related to the PHM and system domains, called in our paper contexts, are modelled and relations between these concepts are explicit. Such a semantic model enables to reuse particular data, such as maintenance records, reliability analysis, failure analysis, data analysis at a fleet level in order to provide more knowledge. As data become available, PHM activities could benefit from more contextual information.
2. PHM AT COMPONENT AND SYSTEM LEVEL
PHM activities help to reduce the life cycle cost of a product by decreasing inspection costs, downtime and inventory (Pecht, 2008), (Vichare and Pecht, 2006). The proposed approach could be performed for any PHM activity but we focus on the diagnosis one in order to exemplify the proposed approach. (Lei et al., 2008) define diagnosis as a process of locating the exact causes of a failure. However, within the PHM activities in order to anticipate failures, “predictive diagnosis” is performed. Predictive diagnosis aims at warning about failure events before they occur and identifying the causes of degradation. For this purpose, features (i.e. variables) of the process and of the components are monitored. Degradation is then identified with the occurrence of at least one abnormal behavior on the process, manifested as symptoms (e.g. an event). Once the event has been detected, the maintenance operator/engineer needs to analyze the symptom behavior/evolution to understand which components may have caused the symptom and the reasons for the abnormal behavior of the component. In that sense, the diagnostic process involves two main sub-processes: generation of hypotheses about what could have been wrong and testing of these hypotheses (Öztürk and Aamodt, 1997). Since a machine has many components and is highly complex, diagnosis of a machine failure/degradation usually requires technical skill and experience (Lei et al., 2008). It also requires understanding the machine’s structure and operation. To better understand machine operation, the first step is to perform a functional analysis about the normal functioning of the system. Once functioning knowledge is formalized, abnormal situations are studied. Abnormal situations are studied through dysfunctional analysis (such as Failure Mode, Effects and Criticality Analysis (FMECA) and Hazard and Operability Study (HAZOP)) where degradation modes at different abstraction levels are identified (Muller et al., 2008). Moreover, the causes and consequences of the degradations modes have to be identified in order to define the underlying causality chain and to reach the system level. This causality chain helps to identify the link between the monitored variables and the degradation mode that is monitored in order to locate easily the abnormal behavior. Moreover it also requires knowledge about the context such as the operational conditions of the machine. In that sense, according to (Cinar and Kayakutlu, 2010) some of the input information valuable for diagnostic is: • Current data: on-line data in order to provide the values in real-time of the monitored indicators (variables). Data is
captured and must be treated and analyzed. This data provides information to maintenance engineers about the current state of the unit. It should be used to compare the evolution of the current situation with similar situations (e.g. similar case retrieval).
• Past data: feedback about past failures on the system, as well as historic data about the evolution of degradation indicators under different circumstances (mission, environment, etc.). This data allows comparisons among the current and the past behaviors. Moreover past events could be used to make statistics that could ease the hypothesis generation process about the causes of degradations.
Additionally as mentioned in (Peysson et al., 2009) the health of a complex systems (S) depends mainly on three factors (1):
ΡΕΜ= ,,S (1)
where M is the Mission that defines the use of the system during a time period; E is the Environment that represents the area where the mission is accomplished and where the process evolves and P is the process that gives the necessary means to
3
accomplish the mission. The process is decomposed according to the different resources that are monitored during the mission.
Such a model shows that the contextualization of the information according to the operational conditions and the usage of the machine is of great importance. For diagnosis purpose, experts could use this set of contextual knowledge in order to make hypothesis about the possible explanations of abnormal operation. Indeed, contextual knowledge allows a refinement on data analysis (facilitating the selection of relevant information for hypothesis reasoning).
While analyzing this knowledge, several sources of uncertainty may appear such as measurement and sensor errors, future load and usage uncertainty and so on. However uncertainty could be reduced when more data becomes available (Pecht, 2008). In these cases the notion of fleet becomes very interesting since it can provide more capitalized data and information coming from other members of the fleet for improving the efficiency on the solution of a problem (e.g. diagnosis). The following section presents a review about the use of the fleet notion in the PHM domain.
3. PHM VS. FLEET-WIDE APPROACH
3.1. Fleet integrated PHM review
A fleet generally refers to gathering ships into a group of ships and the term is extended also to any kind of vehicle (e.g. trains, aircrafts, or cars). For industrial systems, the term fleet refers to a set of assets or production lines that may share some common components. In this paper, the fleet is considered as an abstract point of view to define a set of objects for a specific purpose (e.g. a unit maintenance planning) and for a given time (e.g. before the end of the current mission) that share some common “properties”. The fleet can be viewed as a population consisting of a finite set of objects (individuals) on which a study is ongoing. In this context, a fleet is generally a subset of the real fleet under consideration, i.e. a sub fleet related to the aim of the study. Individuals composing the fleet/sub fleet may be, as needed, systems themselves (Bonissone and Varma, 2005), (Patrick et al., 2010), subsystems or components (Umiliacchi et al., 2011). In the following, systems, sub-systems or components constituting the fleet, will be referred to as units. In fact, fleet’s units must share some characteristics that enable to group them together according to a considered purpose. These common characteristics may be technical, operational or contextual (Monnin et al. 2011a). Such consideration allows to put data or information related to the whole selected fleet of units on the same benchmark in order to bring out pertinent results for the PHM activities. Common characteristics among units allow the definition of three types of fleet composition: identical, similar and heterogeneous fleets. Based on these three types of fleet, some relevant works are reviewed below: • Fleet composed of identical units: when considering maintenance operator’s point of view, fleet management aims at
making decisions that affect asset life extension and performance, operational costs and future planning (Wheeler et al., 2009), (Bonissone and Varma, 2005),(Williams et al., 2008). In (Patrick et al., 2010), the authors notice that condition monitoring thresholds could be derived from statistical studies of fleet wide behaviors and known cases of faults. (Reymonet et al., 2009) propose to apply to the failed system the technical solution corresponding to an identical incident already solved with an other identical asset. (Wang et al., 2008) present a similarity-based approach for estimating the Remaining Useful Life (RUL) in prognostic using data from a fleet composed by the same kind of units. Nevertheless, knowledge derived from this type of fleet arises from the same kind of units. Such consideration means that the units have the same technical features, usage, operational conditions,... In a domain where customized units are common, this approach may give poor results.
• Fleet composed of similar units: the fact of comparing similar units has rarely been addressed in the literature. In that
sense, (Umiliacchi et al., 2011) show the importance of having a standard format for the diagnostic data in order to facilitate their understanding across several subsystems and trains within a railway fleet. The units coming from this kind of fleet share identical or almost identical technical features, they have been submitted to similar operational conditions, but there are few differences between the units, either on their features or on their usage.
4
• Fleet composed of heterogeneous units: to fully exploit the knowledge issued of the fleet dimension, we propose in this
paper to consider heterogeneous units that compose the fleet level for decision making (e.g. maintenance purposes). Situations to investigate signal evolution issued from an historical data of a heterogeneous fleet are searched, based on some similar characteristics of the units in study (Monnin et al., 2011a) (Monnin et al., 2011b) (Medina-Oliva et al., 2012). In that sense, units composing this kind of fleet could have different technical features but they share some common and pertinent points of similarity to solve a given situation. The originality of the proposed method within the PHM domain is to enlarge the search to heterogeneous units where the similarity is defined on-line and interactively by the user, in order to find relevant information to be reused.
3.2. Fleet-wide approach to improve predictive diagnosis
One of the industrial reality is the lack of capitalization of knowledge and model reuse which represents high costs and efforts for the enterprises (Weber et al., 2012) (Medina-Oliva et al., 2013b). In some fields such as the naval one, units are very customized leading to heterogeneous units. These facts limits mainly: • Historical data reuse for identical units. Due to the exposition of industrials systems to different and uncertain missions
and environmental conditions. • Knowledge capitalization about the causality chain (e.g. cause-effects relationships) of a unit with identical technical
features.
To tackle this issue the fleet dimension can provide enough information and data to perform diagnosis. In that sense, when searching non-identical but similar units a higher volume of data becomes available to reduce diagnosis uncertainty (i.e. more confidence on the hypothesis generation). This data can be obtained through the identification of “similar contexts” or “similar individuals” (Zarri, 2011). For example, in the naval field, a technical similarity for diesel engines, which are critical components for propulsion and power generation, could be the membership to “4-strokes engines” or “high speed engines” classes. In order to perform diagnosis, different types of approaches and methods could be used according to the a priori knowledge available on the process. In that sense, two types of categories could be defined (Venkatasubramanian, 2003a), (Isermann, 2006), (Frank, 1996): classification and inference methods. The classification methods, do not dispose of a priori information on the possible causes. Thus they link the process monitoring features with different classification of faults. This approach uses pattern recognition for every fault based on the behavior of the features. Such methods include statistical and geometrical classifications, neural nets and fuzzy clustering. On the other side, inference methods use a priori knowledge on the relationships between faults and symptoms. These methods formalize these relationships through causal relations between faults and symptoms. Some of these methods are: fault-tree analysis (FTA), event-tree analysis (ETA), diagraph, FMEA, expert systems, etc. Both type of methods provides information about the failure occurrence, localization of the failure and on the possible causes but very often there is not certainty about the identified cause(s). Maintainers/engineers have to face a huge search space (i.e. a set of alternatives among the fleet) to identify the causes of abnormal operation. In that sense, in order to help the expert to reduce the search space about the possible hypothesis (i.e. causes of abnormal behavior) and to solve efficiently the problem, a priori contextual knowledge definition can help to retrieve relevant data about similar units, to refine the analysis of data and can facilitate the selection of relevant information. In that sense, searching data with contexts that take into account the main factors that impact system behavior, can improve efficiently the location/identification of the problem (Öztürk and Aamodt, 1997). To facilitate the selection of the relevant information among the fleet, the objective of our proposition is to create an iterative investigation process that will allow the definition of a sub-fleet. The sub-fleet is defined by grouping a set of units (i.e. systems, sub-systems or components) based on “similar characteristics”. Figure 1 presents the main steps of this process. When an event or abnormal behavior is detected and cannot be explained directly, then the situation must be first characterized in order to determine the expertise purpose. Situation characterization consists in the description of the unit subject of the study (e.g. type, age, usage, operating environment) as well as data on which analysis will be carried out (Figure 1-A). To guide this process, the fleet-wide application proposes different criteria based on the technical features of units as well as on the mission and on the environment description. According to this, a targeted population is defined within the whole fleet (Figure 1-B). The potential similar events are investigated in order to complete knowledge of the current situation (Figure 1-C). In an iterative process of steps B and C, the target fleet can be refined (closed loop by restricting
5
criteria) if results, such as the potential similar events, are too far from the current situation. Conversely, the target fleet can be extended (closed loop by enlarging criteria) if it points out too few similar situations. Then, the current situation benefits from the past experiences results and lessons-learned (Figure 1-D) and the results of the analysis are used as feedback in the database. Such a case-reuse process could provide benefits to almost all PHM activities (Monnin et al., 2011a), (Monnin et al., 2011b), (Medina-Oliva et al., 2012). Some of them are:
1. To design an individual PHM application such as degradation indicators definition, data processing, thresholds, architecture, Human-Machine Interface (HMI) for a new unit obtained from existent PHM applications.
2. To determine the causes of a current degradation mode or flow deviation from similar situations.
3. To determine which maintenance interventions seems to be more efficient to prevent the evolution of a degradation mode based on the lessons learned in the past.
Toward this goal, the knowledge corresponding to the fleet domain must be well formalized and structured in order to facilitate the manipulation of the multidimensional aspects of the fleet and the heterogeneous data among all fleet units’ databases.
Situation characterization
A
Available information Target
population definition
B
Sub fleet data/information
analysis
Targeted population
Iterative process enlarging/restricting
Current situation expertise
D C Information from
historical cases
Feed
back th
e result
In th
e datab
ase
Figure 1. Main steps for fleet case re-use
3.3. Sub-fleet characterization
Nowadays, fleet managers/engineers query separately (one by one) ship databases for identical units to obtain data/information. However, units in the naval domain are very specific and customized. This fact leads to dispose of few identical units. For this reason the proposed methodology leads to search non-identical but similar units. Furthermore, another issue emerges. At a fleet level, engineers must treat different databases of several units. These databases might be heterogeneous, in the sense that the database structure might be different, they might have different names for the tables, different primary keys and foreign keys, etc. Moreover, another issue when dealing with heterogeneous databases is the semantic heterogeneity. As discussed by (Partridge, 2002) databases could differ even if the tables and primary keys have the same name, the same syntax. They can
6
differ on their semantic. In that sense, two sources of semantic heterogeneity are identified: one coming from the disagreement between communities, as a part of disagreement on the interpretation and meaning and another coming from the disagreement in form, related to the intended use of the data (Sheth, 1999). To tackle these issues, a common semantic becomes necessary (Figure 2). A semantic model provides a high level definition of objects that is common to all databases allowing to query them. It allows to define characteristics of similarities among units and contexts, for instance, by defining common characteristics in the technical, operational and contextual domains. The semantic model gathers knowledge which is shared on one hand by the PHM community and on the other hand by the naval community. Both knowledge domains can be partially found in the heterogeneous databases. From a practical point of view to use the semantic model as a unifying model, when a new unit joins the fleet with its own database, instances of the database are added to the semantic model as instances related to corresponding concepts in order to establish a link between instances of the database and the concepts of the semantic models. In that sense, the instance of the semantic model contains: the Id. of the database + the Id. of the table + the Id. of the instance itself. In the following sections a semantic model specifying the similar characteristics necessary to obtain data/information to perform diagnosis is presented. The semantic model is specified by means of ontologies.
Common Semantic level
Heterogeneous data-bases of units
Experiences and lessons-learned
Figure 2. Semantic level to query heterogeneous databases
4. PROPOSITION OF AN ONTOLOGY MODEL FOR FLEET-WIDE SEMANTIC
4.1. Ontology for providing semantic
An ontology determines formal specifications of knowledge in a domain by defining the terms (vocabulary) and relations among them (Gruber, 2009). Ontologies are composed of classes, properties of the classes and instances. These elements are explained as follow: • Classes describe concepts in the domain. In PHM and naval domain, examples of classes are “components” or
“degradation indicator”. Subclasses represent concepts that are more specific than the superclass (mother class). When a superclass has a subclass, it means that they are linked by a subsumption relation, i.e. “is a” relation, allowing a taxonomy to be defined. Hence, a hierarchy of classes is established, from general classes to specific ones.
• Properties are contained in a class definition and describe relationships among the classes. For example, the class component has property called “is monitored by” with the class degradation indicator. The property “is monitored by” link the individuals of the class “component” with the individuals of the class “degradation indicator”.
• Instances are the set of specific individuals of classes. For example, the engine Baudouin 12M26.2P2-002 is a specific individual that is part of the class “component”.
Ontologies seem to be a suitable modeling method to provide common semantic and to query heterogeneous databases. Some of the capabilities provided consist in (Noy and McGuinness, 2001): sharing common understanding of the structure of information among people or software agents, making domain assumptions explicit, defining concepts and knowledge and making domain inferences to obtain non-explicit knowledge.
7
To represent knowledge and to explicit semantic (vocabulary and relations), the ontology is coded in Web Ontology Language (OWL) supported by Protégé1 ontology editor. In that sense, OWL embeds all the features previously mentioned except for the relationships. OWL allows only binary relationships between classes and it distinguishes object-properties (linking objects to objects) from data-properties (linking objects to data values of built-in OWL datatypes). For instance, in our application, a taxonomy is used to represent systems, subsystems and components. In addition, the characteristics of languages such as OWL facilitate the definition of generic conceptualizations that can be used in multiple domains, facilitating the creation of Web-based applications, such as a module of an e-maintenance platform in the PHM domain (Garcia-Crespo et al., 2011).
Moreover, OWL provides inference capabilities with plugged reasoners. OWL reasoners shall performed consistency checking. Hence, one shall guarantee that the ontology has been built correctly in the sense that no syntactic error and inconsistency remain in the ontology. For example, if a fuel-engine is associated to an electrical degradation, an inconsistency will be point out by the reasoner since it is explicitly declared that fuel-engines cannot cause electrical degradation. Also, explicit and manually constructed classes that belong to taxonomy constitute an asserted hierarchy. But thanks to OWL reasoners, an inferred hierarchy is automatically computed allowing to infer new knowledge. For example if an engine has an internal electrical degradation, the ontology can induce that it is an electrical engine.
Another useful service of Protégé ontology editor is the possibility to plug inference rules. Actually when knowledge cannot be formalized with the OWL elements, inference rules can be used. These rules allow the definition of classes by means of, for example, Semantic Web Rule Language (SWRL) or with JENA2 Ontology API. Rules define conditions that are in the antecedent hold and then, the conditions specify in the consequent must also hold. Furthermore, ontologies have been used in the diagnosis domain thanks to their capabilities such as: the reasoner, unifying language facilitating interoperability, and the consistency model checking capabilities. For instance, (Kitamura and Mizoguchi, 1999), used ontologies to characterize diagnostic models and to create a characterization of faults. This way a diagnostic ontology-based system was created allowing to manipulate ontology concepts for the search of deeper causes of a drift. (Benaras et al., 1996), described different elements composing electrical networks with an ontology model in order to perform fault diagnosis. (Melik-Merkumians et al., 2010) proposes to use ontologies for fault diagnosis, since ontologies eases agents interoperation and they provide a knowledge base model that allows representing concepts and relations/associations among them. Through this knowledge formalization capability, it is possible to formalize knowledge for technical units as well as their failure modes and causal chain allowing to perform diagnostics. In (Wang, 2011), ontologies for fault diagnosis of power transformers are used for knowledge exchanging among heterogeneous systems. Through the use of this knowledge formalization model, various transformer diagnostic methods were integrated to describe the relations between fault phenomena, fault sources and causes of faults. Moreover, (Dendani-Hadiby and Tarek Khadir, 2012) combined a fault diagnosis method, case-based reasoning (CBR) with a knowledge model in the form of ontology. The ontology provided the basis for the cases definitions, for the knowledge structure where the cases were located. A semantic reasoning was used for similarity measures among cases. As it have been presented ontologies have been already used in the diagnosis domain for improving knowledge capitalization techniques such as CBR. For these reasons, a PHM ontology is proposed in this article allowing to retrieve feedback records from past experiences on heterogeneous databases and allowing to use the reasoner capabilities to emerge non-explicit knowledge. The proposed approach based on PHM ontology is not a goal itself. This ontology is a support for PHM software applications through the KASEM® software platform3 (Figure 3). For the purpose of the underlying software application, the ontology model is integrated by means of an SQL-backed storage. The java framework JENA allows the manipulation of the ontology stored knowledge and then it uses this knowledge to search individuals (that correspond to the described criteria in the ontology) in the different and distributed databases. The JENA inference engine allows semantic queries and inference rules to be solved within the platform. The information issue from the ontology as well as the occurrences (e.g. individuals) found in the different databases are shown through the KASEM® platform via JENA (Leger, 2004), (Monnin, 2011c). KASEM®
1 http://protege.stanford.edu/ 2 http://jena.sourceforge.net/index.html 3 http://www.predict.fr
8
platform provides the user a web portal that allows benefiting of the fleet-wide knowledge capitalization. Relevant contextual information can be retrieved and gathered for the purpose of, for instance, failure anticipation, investigation or expertise sharing. In the next section, the formalization of an ontology to support PHM activities in the naval domain is proposed.
Storage Manipulation HMI
Off
-Bo
ard
da
ta
wa
reh
ou
se
RDF/OWL
On
tolo
gy
mo
de
l
JENA API
Inference Semantic query
Inference rules
On
tolo
gy
ma
nip
ula
tio
n t
oo
l
Ontology-enhanced
query
Jena Inference
engine (reasoner)
Figure 3: Typical architecture of Fleet-wide PHM system
4.2. Ontology-based PHM knowledge modeling rules
The modeling engineering phase was based taking into account the best practices described by (Noy and McGuinness, 2001) and (Rector et al., 2004). In addition, to illustrate the modeling rules, the examples presented in this section have been taken from the proposed ontology. To build the ontology the following modeling patterns and modeling steps were used:
4.2.1. To define the key concepts of the domain
In our case, the main concepts concern a description of the main characteristics of a fleet. Those concepts are related to the technical characteristics of units, to the monitoring activities that are done to maintain the operational conditions of units and to the factors that influence the normal functioning behavior of a unit. In that sense, these factors were previously identified such as the environment and the mission of the unit.
4.2.2. To define a class hierarchy (Subsumption)
Classes to formalize those concepts were defined. Some best practices rules were used in order to identify whether it was pertinent to create a class or not. In that sense, to create a new class the following criteria have to be checked (Noy and McGuinness, 2001):
- Does the new class integrate any new object property? - Does the new class integrate any new data property? - Does the new class have relations with other classes different to its superclass?
If any of these answers is positive then a new class has to be created. Otherwise it is not worthy to represent the concept as a class, so the concept should be represented as an instance. Hence, in order to define the main classes within a fleet-domain, five first level classes were created as follow:
- Technical context class - Dysfunctional context class - Operational context class - Service context class - Application context class
9
Each of these classes participates in different object properties. For example:
Class: Technical Context EquivalentTo: isExposedTo (object property) some “Operational Context”.
Class: Dysfunctional Context
EquivalentTo: isAssociatedTo (object property) some “Technical Context”
Class: Operational Context EquivalentTo: EvolveAround (object property) some “Technical Context”
Class: Service Context
EquivalentTo: RequiresFunctioningModesof (object property) some “Technical Context”
Class: Application Context EquivalentTo: Monitors (object property) some “Technical Context”and
Monitors some “Dysfunctional Context”
Obviously, each of these object properties are different (in a semantic sense) and, for that reason, these concepts have to be formalized as separate classes in the proposed ontology. In the next section 4.3 we describe in more details these classes.
4.2.3. To describe and define classes
- Disjoint classes
A first step to define a concept is to explicit if a class is “separated” from another class. In other words, one has to determine if classes are disjoint or overlapped. If classes are disjoint, an individual can belong only to one of them. In the proposed ontology the class “Component” is disjoint from the class “Degradation”. This means that an individual cannot be a component and a degradation at the same time. - Primitive or Defined Classes
i. Defined Classes: A defined class is a class that has at least one set of necessary and sufficient conditions. These conditions aim at determining if an individual is a member of the class. If the individual satisfies the conditions, then it is a member of the class. Each set of necessary and sufficient conditions is called “Equivalent Class” (Horridge et al., 2011) (Rector et al., 2004).
Defining classes allows the automatic inference of a class by means of a reasoner. This means that if any individual fulfils a set of necessary and sufficient conditions, the reasoner will:
• add the individual to the class if it is not a member • check if the individual is well classified if it is a member of the class.
In the proposed ontology, defined classes for the taxonomy of engines were specified. For example, a set of necessary and sufficient conditions for the definition of the “4-stroke engine class” is:
Class: 4-stroke Diesel Engine EquivalentTo: hasFunctioningCycleValue some 4-stroke cycle, and
consumes some Diesel.
10
These conditions mean that if any individual participates in a relation with a 4-stroke cycle and that consumes Diesel, then this individual is necessarily a 4-stroke Diesel Engine. ii. Primitive classes: This kind of classes only has necessary conditions but those conditions are not sufficient. Although in this case, the reasoner cannot make inferences from the primitive classes, it can check that conditions are fulfilled for individual.
An example of a primitive class in the ontology is the necessary condition: Class: Electrical Engine
EquivalentTo: isAssociatedTo some “Rotation Speed”
This conditions means that any electrical engine is associated to a property that is the rotation speed. However, if any other individual has a rotation speed it does not mean that it is necessarily an electrical engine. For instance, in this case the individual could be a diesel engine. - Definition of classes by means of Semantic Web Rule Language (SWRL)
SWRL allows the representation of knowledge that cannot be represented in OWL language. By using rules, concepts can be defined. For instance, the definition of the “High Speed Diesel Engine” class (Figure 4) uses a rule specifying that a Diesel Engine having a speed greater than 1000 rpm is a High Speed Diesel Engine.
Figure 4: Example of inference rule for “HighSpeedEngine” class
4.2.4. To define properties of classes
A class is defined by the properties that it contains. As previously mentioned, these properties are of two types: data properties and object properties. a. Object Properties: describe the relations between individuals. Relations are defined at the concept level. An example of an object property in our ontology is given as follow:
Class: Unit EquivalentTo: hasIndicators some “Indicators”
This statement means that the individuals of the class “Unit” are related to the individuals of the class “Indicators” via the object property “hasIndicators”. b. Data Properties: describe the relations between individuals and data values. In the proposed ontology, data properties are used to model the values of the technical features or properties of units. For instance:
Class: Rotation Speed EquivalentTo: hasValue some “Float”
11
This means that the rotation speed, has a value which is a float number. One frequent question that modelers have to face concerning data properties is whether to model a new class or to define a data property. As shown by (Noy and McGuinness, 2001), a best practice is to see if the value of the data property has other relations with other concepts. In our case, the technical features of units do not have other relations with other concepts and for this reason they were modeled as data properties.
4.2.5. To define the value type, the cardinality and the allowed values of classes a. Existential restrictions: describe classes of individuals that participate in at least one relationship along a specified property to individuals that are members of a specified class (Horridge et al., 2011). For example, in the proposed ontology the class of “Units” within the technical context (which integrates ships, sub-systems and components) has at least one “hasDegradationMode” relationship to the members of the class “Degradation Modes”. The representation with Manchester syntax is:
Class: Unit EquivalentTo: hasDegradationMode some “Degradation Modes”
This means that every individual that belongs to the class “Unit” participates in at least one relationship called “hasDegradationMode” with the members of the class “Degradation Modes”. In current English, this means that every unit has at least one degradation mode. b. Universal restrictions: describe classes of individuals that for a given property only have relationships along this property to individuals that are members of a specified class (Horridge et al., 2011). For example, in the proposed ontology the class “Electrical Engines” only has the relationships with the individuals of the class “Electrical Degradation Modes”. The representation with Manchester syntax is:
Class: Electrical Engines
EquivalentTo: hasDegradationMode only “Electrical Degradation Modes”
In Protégé the keyword “only” is used to denote existential restrictions. c. Cardinality restrictions: This type of restrictions describes the class of individuals that have at least, at most or exactly a specified number of relationships with other individuals or with datatype values. For example, in the proposed ontology, the class “4-stroke Diesel Engine” has exactly one functioning Cycle. Its representation with Manchester syntax is:
Class: 4-stroke Diesel Engine EquivalentTo: hasFunctioningCycle exactly 1
4.2.6. To create instances Individuals are also known as instances (Horridge et al., 2011). They are the specific members of classes. When an element needs to be added to the ontology, there are two options: it can be added as a class or as an instance. For example a diesel engine could be represented as a sub-class of the diesel engine class or it can be represented as a particular individual of the class engine. In that sense, a best practice was used is to understand if the concept is the most specific concept that it is possible to be represented (for the purpose of the ontology). This practice suggests analyzing if the concept should have relations with other concepts then it is represented as a class. If not, then the individual should be modeled as an instance. In the proposed ontology an individual might be a specific engine, for instance, Wärstila 12V38 diesel engine. This modeling choice was made since this is the most specific concept that could be represented and also because all the interesting relations that this concept are already defined in the “Diesel Engine Class” (its belonging class).
12
Furthermore, instances could be also modeled to define what is called “Enumerated classes”. This kind of classes is defined by exhaustively listing all the individuals to be considered in the domain that are members of the class (Horridge et al., 2011). In the proposed ontology, some technical features of units were modeled using this pattern. For example: “Type of Injection Class” was modeled as a class that has three individuals: “Direct Injection, Indirect Injection and Common Rail Injection”. These instances do not have any additional relations with other concepts and for this reason, this modeling option was taken. The next section presents part of the ontology model.
4.3 Fleet-wide PHM Ontology
In the section 2. key elements to perform diagnosis were identified. These elements are technical characteristics of the system/sub-system/component, degradation modes, degradation indicators, the mission and the environment. The sources of knowledge for building the ontology were mainly:
- A bibliographical review of standards and of other articles of the PHM community. For example, the influence of the environment and of the mission is referenced in (Peysson et al., 2009).
- Standards used in the PHM community such as the (IEC 60812, 2006). - A 3 years project with several brainstorming sessions with experts on the domain, where knowledge was gathered
and later validated. In that sense, experts from the naval domain (engine experts, ship owner,…) and experts from the PHM/ Maintenance domain collaborated with us for the knowledge identification/formalization. This community of experts belonged to the same organization and the same country.
A semantic model that formalizes these pieces of knowledge is provided in order to define “similarities” among units. Based on (Medina-Oliva et al., 2012), (Monnin et al., 2011a) several contexts are defined: a technical context (e.g. characteristics of the system/sub-system/component), a dysfunctional context (e.g. degradation modes), an operational context (e.g. mission and environment), a service context (e.g. usage of units) and an application context (e.g. degradation indicators). For a graphical representation of the ontology for these contexts, classes are represented as ovals, subsumptions relations are represented as full lines and properties are represented as dashed lines linking classes. Once the ontology model is formalized, comparisons of heterogeneous units shall be performed on the basis of context similarity.
4.3.1 Technical context
One might think that the definition of every model of component could be enough to take advantage of the fleet dimension. But if the expert seeks strictly identical units, then this modeling choice could narrows the results too much (i.e. just identical units) limiting the manipulation of the fleet dimension. For this reason, a technical context is proposed. The technical context integrates the technical features and characteristics of the system/sub-system/component (Figure 5).
Ship Installation
Unit
Component
Figure 5: Taxonomy of units
To model the technical context, “Component” (Figure 6) classes are specified as well as “Properties” classes which define all their features (Figure 7). Hence, units with similar technical properties could be clustered according to their technical
13
properties such as the output power, the rotation speed, the number of cylinders, etc. (Figure 7) in order to retrieve data/information.
DieselEngine GasEngine
Engine Pump
Component
Propeller
Controllable
PitchPropeller
Azimuth
Thruster
Figure 6: Part of the component taxonomy
DieselEngine
Properties
Specific oil
consumptionMaximum fuel
consumption
Operating
pressureCompression
ratio Specific fuel
consumption
Output
Power
Torque
Piston
speed
Type of
fuel
Rotational
speed
Number of
cylinders
Configuration
Cooling system
Type of injection
system
Aspiration
system
Figure 7: Part of the component properties taxonomy
Furthermore, other taxonomies for higher abstraction levels are formalized such as the taxonomy for the installations (sub-system) (Figure 8) and for ships.
Power
Generation
Linked to the
propulsion
installation
Power
Distribution
Single-
propeller
Electricity
generation
Propulsion
installation
Installation
Stem
propulsion
Autonomous
power
generation
Leading
propulsion
Double-
propeller
Triple-
propeller
Power
Management
Gas TurbineFuel
Alternator
Figure 8: Part of the installation taxonomy
This model allows the comparison of heterogeneous units for instance when seeking relevant characteristics such as “4-strokes engines” or “direct injection engines”.
4.3.2. Dysfunctional context
The dysfunctional context takes into account the information about the degradation modes on the units. It considers the generic degradation modes. Generic degradation modes are taken from the standard (IEC 60812, 2006). Classes include electrical degradation modes, mechanical degradation modes, hydraulic degradation modes, etc. Degradation modes are linked to units (Figure 9).
14
Furthermore, in this context, as in fault tree analysis, one degradation mode might be caused by another degradation mode until primary causes are found. In that sense, this context allows to describe information about the causality chain of degradation modes that produced an undesirable event. This knowledge is very valuable to retrieve information/data for troubleshooting and diagnosis issues. This modeling choice allows to explore the main causes of similar degradation modes. For example to explore common causes of pumps failures regardless of the use of the pumps.
Degradation
Modes
Mechanical
degradation
modes
Vibration
Component
brokeGalling
Component
blocking
Electromechanical
degradation modes
Hydraulic/Pneumatic
degradation modes
Impact/isImpactedbyUnit
Equipment
Installation
Ship
Short
Circuit
Faulty
input signal
Opened
circuit
Faulty
output signal
Blocked
circuit
Leak
Faulty seals
Cause/isCausedby
Figure 9: Part of the dysfunctional analysis on units
Operational
conditions
EnvironmentMission
Port of call Waiting Port Road
On-Water
Chemical
composition
of water
pH
ChloridesSalinity
Sulfates
Atmospheric
pressure
Water
turbulence
Weather
conditions
On-Air
Figure 10: Part of the operational context taxonomy
4.3.3. Operational context
Even if units are identical, the operational conditions lead to different units’ behaviors. For this reason, one could need to cluster information/data according the operational and service contexts. The operational context integrates the operational conditions to which the units are exposed to. As explained in section 2, for performing diagnosis, the Mission (M) and the Environment (E) have to be considered. The operational conditions are given by the mission to be performed by units as well as the environment they evolved in (Figure 10). In the naval domain, the mission is a sequence of dated tasks in a geographical area (e.g. Port of call mission) (Peysson et al., 2009). Hence, similar missions on similar units could be compared (Figure 10). On the other side, the environment takes into account the weather conditions, the chemical composition of water (pH, salinity…), the pressure, water turbulence, etc. (Figure 10) which might impact degradation mechanisms and units’ functioning behavior.
15
The mission and the environment could affect component, sub-system and system performances and behavior. For this reason the mission was formalized at different abstraction levels (system, sub-system, component).
4.3.4. Service context
The service context deals with the usage of units. Even when units are similar they are exposed to different usages according to the corresponding mission tasks. In that sense, for every mission, different operating modes could be required in order to accomplish it. For instance, for a specific mission the engine could work a percentage of its time in a stabilized condition then it might need to be stopped for another part of the time, and so on. The different operating modes affect the evolution of the degradation modes. Hence a service context is formalized in order to differentiate behaviors of the degradation indicators evolution . In that sense, usage could be divided according to the operating steps, operating phases and the configuration of units (Figure 11). Moreover, degradation behavior can be analyzed according to different abstraction levels.
Operation
modes
Operating
steps
Stop
TransitionalStart
Stabilized
Operating phases
Stop MaintenanceOperationNon-
Stabilized
ScheduledNon-
Scheduled
Preventive
Maintenance
Corrective
Maintenance
Configuration
of units
Spare unitLeading
unit
Figure 11: Part of the service context taxonomy
4.3.5. Application context
The application context is related to the needs of PHM management. The PHM management aims the capitalization of knowledge to perform health assessment. Health assessment deals with the definition of indicators such as functional, dysfunctional and environmental indicators at different levels as well as the data processing of these indicators. Hence, the application context includes health assessment concept and relation with other previously defined domain contexts. (Figure 12). This context enables data/model retrieval of the monitored unit with its corresponding context defined in the ontology. The ontology-based knowledge formalization provides the basis to capitalize knowledge with contextual information. In that sense, one might define similar units, i.e. high-speed engines, with similar missions and under similar context in order to compare signal evolution of indicators.
16
Equipment
hasIndicators/refersToEquipment
Installation
hasIndicators/refersToInstallation
Ship
hasIndicators/refersToShip
Health
Condition
Equipment
Indicator
Installation
Indicator
Ship
Indicator
Environmental
Indicator
Dysfunctional
Indicator
Functional
Indicator
Environmental
Indicator
Dysfunctional
Indicator
Functional
Indicator
Environmental
Indicator
Dysfunctional
Indicator
Functional
Indicator
IsComposedby/compose
IsComposedby/compose
Processing
isComputedBy/computes
isComputedBy/computes
isComputedBy/computes
Figure 12: Part of the application context
4.3.6. Relations between the different contexts
The ontology encodes knowledge about the relations among the various concepts. These relations allow to guide the query of the expert about the causes of the abnormal behavior. For example, the expert (e.g. maintenance engineer) might want to investigate the evolution of some indicators (Application Context). Then, the ontology encodes knowledge about the degradation modes (Dysfunctional Context) that are monitored with a given indicator (Figure 13). Indicators are also linked to units (Technical Context). Moreover, units are exposed to an environment (Operational Context) and they are also exposed to different operation modes (Service Context). Thus the software application developed allows to guide the expert to enable the identification of a degradation mode linked to an indicator and linked to one unit (e.g. component) with a given environment for example. This way, knowledge is encoded in the ontology and the expert can use it to see which criteria are more appropriated to choose in order to retrieve similar cases to perform diagnosis. The proposed approach aims at dealing with a general description of a domain and not with a particular individual. In that sense, individuals/particular cases are not treated in the ontology but remains stored in the databases. To deal/solve a particular case, we use the general descriptions done through the ontology concepts. The user describes the particular situation with the general domain knowledge-base. Moreover, the ontology is enriched when a particular case is recurrent and solved. Thus, the enrichment of the ontology could consist in adding new concepts. This aspect should be dealt by the experts. The ontology is dedicated to be used by a group of experts belonging to the same organization. Hence they share the same concepts and vocabulary since they are used to work in cooperation. Moreover building the ontology is a step forward in the homogeneity of the concepts and vocabulary sharing.
17
Technical
context
Dysfunctional
context
Operational
context
Service
context
Application
context
Unit
Degradation
Mode
hasDegradationModes/isAssociatedtoUnit
Environment
Operation
modes
Indicator
monitorsDegradationModes/isMonitoredbyIndicators
isExposedtoEnvironment/evolveAroundUnit
characterizesEnvironment/isCharacterizedbyIndicator
isExposedtoOperationMode/requiresUnitPerformances
hasIndicators/refersToUnit
Figure 13: Part of the ontology showing the relations between contexts
The next section illustrates the benefits of the proposed methodology within the PHM context.
5. PHM EXPERIENCES RETRIEVAL FROM FLEETS COMPOSED OF HETEROGENEOUS UNITS
The fleet-wide approach could be used for several PHM activities, such as for diagnosis, prognosis, health assessment or for engineering analyses for example. To gather data and knowledge for all these applications the iterative investigation process explained in (Figure 1) can be adapted for these purposes.
In every application, from a specific case (e.g. prognostic for a new component or to a new detection algorithm), the characteristics of a sub-fleet have to be defined. These characteristics are based on the defined contexts (Figure 1-A). According to this characterization, a population is defined within the fleet (Figure 1-B). Then, the potential similar events are investigated (Figure 1-C). According to the application, these events may be different; for instance for prognostic one might be interested in collecting the degradation trajectories for building a new one based on the past experiences (Voisin et al., 2013), for engineering one might be interested in a collection of different detection algorithms in order to apply them to a new unit and so on. Finally, the studied situation benefits from past experiences for PHM purposes (Figure 1-D).
To illustrate the feasibility of the proposed approach as well as the added-value, a scenario was developed. This scenario shows how the fleet-wide approach is useful for experts during the decision making process for diagnosis purposes. We consider the diagnosis of a Wärstila 12V38 diesel engine. This engine is a 12-cylinder engine with V-configuration of cylinders and is a medium-speed engine.
This engine presents two symptoms:
• Lower oil pressure inlet of the engine • Higher oil temperature.
When making the statistical analysis about the degradations causing these symptoms, one can notice that there is a problem in the lubrication system of the engine. Hence, the entire set of root causes of the symptoms is required in order to make a decision. Usually, experts are only able to deliver a subset of root causes. Moreover, expert cannot provide objective evidence on the final choice of the root cause (s). Hence, the objective is to help an expert to extract/retrieve data coming from the fleet in order to solve the diagnostic of this situation. In that sense, the expert should identify what are the most probable root-causes of degradation in the lubrication system (Figure 14).
18
Figure 14. Causality tree about the possible causes of degradation of the lubrication system
To find the root-causes, the application in interaction with the expert allows to perform a statistical analysis based on the capitalized past experiences within the fleet.
To illustrate the advantage to consider more or less similar units as well as to show the ability of the fleet dimension to tackle this issue, three cases are considered:
1. Consideration of identical fuel engines to the Wärstila 12V38 diesel engine
2. Consideration of all fuel engines composing the fleet
3. Consideration of the heterogeneous units composing the fleet using the ontology-based approach
For the purpose of this example, the fleet is limited to diesel engines. Seventeen diesel engines located in five ships (Figure 15) are considered and briefly presented in Table 1. The table shows an extract of the technical features of the engines.
1. Consideration of identical fuel engines to the Wärstila 12V38 diesel engine
The first step to extract data from the fleet dimension is to consider identical units to Wärstila 12V38 diesel engine. Nevertheless, if one considers purely the same kind of units with the same symptoms and working in a propulsion installation as well, then only the studied unit matches to the results as shown in Table 2. The databases does not include enough historical data for performing an investigation about the causes of failure in the lubrication system.
For this reason, other approaches have to be investigated.
2. Consideration of all fuel engines composing the fleet
Another approach to take advantage of the fleet dimension is to consider all the fuel engines in the fleet. In that sense, the expert has the possibility to make a query in the proposed application (ontology-based application) about the past events that produced a degradation on the lubrication system for all fuel engines. Then, instances are searched, based on the criteria
19
selected by the expert (in this case, all the fuel engines), among all the databases that compose the fleet. The statistic results of this query are shown in the Figure 16. The statistics shows a higher preference regarding the bearings wear cause.
DatabaseShip 1
Engine Ref TotalWärtsilä 12V38 1Wärtsilä 12V38 1
Wärtsilä RT-flex50 1
Engine Ref Total
Wärtsilä 16V38 2
Wärtsilä 9L38 1
Wärtsilä 8L38 1
Engine Ref TotalVolvo Penta D16C –
AMG 2
ABC 12VDZC 2
Engine Ref Total
Wärtsilä RT-FLEX82T 1
Baudouin 12M26P1FR 2
Engine Ref TotalBaudouin 12M26P1FR 1
Wärtsilä 16V38 1Wärtsilä RT-flex50 1
DatabaseShip 2
DatabaseShip 3
DatabaseShip 4
DatabaseShip 5
Figure 15. Ships, engines and databases that composed the fleet
Table 1. Extract of engine fleet technical features stored in the databases
Engine RefOutput power
(kW)Nb. of
CylinderConfiguratio
nEngine
Speed (rpm)
Tag related to the
ontology
Engine cycle
Injection InstallationTotal
number ofengines
Wärtsilä 12V38 8700 12 V 600 Fuel engine 4 DirectPropulsion installation 2
Wärtsilä RT-flex50 13 960 8 L 124 Fuel oil 2 DirectPropulsion installation 2
Wärtsilä RT-FLEX82T 40 680 9 L 80 Fuel oil 2 DirectPropulsion installation 1
Baudouin 12M26P1FR 357,94 12 V 1800 Fuel engine 4 DirectPower generation
installation 3
Wärtsilä 16V38 11600 16 V 600 Fuel engine 4 DirectPropulsion installation 3
Wärtsilä 9L38 6525 9 L 600 Fuel engine 4 DirectPropulsion installation 1
Wärtsilä 8L38 5800 8 L 600 Fuel engine 4 DirectPropulsion installation 1
Volvo Penta D16C – AMG 470 6 L 1 800 Fuel engine 4 DirectPower generation
installation 2
ABC 12VDZC 2652 12 V 1000 Fuel engine 4 DirectPropulsion installation 2
17 Table 2. Result of the identical fuel engines query
20
Symptoms
Engine RefOutput power
(kW)Nb. of
CylinderConfigurati
on
EngineSpeed (rpm)
Tag related to
the ontology
Enginecycle Injection
InstallationTotal
number ofengines
Lower pressure of
the input oil of the engine
Higher oil temperature
Wärtsilä 12V38 8700 12 V 600 Fuel engine 4 DirectPropulsion installation 1 X X
0
5
10
15
20
25
30
Leak in the
lubrication circuit
Damaged oil pump Wear of the
bearings
Damaged in the
regulation
components (check
valve...)
Nu
mb
er
of
fail
ure
s
Statistics considering all the engines composing the
fleet about the possible causes of degradation in
the lubrication system
Figure 16. Statistics considering all the engines composing the fleet about the possible causes of the degradation on the
lubrication system However, from the expert point of view, the fleet is composed of a wide variety of different engines and the causes of a symptom might be slightly different according to the refined type of fuel engine. If one take a look to Table 1, it is possible to notice that the fleet is composed of big size, high power, two-stroke engines such as the Wärtsilä RT-FLEX82T engine and of other engines with lower output power and four-stroke cycles such as the Wärtsilä 12V38 engine. These units are very different and thus their degradation behaviors are very different as well. For this reason considering all the fuel engines might not be appropriated to study the degradation behavior of the Wärtsilä 12V38 engine. 3. Consideration of the heterogeneous units composing the fleet using the ontology-based approach
As mentioned previously, the developed application based on ontologies guides the definition of “similar characteristics” in order to define the sub-fleet of units to be used for diagnostic purposes (Figure 1-A). The resulting fleet contains units close enough to perform a relevant statistical analysis but not purely identical. To guide the sub-fleet definition some questions will be asked, automatically by the application, based on the relations between the different contexts defined in the ontology. One question concerns the application context, if one seeks a diagnosis, a prognostic model or an engineering model. For this example, a diagnosis is performed. Then another question deals with the technical context. The application poses questions about the type of unit (i.e. engine, thruster, pump…), the application domain (i.e. marine, land, aeronautics, etc.) and the subsystem (i.e. propulsion and power generation). As mentioned previously, for this example, an engine located on a ship for propulsion purposes is sought.
In the ontology the definition and relations of diagnosis have been established. For example, the relations between diagnosis and the operational conditions or the dysfunctional modes are explicit. For this reason, another question is asked about the mission and the environment of the engine (operational context). The mission in this example is a costal surveillance mission (Figure 1-B). After the relevant criteria embedded in the ontology have been selected by the expert, a query of the distributed databases can be performed in order to look at the results of the defined sub-fleet (Figure 1-C).
In that sense, the proposed approach aims at helping the expert in the research of similar cases among a heterogeneous fleet of engines that allows the identification of the root-causes.
21
Additionally, in the technical and dysfunctional contexts the semantic model embeds knowledge about the degradation modes and the properties of units. To search the causes of the degradation the proposed ontology-based application guides the user and proposes different criteria such as the properties or technical features of units. Since there is a degradation on the lubrication system, the embedded knowledge in the ontology provide information to the expert about the two types of lubrication systems: for the two-stroke engines and for four-stroke engines (Figure 17). These two lubrication systems are technologically different and thus their functioning and dysfunctioning behaviors are also different. For this reason it is interesting to integrate this criterion in the query.
Lubrication system
of engines
Lubrication system of
4-stroke enginesLubrication system of
2-stroke engines
Figure 17. Classification of the lubrication system of diesel engines
This kind of cluster could be relevant for the user since these criteria allows the definition of common and similar characteristics of engines behavior even though they are not identical. This way the user can perform a query including a restriction that is the 4-stroke engines (since the Wärtsilä 12V38 engine is a 4-stroke engine). This query is specified in the ontology application and instances that correspond to the selected criteria are searched in the different databases composing the fleet. The statistical results of the query are shown in Figure 18. The figure shows that the bearings wear is in fact the most probable cause of the degradation of the lubrication system on 4-stroke engines. This type of comparisons is more reliable since one can expect similar behaviors from similar units. Moreover, even if the cause is the same as in the previous case, its relevancy is higher since the associated statistics is of 43% instead of 36% in the previous case.
0
10
20
30
Leak in the
lubrication circuit
Damaged oil pump Wear of the bearings Damaged in the
regulation
components (check
valve...)
Nu
mb
er o
f fa
ilu
re
s
Statistics considering 4-stroke engines composing the
fleet about the possible causes of degradation in the
lubrication system
Figure 18. Statistics considering 4-stroke engines composing the fleet about the possible causes of the degradation on the
lubrication system In order to find the root-causes the expert can then continue to search the past events in order to identify the most probable causes of bearings wear (Figure 19).
22
Figure 19. Causality tree about the possible causes of wear in the bearings
Once the query is executed, the statistics about the causes are shown as in Figure 20. With this analysis it is possible to notice that the vibrations are the most probable cause of wear of bearings. Then the user can continue a deeper investigation about the possible causes of vibrations (Figure 20).
0
2
4
6
8
10
12
Defective material
or dimensions
Faulty bearing-
mounting
Problems with
bearing
lubrication
Service conditions
(over-speed, over-
charge…)
Vibrations
Nu
mb
er o
f fa
ilu
re
s
Statistics considering 4-stroke engines composing the
fleet about the possible causes of wear of bearings
Figure 20. Statistics considering 4-stroke engines composing the fleet about the possible causes of wear of bearings.
23
Figure 21. Causality tree about the possible causes of vibrations
Once again the semantic model embeds a link between degradation modes and the properties or technical features of engines. To search the causes of vibrations, the application proposes the expert different properties of engines. One of these properties is the rotation speed of engines. As a matter of fact, this property has an impact on the evolution of vibrations. For this reason it is interesting to integrate it in the query. The Wärtsilä 12V38 engine is a “medium-speed engines” (i.e. 300 - 1000 rpm) (this class was defined by means of the SWRL, as shown in section 4.2.3. for the high-speed engines). With this information now the expert can search the engines that present a similar degradation behavior (Figure 22).
Diesel
engines
High-speed
engines
Medium-
speed
engines
Slow-speed
engines
Figure 22. Classification of engines according their rotation speed Hence the new restrictions in the search space leads to search for the 4-stroke engines and the medium-speed engines. One might notice that if statistics were performed only on 4-stroke engines, the most probable cause would have been the degradation on the damper. However, when taking into account a more coherent and relevant property of engines (rotation speed) concerning the studied degradation (vibrations), a more pertinent cause can be identified for this situation (Figure 23). The result shows that the misalignment was of the most probable root-cause of degradation.
24
0
1
2
3
4
Degradation
on the
suspension
Degradation
of the engine
damper
Problems with
fuel-injection
system
Misalignment Inadequate
wedge
Nu
mb
er
of
fail
ure
s
Statistics considering 4-stroke medium-speed
engines composing the fleet about the possible
causes of vibrations
Figure 23. Statistics considering 4-stroke medium-speed engines composing the fleet about the possible causes of vibrations
This type of approach allows to retrieve a higher amount of and more relevant feedback data from heterogeneous diesel engines of the fleet. Moreover, the ontology allows to query the 5-ship databases in the fleet with only one query. The knowledge embedded in the ontology shows potential key criteria of similarity between units to solve a diagnostic situation. In this respect, from a particular case the user can browse the embedded knowledge base and generalize the description of the situation with the corresponding units of the fleet. The pertinent criteria could be thus identified and selected to analyze a given situation.
This way, a higher volume of data, as well as more relevant, becomes available and feedback experiences can be reused. Thus wider types of experiences can be found and analyzed from the fleet. Hence, the expert can perform a diagnostic guided by a semantic model that embeds useful knowledge about the marine domain and that allows the capitalization of data/knowledge within a fleet composed of heterogeneous units.
Furthermore, at the current stage the validity of results depends on the user/expert pertinent criteria selection. Additional features could be integrated to the application to provide more information about the relevance of the criteria selection.
6. CONCLUSIONS AND PERSPECTIVES
Fleet-wide PHM requires knowledge-based system that is able to handle contextual information. Diagnosis and maintenance decision making processes are improved by means of semantic modeling that deals with concepts definition and description. In this paper, a knowledge model based on ontologies is proposed. Contextual information is structured by means of specific contexts. These contexts allow to consider similarities and heterogeneities of unit within a fleet. Data of the monitored unit are considered within their context enhancing the analysis of contextualized data which facilitates the diagnostic task.
The proposed methodology allows the improvement of diagnosis thanks to the following features:
• Broaden the searched knowledge with the capitalized knowledge/data of the fleet since heterogeneous units are considered.
• Only relevant (regarding the context) information is provided to maintenance engineers, since contextual knowledge reduces the search space of solution.
• Iterative search for enlarging or restricting the solution space according the response of the query.
• Guided search through the automatic proposition of relevant search criteria.
The fleet knowledge model has been structured for a marine application. The resulting ontology has been integrated in the KASEM® industrial PHM platform. The ontology formalizes knowledge for all PHM process and naval domain in the form of sub-ontologies for several contexts. The contexts include the technical characteristics representation of units, the
25
degradation modes, the operational context of units with a specific focus on the naval domain, the usage of units, the environment and the associated indicators for health assessment. Moreover, this global ontology integrates also relations between each of the specified contexts. The ontology may not integrate all the concepts considering all the recurrent cases. In that sense, an improvement and enrichment cycle for integrating new concepts and new instances in the ontology should be considered. Also, the proposed approach could be customized to other domains. To do it, the following considerations should be taken into account:
1. The main effort to customize the ontology would concern the development of the technical context concepts since they are naval domain oriented. Eventually it would be possible to reuse some parts of the existing technical concepts adapted to a new domain. 2. To customize (not to re-develop) the other contexts (dysfunctional, operational, service, application) to integrate domain specific knowledge to other sub-parts of the ontology. For example, to adapt the ontology to the wind-turbine domain, the degradation concepts of the ontology should be added with new electrical degradations. 3. To integrate the relation between the concepts of different contexts. For example, the links between a wind turbine associated to electrical degradations.
As the ontology is customized for different domains, the effort to adapt it to other domain would be reduced since:
- The domain specific part will benefit of larger concept reuse from other domains - The coverage of other contexts (dysfunctional, operational, service, application) will be higher requiring less and
less the integration of new concepts.
Nevertheless, it will be required to make the same efforts to integrate the relation between the different concepts of the contexts.
Some experimentation has already been done (Medina-Oliva et al., 2013a). However, further experimentations have to be conducted to show the feasibility and the added value of this methodology. Moreover embedded knowledge could be refined while implementing this solution to different industrial systems.
Finally, this paper arises some perspectives related to the manipulation of the uncertainty on the generated hypothesis (Petch, 2008). In the presented approach we are focusing on the precision of probabilities (e.g. uncertainties). Usually, probabilities are considered as known perfectly (all the information on the behavior of a system and its component is available). However we are aware that this condition is rarely fulfilled (Utkin and Coolen, 2007). Different sources of uncertainty are presented in the condition-monitoring processes such as: sensors functioning, incomplete models, comparison among heterogeneous units, and granularity of the information representation… For this reason, the problem of imprecision of probabilities (uncertainties) is considered as one of the future work direction, since it should be treated either with probabilities densities, belief functions, fuzzy number, confidence intervals, etc. (Simon and Weber, 2009). Another perspective is to analyze the similarity of signals coming from the characterization of a situation (Liu et al., 2007) and (Wang et al., 2012). The similarity would allow to gather more relevant data to be analyzed to solve the treated situation.
Finally, at the current stage, the retrieval of feedback cases depends on the expert/user selection of pertinent criteria. Additional features could be integrated to the application to provide more information about the pertinence of the criteria selection. For example, similarity measures between concepts can be provided for the retrieved cases. This way the expert could have more information to select relevant criteria. Semantic similarity is related to the common and different characteristics between concepts (Pesquita et al., 2009), (Rada et al., 1989), (Resnik, 1995), (Seco et al., 2004) and (Assali et al., 2009).
26
ACKNOWLEDGEMENTS
The authors wish to express their gratitude to the Directions Générale de la Compétitivité de l'Industrie et des Services (DGCIS) and territorial collectivity for the financial support of the 'Bilan pour la Maintenance et la Conduite Intelligente des Navires' (BMCI) project.
REFERENCES
Alsyouf, I. (2007). The role of maintenance in improving companies’ productivity and profitability. International Journal of
Production Economics, 105, 70–78. Assali, A. A., Lenne, D., and Debray, B. (2009). Case Retrieval in Ontology - Based CBR Systems. In: KI 2009: Advances in
Artificial Intelligence Lecture Notes in Computer Science Volume 5803, 2009, pp 564-571 Azam M., Tu F. and Pattipati, K. R. (2002) “Condition Based Predictive Maintenance of Industrial Power Systems”, SPIE
conference on Fault Diagnosis, Prognosis and System Health Management, Orlando, April 2002. Barros A., Bérenguer C., Grall A. (2009). A maintenance policy for two-unit parallel systems based on imperfect monitoring
information. Reliability Engineering and System Safety 91 (2006) 131–136. Bernaras A., Laresgoiti I., Bartolome N., Corera J. (1996). An ontology for fault diagnosis in electrical networks.
Proceedings of the International Conference on Intelligent Systems Applications to Power Systems, (ISAP '96). pp:199 – 203 Feb. 1996
Bonissone, P.P., Varma, A. (2005). Predicting the Best Unit within a Fleet: Prognostics Capabilities Enabled by Peer Learning, Fuzzy Similarity, and Evolutionary Design Process. In Proceedings of the 14th IEEE International Conference on Fuzzy Systems, IEEE, pp. 312-318.
Cinar D., Kayakutlu G. (2010). Scenario analysis using Bayesian networks: A case study in energy sector. Knowledge-Based Systems, vol. 23, p. 267-276.
Dendani-Hadiby J. and Tarek Khadir M., (2012). A Case based Reasoning System based on Domain Ontology for Fault Diagnosis of Steam Turbines. International Conference on Machine and Web Intelligence (ICMWI). Vol. 5, No. 3.
Dou D., Yang J., Liu J. and Zhao Y. (2012). A rule-based intelligent method for fault diagnosis of rotating machinery. Knowledge-Based Systems, vol 36, Pages 1–8.
Garcia-Crespo, A., Ruiz-Mezcua, B., Lopez-Cuadrado, J.L., Gonzalez-Carrasco, I. (2011) Semantic model for knowledge representation in e-business, Knowledge-Based Systems, vol. 24, pp. 282–296.
Gruber, T. (2009), Ontology. In: the Encyclopedia of Database Systems, Ling Liu and M. Tamer Özsu (Eds.), Springer-Verlag.
Horridge M., Knublauch H., Rector A., Stevens R., Wroe C., Jupp S., Moulton G., Drummond N., Brandt S. (2011). A Practical Guide To Building OWL Ontologies. Using Protégé 4 and CO-ODE Tools Edition 1.3 , Tech. rep., The University Of Manchester and Stanford University, http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/resources/ProtegeOWLTutorialP4_v1_3.pdf.
IEC 60812. Analysis techniques for system reliability – Procedure for failure mode and effects analysis (FMEA). 2006 ISO 13381-1:2004. Condition monitoring and diagnostics of machines- Prognostics- Part 1: General guidelines Iung, B., Levrat, E., Crespo Marquez, A. and Erbe, H. (2009). Conceptual framework for e-Maintenance : illustration by e-
Maintenance technologies and platforms, Annual Reviews in Control, PP. 220-229. Kitamura Y. and Mizoguchi R. (1999). An Ontological Analysis of Fault Process and Category of Faults. Proc. of Tenth
International Workshop on Principles of Diagnosis (DX-99), pp.118-128, June 8-11 1999. Kleindorfer PR, Singhal K, Van Wassenhove LN. (2005). Sustainable operations management. Production and Operations
Management; winter, 14(4):482–492. Léger J-B. (2004). A case study of remote diagnosis and e-maintenance information system, Keynote speech of IMS’2004,
International Conference on Intelligent Maintenance Systems, Arles, France. Lei, Y. G., He, Z. J., & Zi, Y. Y. (2008). A new approach to intelligent fault diagnosis of rotating machinery. Expert Systems
with Applications, 35, 1593–1600 Liu J., Djurdjanovic D., Ni J., Casoetto N., Lee J. (2007). Similarity based method for manufacturing process performance
prediction and diagnosis. Computer in Industry 58, Pages 558-566. Lord PW, Stevens RD, Brass A, Goble CA. (2003). Investigating semantic similarity measures across the Gene Ontology:
The relationship between sequence and annotation. Bioinformatics 19: 1275–1283. Medina-Oliva G., Voisin A., Monnin M., Kosayyer N., Leger JB. (2013a). A case study for fleet-wide semantic based
predictive diagnostic. ESREL 2013 Conference. Amsterdam, The Netherlands. Medina-Oliva G., Voisin A., Monnin M., Peysson F., Leger JB. (2012a). Prognostics Assessment Using Fleet-wide
Ontology. PHM Conference 2012, Minneapolis, Minnesota, USA.
27
Medina-Oliva G., Weber P., Levrat E., Iung B. (2013b). PRM-based patterns for knowledge formalisation of industrial systems to support maintenance strategies assessment. Reliability Engineering & System Safety. Volume 116, Pages 38–56.
Melik-Merkumians, M., Zoitl, A., Moser, T. (2010). Ontology-based fault diagnosis for industrial control applications. In: 15th IEEE International Conference on Emerging Techonologies and Factory Automation.
Monnin M., Abichou B., Voisin A., Mozzati C. (2011b). Fleet historical cases for predictive maintenance. The International Conference Surveillance 6. October 25-26. Compiègne, France.
Monnin M., Voisin A., Leger JB., Iung B. (2011a). Fleet-wide health management architecture. Annual Conference of the Prognostics and Health Management Society. Montreal, Quebec, Canada.
Monnin, M, Leger, J-B., Morel, D. (2011c). KASEM®: e-Maintenance SOA Platform, in Proceedings of 24th International Congress on Condition Monitoring and Diagnostics Engineering Management, 29th May – 1st June, Stavanger, Norway.
Moss, L., Sleeman, D., Sim, M., Booth, M., Daniel, M., Donaldson, L., Gilhooly, C., Hughes, M., Kinsella, J. (2010). Ontology-Driven Hypothesis Generation to Explain Anomalous Patient Responses to Treatment. Knowledge-Based Systems, vol 23: 309-315.
Muller A., Suhner M-C., Iung B. (2008). Formalisation of a new prognosis model for supporting proactive maintenance implementation on industrial system. Reliability Engineering and System Safety. 93(2) 234-253.
Noy N. F. and McGuinness D. L. (2001). Ontology development 101: A guide to creating your first ontology. Technical Report SMI-2001-0880, Stanford Medical Informatics.
Özturk, P. and Aamodt, A.(1997). Towards a model of context for case-based diagnostic problem solving. In Context-97; Proceedings of the interdisciplinary conference on modeling and using context. Rio de Janeiro, February 1997. pp 198-208.
Partridge, C. (2002). The Role of Ontology in Integrating Semantically Heterogeneous Databases. Technical Report 05/02, LADSEB-CNR Padova, Italy, June
Patrick, R., Smith, M J., Byington, C S., Vachtsevanos, G J., Tom, K., Ly, C. (2010). Integrated Software Platform for Fleet Data Analysis, Enhanced Diagnostics, and Safe Transition to Prognostics for Helicopter Component CBM, in Proceedings of Annual Conference of the Prognostics and Health Management Society, October 10-16, Portland, Oregon.
Pecht, M. (2010). A prognostics and health management roadmap for information and electronics-rich systems, IEICE Fundamentals Review, vol. 3, no. 4, pp. 25 – 32.
Pesquita C, Faria D, Falcao A. O, Lord P, Couto F. M (2009) Semantic similarity in biomedical ontologies. PLoS Comput Biol 5: e1000443.
Peysson F, Ouladsine M, Outbib R, Leger JB, Myx O, Allemand C (2009). "A generic prognostics methodology using damage trajectory models." IEEE Trans. Reliab., 58(2) (277 - 285), June.
Peysson F., Léger J-B., Allemand C., Ouladsine M., Iung B. (2012) New approaches for ships fleet-wide management and naval mission prognostics. MFTP 2012: The Prognostics and Health Management Solutions Conference. April 24-26. Dayton, Ohio, USA.
Provan, G., (2003). Prognosis and Condition-Based Monitoring: an open systems architecture. 5th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes, 57--62, Washington, USA.
Rajkumar and Bardina (2003). Training data requirement for a neural network to predict aerodynamic coefficients. Proceedings of SPIE.
Rector A. Drummond N., Horridge M., Rogers J., Knublauch H., Stevens R., Wang H., Wroe C. (2004). OWL Pizzas: Practical Experience of Teaching OWL-DL: Common Errors & Common Patterns. In EKAW, pages 63-81.
Resnik P. (1995). Using information content to evaluate similarity in a taxonomy, In Proceedings of the 14th joint conference in Artificial Intelligence.
Reymonet, A., Thomas, J., Aussenac-Gilles, N. (2009). Ontology Based Information Retrieval: an application to automotive diagnosis, in Proceedings of International Workshop on Principles of Diagnosis, June 14-17, Stockholm, Sweden, pp. 9-14.
Richardson R., Smeaton A.F. (1995). Using WordNet in a Knowledge-Based Approach to Information Retrieval, Working Paper, CA-0395, School of Computer Applications, Dublin City University, Ireland.
Seco N, Veale T, Hayes J. (2004). An intrinsic information content metric for semantic similarity in wordnet. ECAI. pp. 1089–1090.
Sheth, A. (1999). Changing Focus on Interoperability in Information Systems: From system, syntax, structure to semantics. Interoperating Geographic Information Systems, C. Kottman, Editor. Kluwer Academic Publishers: Boston.
Simon C. and Weber P. (2009). Evidential networks for reliability analysis and performance evaluation of systems with imprecise knowledge. IEEE Transactions on Reliability, vol. 58(1), pp. 69–87.
28
Umiliacchi, P., Lane, D., Romano, F. (2011). Predictive Maintenance of railway subsystems using an Ontology based modelling approach, in Proceedings of 9th world Conference on Railway Research, May 22-26, Lille, France.
Utkin L. and Coolen F. (2007) New metaheuristics, neural & fuzzy techniques in reliability, ser. Computational intelligence in reliability engineering. G. Levitin, 2007, vol. 2, ch. Imprecise reliability: An introductory overview, pp. Chapter 10, pp. 261–306
Verma, A. K. and Srividya, A. and Ramesh, P. (2010). A systemic approach to integrated E-maintenance of large engineering plants, International Journal of Automation and Computing, vol. 7, pp. 173-179.
Vichare, N. and M. Pecht, (2006). Prognostics and Health Management of Electronics, IEEE Trans. on Components and Packaging Technologies, Vol. 29, No. 1, pp. 222-229.
Voisin A., Medina-Oliva G., Monnin M., Leger JB. (2013). Fleet-wide Diagnostic and Prognostics Assessment. PHM Conference 2013, New Orleans, LA, USA.
Voisin, A., Levrat, E., Cocheteux, P., & Iung, B. (2010). Generic prognosis model for proactive maintenance decision support: Application to pre-industrial e-Maintenance test bed. Journal of Intelligent Manufacturing. 21 (2): 177-193.
Wang D., (2011). Ontology-based Fault Diagnosis for Power Transformers. Master of Philosophy Thesis in Electrical Engineering and Electronics. University of Liverpool.
Wang P., Youn B., Byeng D. (2012). A generic probabilistic framework for structural health prognostics and uncertainty management. Mechanical Systems and Signal Processing. 28, Pages 622–637
Wang T., Yu J., Siegel D., Lee J. (2008). A similarity-based prognostics approach for Remaining Useful Life estimation of engineered systems. International Conference on Prognostics and Health Management. Denver, USA.
Weber P., Medina-Oliva G., Simon C., Iung B. (2012). Overview on Bayesian networks Applications for Dependability, Risk Analysis and Maintenance areas. Engineering Applications of Artificial Intelligence, vol. 25 (4), (671-682).
Wheeler, K., Kurtoglu, T., Poll, S.D. (2009). A survey of health management user objectives related to diagnostic and prognostics metrics, in Proceedings of International Design Engineering Technical Conferences and Computers and Information in Engineering Conference, August 30–September 2, San Diego, California, USA.
Williams, Z., Gilbertson, D. & Sheffield, G., (2008). Fleet analysis and planning using CBM+ open architecture, in Proceedings of IEEE International Conference on Prognostics and Health Management, Denver, CO.
Wu Z., Palmer M. (1994). Verb semantics and lexical selection, In Proceedings of the 32nd annual meeting of the Association for Computational Linguistics, pp 133-138.
Yang B-S, Lim D-S, Tan ACC (2005). VIBEX: an expert system for vibration fault diagnosis of rotating machinery using decision tree and decision table. Expert Systems with Applications 28, 735-742.
Zarri G.P. (2011). Knowledge representation and inference techniques to improve the management of gas and oil facilities. Knowledge-Based Systems, vol 24, 989–1003.
Zio E., Baraldi P., Gola G. (2008). Feature-based classifier ensembles for diagnosing multiple faults in rotating machinery, Applied Soft Computing Journal 8 (4) 1365–1380.