D A Tobon-Mejia

K Medjaher

N Zerhouni

G Tripot

Hidden Markov Models for Failure Diagnostic and Prognostic

Keywords: Monitoring, Diagnostic, Prognostic, Remaining Useful Life, Hidden Markov Models I

This paper deals with an estimation of the Remaining Useful Life of bearings based on the utilization of Mixture of Gaussians Hidden Markov Models (MoG-HMMs). The raw signals provided by the sensors are first processed to extract features, which permit to model the physical component and its degradation. The prognostic process is done in two phases: a learning phase and an evaluation phase. During the first phase, the sensors' data are processed in order to extract appropriate and useful features, which are then used as inputs of dedicated learning algorithms in order to estimate the parameters of a MoG-HMM. The obtained model represents the behavior of the component including its degradation. In addition, the model contains the number of health states and the stay durations in each state. Once the learning phase is done, the generated model is exploited during the second phase, where the extracted features are continuously injected to the learned model to assess the current health state of the physical component and to estimate its remaining useful life and the associated confidence.

The proposed method is tested on a benchmark data taken from the "NASA prognostic data repository" related to bearings used under several operating conditions. Moreover, the developed method is compared to two methods: the first using traditional HMMs with exponential time durations and the second using regular Hidden Semi Markov Model (HSMM). Finally, simulation results are given and discussed at the end of the paper.

INTRODUCTION

Maintaining the equipment in operating conditions is an industrial, economical and societal requirement. The maintenance can be curative or preventive. In the first case, the maintenance interventions are done only after a fault has been observed or undergone. Thus, this may lead to non desired situations; especially for sensitive industrial systems (one can cite the recent petrochemical explosion in the Gulf of Mexico). To avoid such cases, a systematic maintenance can be implemented. Moreover, the implementation of a condition Based Maintenance (CBM) [START_REF] Lebold | standards for condition-based maintenance and prognostic systems[END_REF] can lead to significant benefits. Indeed, contrary to a systematic maintenance, a CBM is done according to the real equipment's health condition, estimated or measured through the sensors present on the industrial equipment. In addition, by using appropriate mathematical or modeling tools, the estimated or measured equipment's state can be projected in order to predict its future health condition and thus take appropriate decisions.

In the framework of CBM, failure prognostic is considered as one of the main processes, as it permits to estimate what is called Remaining Useful Life (RUL) before failure of a given industrial system [START_REF] Jardine | A review on machinery diagnostics and prognostics implementing condition-based maintenance[END_REF]. Numerous methods and tools can be used to predict the RUL's value. These methods can be classified into three main groups [START_REF] Lebold | standards for condition-based maintenance and prognostic systems[END_REF]: model-based prognostic, datadriven prognostic and experience-based prognostic. Modelbased prognostic [START_REF] Heng | Rotating machinery prognostics: State of the art, challenges and opportunities[END_REF] deals with the prediction of the RUL of critical physical components by using mathematical or physical models of the degradation phenomenon (crack by fatigue, wear, corrosion, etc.). The data-driven prognostic [START_REF] Heng | Rotating machinery prognostics: State of the art, challenges and opportunities[END_REF] aims at transforming the data provided by the sensors into relevant models of the degradation's behavior. Finally, the experiencebased prognostic [START_REF] Heng | Rotating machinery prognostics: State of the art, challenges and opportunities[END_REF] exploits the data gathered from the machine during a long period of time to estimate the parameters of traditional reliability laws. Finally, they are used to do extrapolations and projections to compute the RUL.

In this paper, a failure prognostic method based on the use of the data provided by the sensors is presented. This method belongs then to the category of data-driven approach, and uses mainly Mixture of Gaussians Hidden Markov Models (MoG-HMMs) to model the degradation and to estimate the value of RUL before a potential failure. This tool is chosen for its capability to transform the features extracted from the raw signals to relevant behavioral models representing the physical component and its degradation. The proposed failure prognostic method is done in two phases: a learning phase and an evaluation phase. During the first phase, the raw signals coming from the sensors are processed to extract appropriate and useful features. These features are then used to learn the parameters of the MoG-HMMs. In the second phase, the learned models are exploited in order to assess the current condition of the component and to predict its future one. In addition to this latter, a confidence value can be calculated. The RUL and the confidence are important information that may be used in the decision process. For example, they can be used to delay the maintenance interventions or to stop a machine before its future maintenance due to early fault. The developed prognostic method based on the use of MoG-HMMs is finally compared to two other methods: the first uses simple HMMs and the second is based on Hidden Semi-Markov Models (HSMMs).

The paper is organized as follows: after the introduction, some definitions and the existing prognostic approaches are given in section 2. Section 3 presents the proposed method followed by its comparison with two other methods cited previously, with simulation results are given for each method. Finally, section 4 presents the conclusion and some future works.

II. FAILURE PROGNOSTIC: DEFINITION AND TAXONOMY Contrary to fault diagnostic, which consists in detecting and isolating the probable cause of the fault [START_REF] Jardine | A review on machinery diagnostics and prognostics implementing condition-based maintenance[END_REF], [START_REF] Venkatasubramanian | Prognostic and diagnostic monitoring of complex systems for product lifecycle management: Challenges and opportunities[END_REF] and which is done a posteriori, i.e. after the occurrence of the fault, failure prognostic aims at anticipating the time of the failure and thus is done a priori, as shown in Fig. 1. Several definitions about failure prognostic have been reported in the recent literature [START_REF] Lebold | standards for condition-based maintenance and prognostic systems[END_REF], [START_REF] Wang | Prognosis of machine health condition using neuro-fuzzy systems[END_REF], [START_REF] Muller | Formalisation of a new prognosis model for supporting proactive maintenance implementation on industrial system[END_REF]. However, in this paper only that one proposed by the International Standard Organization [START_REF] Afnor | Condition monitoring and diagnostics of machinesprognostics -part 1: General guidelines[END_REF] is considered and where prognostic is defined as "the estimation of the Time To Failure (ETTF) and the risk of existence or later appearance of one or more failure modes". Note that, most of the definitions reported in the literature use the terminology "Remaining Useful Life (RUL)" instead of "ETTF". An illustration of a RUL estimation is given in Fig. 2.

In addition to the absolute value of the RUL, a confidence can be associated, which may be useful during the decision process. A method for calculating the confidence value associated to a RUL prediction is proposed in the standard [START_REF] Afnor | Condition monitoring and diagnostics of machinesprognostics -part 1: General guidelines[END_REF]. A list of the factors and the corresponding weights, which may influence the computation of the confidence are suggested.

Numerous methods and tools regarding failure prognostic have been proposed and reported in the literature. This material can be grouped in three main categories [START_REF] Jardine | A review on machinery diagnostics and prognostics implementing condition-based maintenance[END_REF], [START_REF] Heng | Rotating machinery prognostics: State of the art, challenges and opportunities[END_REF], [START_REF] Vachtsevanos | Intelligent fault diagnosis and prognosis for engineering systems[END_REF] (Fig. 3): experience -based prognostic, data -driven prognostic and model -based prognostic. 1) Model-based prognostic: in this approach, the physical component or system and its degradation phenomenon are represented by a set of mathematical laws. The obtained behavioral model is then used to predict the future evolution of the degradation [START_REF] Luo | Model-based prognostic techniques applied to a suspension system[END_REF], [START_REF] Chelidze | A dynamical systems approach to failure prognosis[END_REF]. In this case, the prognostic consists in evolving the degradation model till a determined future instant, from the actual deterioration state and by considering the future use conditions of the corresponding component. The main advantage of this approach dwells in the precision of the obtained results, as the predictions are achieved based on a mathematical model of the degradation. However, the derived degradation model remains specific to a particular kind of component or material, and thus, can not be generalized to all the system components. In addition, getting a mathematical model of the degradation is not an easy task and needs well instrumented test-benches.

2) Data-driven prognostic: this approach consists in transforming the monitoring data provided by the sensors installed on the system into reliable behavioral models of the degradations [START_REF] Heng | Rotating machinery prognostics: State of the art, challenges and opportunities[END_REF], [START_REF] Dong | A segmental hidden semi-markov model (hsmm)-based diagnostics and prognostics framework and methodology[END_REF]. The collected data are first processed in order to extract relevant features. These latter are then exploited to learn the parameters of behavioral models. The formalization tools used in this approach are mainly those used by the artificial intelligence community, namely: temporal prediction series, trend analysis techniques, neuronal networks under all their facets, neuro-fuzzy systems, hidden Markov models and also dynamic Bayesian networks.

The advantage of this approach is that, for a well monitored system, it is possible to predict the future evolution of the degradation without any need of prior mathematical model of the degradation. However, the results obtained by this approach can be less precise than those of model-based prognostic, and are sometimes considered as local ones (for the case of neural networks and neuro-fuzzy methods).

3) Experience-based prognostic: the methods belonging to this approach use probabilistic or stochastic models of the degradation phenomenon, or of the life cycle of the components, by taking into account the data and the knowledge accumulated by experience during the whole exploitation period of the industrial system (experience feedback, maintenance data, etc.). This data is then used to adjust the parameters of some reliability models (Weibull law, exponential law, etc.) [START_REF] Keller | Reliability analysis of cnc machine tools[END_REF], [START_REF] Groer | Analysis of time-to-failure with a weibull model[END_REF].

The advantage of this prognostic approach is that it is not necessary to build complex mathematical models. It is also easy to apply on systems for which significant data are available. However, the main drawback of the approach dwells in the amount of data needed to estimate the parameters of the used laws.

III. HIDDEN MARKOV MODELS

This section gives a brief introduction to the Hidden Markov Models (HMMs) and their variants that will be used in the next section to present the different ways to do failure diagnostic and prognostic in an integrated manner.

An HMM is defined as a statistical model used to represent stochastic processes, where the states are not directly observed [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF] (Fig. 4). An HMM is completely defined by the following parameters:

• N: number of states in the model.

• M: the number of distinct observations for each state.

• A: the state transition probability distribution.

• B: the observation probability distribution of each state.

• π: the initial state distribution π.

For simplicity and clarity of presentation, a compact notation ( = π, A, B) is used for each HMM. In practice, HMMs are used to solve three typical problems [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF]: a detection problem, a decoding problem and a learning problem.

Usually, discrete HMMs consider the observations as discrete symbols and use discrete probability densities to model the transition and the observation probabilities. The problem with this approach is that in condition monitoring the observations are typically continuous signals. In order to use a continuous observation density, some restrictions are placed to insure that the parameters of the probability density function can be re-estimated [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF].

() ( ) 1 ,, , 1
M ij m j m j m m bO C O U j N ξμ = =≤ ∑ ≤ (1)
In Equation ( 1), O is the observation vector, C jm is the mixture coefficient for the m th mixture in state i and ξ is any log concave or elliptically symmetric density with mean vector jm and covariance matrix U jm for the m th mixture component in state j. Usually, a Gaussian density is used for ξ and the corresponding model is called a MoG-HMM, which is completely defined by: the A matrix, the B matrix and the initial probability π. For a MoG-HMM the observation matrix B is modeled by a Gaussian density with a mean , a standard deviation σ and a mixture matrix M.

IV. FAILURE PROGNOSTIC AND DIAGNOSTIC METHODS

BASED ON HMMS

Previous research works related to failure diagnostic and prognostic methods based on HMMs and their variants [START_REF] Dong | A segmental hidden semi-markov model (hsmm)-based diagnostics and prognostics framework and methodology[END_REF], [START_REF] Ocak | Online tracking of bearing wear using wavelet packet decomposition and probabilistic modeling: A method for bearing prognostics[END_REF] have been developed. The proposed methods are done in two phases: a learning phase and an exploitation phase. In the following of the paper, an explanation and comparison between three prognostic methods is proposed. The first method is based on traditional HMMs, the second relies on Hidden Semi-Markov Models (HSMM) and the third uses MoG-HMMs.

A. The HMMs case

The learning phase and the exploitation phase for use traditional HMMs to perform diagnostic and prognostic are presented below.

1) Learning phase: the extracted features from complete monitoring histories (from the normal condition to the failure state) are transformed into HMMs by using the well known Baum-Welch algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF]. Thus, an HMM model is created for each failure, the model is then stored in a model base containing all the HMMs with a diagnostic label associated to each learned histories.

2) Exploitation phase: the on-line data are used as inputs to the learned models in order to diagnostic and prognostic the health state. Indeed, the online extracted features are used in a first step to find the model that best fits the actual observation sequence by computing the probability P(O| ) (similarly to the process in Fig. 5).

In a second step the parameters of the selected model are used to assess the current health state and to estimate the RUL. The Viterbi Algorithm [START_REF] Viterbi | Error bounds for convolutional codes and an asymptotically optimal decoding algorithm[END_REF] is used to find the state sequence, then the most persistent state in the last observations is retained as the current health state, as shown in [START_REF] Jardine | A review on machinery diagnostics and prognostics implementing condition-based maintenance[END_REF].

( ) ( ) 12 21 State sequence , , , , Last states , , , , , with past
= = == … … (2)
By knowing the actual health state the Chapman-Kolmogorov equation ( 3) is used to re-estimate the health state after n iterations [START_REF] Ross | Probability Models for Computer Science[END_REF]. When the predicted probability of being in the last state reaches a predefined limit ε, the RUL can be calculated (4).

()

n t Pn A π = (3)
( )

N RUL n P s s n ε = ⇔= = (4)

B. The HSMMs case

The problem with traditional HMMs is that the durational behavior is usually characterized by a geometrically decaying function. This assumption is a source of inaccurate duration modeling because most of real-life applications do not obey this function. Thus, to solve this problem a model with explicit time durations, called Hidden semi Markov Model, has been proposed [START_REF] Dong | A segmental hidden semi-markov model (hsmm)-based diagnostics and prognostics framework and methodology[END_REF]. The learning and exploitation phase using this model are performed as follows.

1) Learning phase: similarly to a traditional HMM, the parameters of the HSMM are defined by using the history data and the Baum-Welch algorithm. For an HSMM the shape is constrained to a left-to-rigth model. In addition, for each state the stay durations D(s i ) are learned by using the Viterbi algorithm. The idea is to use the learned parameters (π, A, B) and the history data to obtain the whole observation sequence. Then, by taking into account the transition instant between the states, the duration D can be defined. Finally, by assuming that the sojourn time follows a Gaussian distribution, the mean time duration µ(D(s i )) and the standard deviation σ(D(s i )) of the same state concerning different histories of the same fault can be estimated (( 5) and ( 6)).

()

( ) () 1 1 H i h h Ds Ds H μ = = ∑ i (5) () ( ) () () ( ) 2 1 1 H ii h h Ds Ds Ds H σ μ = ⎡⎤ =-⎣⎦ ∑ i ( 6
)
In Equations ( 5) and ( 6), D(•) stands for the stay duration, i is the state index, h is the history index and H is the total number of histories from a particular fault state.

2) Exploitation phase: in this step the learned models and their associated stay duration are used. First a competitive model selection is performed by using the raw data and the forward-backward algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF] to compute the probability P(O| ) over all the learned models (Fig. 5). The label of the winner model is used to diagnose the monitored system and the actual health state is defined in the same way as in traditional HMMs using [START_REF] Jardine | A review on machinery diagnostics and prognostics implementing condition-based maintenance[END_REF]. In addition, the selected model is used to estimate the RUL.

The HSMMs permits to estimate the RUL in two ways: a) By using the expression proposed in [START_REF] Dong | A segmental hidden semi-markov model (hsmm)-based diagnostics and prognostics framework and methodology[END_REF] where the stay durations are merged with the state probability transitions:

[ ] ,1 1 ll c l l l RUL t a RUL ++ =+ ( 7
)
where l is the actual state index, t lc is the state changing point and a l,l+1 is the probability transition to the next state. b) By using a more intuitive expression adding the state duration from the current state until the last state and subtracting the time spent in the actual state [START_REF] Vachtsevanos | Intelligent fault diagnosis and prognosis for engineering systems[END_REF].

Furthermore, a confidence interval with different recovering values can be easily estimated by using the Bonferroni method (9). (

limits 1 2 N ii il l RU L Ds c f Ds t cf μσ α = ⎡ ⎤ = ±⋅ - ⎢ ⎥ ⎣ ⎦ + Φ= ∑ (9) ) ( ) () ( ) ( )
In Equations ( 8) and ( 9), l is the actual state, i is the state index, N the total number of states, µ(D(s i )) is the mean time duration in the state i, σ(D(s i )) the standard deviation, t l is the time spent in the actual state, α is the confidence interval between [0,1] and cf is the confidence factor that are defined by using Φ that is the cumulative distribution function of a Gaussian probability distribution.

C. The MoG-HMM based method

The originality of the proposed method dwells in the fact that raw signals are processed using the Wavelet Packet Decomposition (WPD) to extract the relevant information to learn the behavior models. Also in the generated MoG-HMM, the states' stay durations are not assumed to be a geometrically decaying function as in the HSMMs case, but are learned from the monitoring data (note that multiple continuous signals are considered as observation for both learning and simulation phases, instead of the traditional mono observation approach). Moreover, in the proposed method there is no limitation for the type of the generated MoG-HMM (the model can be an ergodic, a left-right or a parallel left-right).

1) Learning phase: in this first phase, which is executed off-line, the raw data recorded by the sensors are processed in order to extract the energy of each node at the last decomposition level by using the WPD technique [START_REF] Zarei | Bearing fault detection using wavelet packet transform of induction motor stator current[END_REF]. These features are then used to learn several behavior models (in the form of MoG-HMMs) corresponding to different histories related to several initial states and/or operating conditions of the component. Also one global left-to-right MoG-HMM is learned for each type of fault. It has X states meaning the different asset health states. Indeed, each raw data history corresponding to a given component's condition is transformed to a feature matrix F, by using the WPD. In this matrix, each column vector (of C features at time t) corresponds to a snapshot on the raw signal, and each cell fct represents the node c of the last WPD level at time t.

t cc t f f F f f tT cC ⎛⎞ ⎜⎟ ⎯⎯⎯ →= ⎜⎟ ⎜⎟ ⎝⎠ ≤≤ ≤ ≤ … ( 10
)
The nodal energy (features) are then used to estimate the parameters (π, A, B) and the temporal parameters (stay duration in each state) of the MoG-HMMs.

The parameters of each MoG-HMM are learned using the Baum-Welch algorithm [START_REF] Dempster | Maximum likelihood from incomplete data via the EM algorithm[END_REF], whereas the temporal ones are estimated by using the Viterbi algorithm [START_REF] Viterbi | Error bounds for convolutional codes and an asymptotically optimal decoding algorithm[END_REF]. This algorithm permits to obtain the state sequence and to compute the time duration for which the component has been in each state of the corresponding MoG-HMM (Fig. 6). Thus, by assuming that the state duration in each state follows a normal law, it is possible to estimate the mean duration [START_REF] Dong | A segmental hidden semi-markov model (hsmm)-based diagnostics and prognostics framework and methodology[END_REF] and the corresponding standard deviation ( 12) by computing the duration and the number of visits in each state. Moreover, the Viterbi algorithm permits to identify the final state which represents the physical component's failure state.

ω ω σ Ω = ⎡ =-⎣ Ω ∑ i μ ⎤ ⎦ f i n a l ) ) (12)
In equations ( 11) and ( 12), D(•) stands for the visit duration, i is the state index, ω is the visit index and Ω corresponds to the total of visits. A compact representation of each learned MoG-HMM used to perform diagnostic and prognostic is given by the following expression:

() ( ) () ( ) ( ) ,,, , , ii AB Ds Ds S λπ μ σ = ( 13
)
Where is the fully defined model and S final is the final state (corresponding to the end of the considered condition monitoring history).

2) Exploitation phase: this phase, which is performed online, consists in exploiting the learned models to detect the component's current condition (using the Viterbi algorithm) and to compute the corresponding RUL. The processed data and the extracted nodal energy using the Wavelet toolbox from Matlab ® are thus continuously fed to the learned models in order to find the global MoG-HMM, which best fits to the observed sequence, then the diagnostic is made and the current health state is defined. The selection process is based on the calculation of a likelihood P(O| ) of the model over the observations (HMMs problem 1). Finally, by knowing the current type of fault, the nearest model concerning this fault can be found (Fig. 5). Using this last and the current model state and the stay durations learned in the off-line phase, the component's RUL and its associated confidence value can be estimated.

The generated MoG-HMMs are used during the on-line phase to estimate the RUL and the associated confidence value of the physical component by using a dedicated procedure whose steps are the following: a) Detection of the appropriate global left-to-right general MoG-HMM that best fits and represents the on-line observed sequence of nodal energy. The diagnostic label of the selected model is used to establish the diagnostic of the current condition. d) Identification of the critical path, which goes from the current state to the end state. The idea is to identify all the non-zero probabilities in the transition matrix as potential transitions, and then to choose the minimal path among all the possible ones (Fig. 7) with only one visit per state.

N mean i i RUL D s μ = = ∑ (14) () ( current state
N lower i i i RUL D s cf D s μ σ = =-⋅ ∑ ) (15) () ( ) () ( [ ] current state
V. APPLICATION AND SIMULATION RESULTS The failure prognostic methods presented previously are tested on a rich condition monitoring data base taken from [START_REF]for Intelligent Maintenance Systems[END_REF] and containing several bearings tested until the failure. The choice of bearings can be explained by the fact that these components are considered as the most common mechanical elements in industry and are present in almost all industrial processes, especially in those using rotating elements and machines. Moreover, bearings are the main components which most frequently fail in rotating machines [START_REF] Donnell | Report of large motor reliability survey of industrial and commercial installations, part I, II & III[END_REF].

The test data correspond to several tests under constant conditions. Four bearings were installed on one shaft. The angular velocity was kept constant at 2000 rpm and a 6000 lb radial load was applied onto the shaft and bearings (Fig. 8). On each bearing two accelerometers were installed for a total of 8 accelerometers (one vertical Y and one horizontal X) to register the accelerations generated by the vibrations, were the sampling rate was fixed at 20 kHz. For simulation purposes (learning and on-line failure prognostic), twelve condition monitoring data histories are used (eleven for learning and one for test), each bearing was considered failed at the end of its associated history, all the history were supposed independent. In the following results the monitoring history related to the bearing 2 in the test 2 is used as test history. The other eleven monitoring histories are used exclusively for training. The test data history concerns the bearing that fails after 9840 min of operation. Note that for all the models the number of states was fixed to three.

A. The HMMs case

In traditional HMMs only one discrete observation is used [START_REF] Rabiner | A tutorial on hidden markov models and selected applications in speech recognition[END_REF]. To transform the continuous signal in a discrete one, the vibrations from the histories are processed. First the root mean square (rms) of the accelerometer placed in the same direction of the load is extracted. Then those values are scaled and rounded to the nearest integer as shown in Fig. 9. 3) to find the RUL one can note that the representation of the stay durations by exponential laws in HMMs does not always hold in practice. For example, when the bearing is detected to be in the first health state and using (3) with the learned matrix A, the number of iterations required to get a probability of 95% to be in the failure state (state 3) will be equal to 17518. Knowing that the time interval between the measures is 10 min, this means that the bearing will fail after 175180 min, when the real failure is at 9480 min. The exponential behavior of traditional HMMs are thus a real drawback of this model and that is why other models including the explicit time behavior are wished for prognostic applications.

B. The HSMMs case

In HSMMs discrete or continuous observations can be used. In this simulation the nodal energies in the third level of the WPD (using the "Daubechies" wavelet family) at each instant t have been extracted from the raw signals (vibration signals). This choice permits to obtain wide frequency bands of 2.5 kHz. The extracted features where used to learn one model per history and then used to predict the RUL at each instant t using [START_REF] Vachtsevanos | Intelligent fault diagnosis and prognosis for engineering systems[END_REF]. The results are presented in Fig. 10, where one can appreciate a dominant late prognostic with an erratic behavior when the system approaches the transition from the state 2 to the state 3, also the model converges late to the real RUL.

C. The MoG-HMM case

During the learning phase of the MoG-HMM method, the parameters of each model were first randomly initialized and then, the continuous extracted features were fed to the learning algorithms in order to re-estimate the initialized parameters (π, A, B). The number of mixtures in each MoG-HMM was set to two, which allows a trade-off between precision and computation time. Eleven MoG-HMMs were thus obtained by using the Baum-Welch algorithm.

In order to simulate an on-line failure, the "test" data history is used. The selection process shown in Fig. 5 is then applied on the data history corresponding to the bearing 2 in the test 2 in order to identify the "best MoG-HMM" at each instant t and to estimate the RUL. A simulation result of the predicted RUL and the corresponding error is shown in Fig. 11.

From Fig. 12-(a) and Fig. 12-(b) one can see that the precision of the estimated RUL increases as the prediction time is approaching the real failure time. Similarly, after 7440 min the mean estimation error drops below 16.5 % whereas when considering the upper RUL limit the error drops to 7 % and continues to decrease as the real failure time approaches. After 9610 min the mean error stabilizes around the value of 1.08 %. The 68 % confidence interval keeps the RUL estimation limits near acceptable values, a wide confidence intervals (95 % and 99.5 %) will give more sparse limits and will increase the prediction error. Note that the obtained results are better than those obtained by using the temporal features (Root Mean Square, mean, skewness and kurtosis) [START_REF] Tobon-Mejia | A mixture of gaussians hidden markov model for failure diagnostic and prognostic[END_REF]. The RUL and the associated prediction error of the same test history using temporal features are shown in Fig. 12-(c) and Fig. 12-(d).

D. Method Comparaison

The results of the precedent methods are compared using the root mean squared error (RMSE) as the model performance criterion. This measure is useful to qualify the accuracy of the predictions thanks to its sensibility to large errors. The RUL estimations of each method were evaluated using the RMSE criterion and the results are presented in Table . 1. The results obtained with traditional HMMs are the less performing due to the exponential behavior of the model. The time integration in HMMs by using explicit state duration like in HSMM improves the prognostic results reducing the error. Finally the proposed MoG-HMM model upgrades the HSMM thanks to its ability to build the more appropriate model unconstraining the model shape and well modeling the continuous signals.

Figure 1 .

 1 Figure 1. Diagnostic vs prognostic.

Figure 2 .

 2 Figure 2. Illustration of a RUL.

Figure 3 .

 3 Figure 3. Main prognostic approaches.

Figure 4 .

 4 Figure 4. A three state left-to-right HMM.

Figure 5 .

 5 Figure 5. Competitive model selection.

Figure 6 .

 6 Figure 6. Example of Viterbi decoding state.

b)

  Choice of the nearest RUL model knowing the active failure mode. c) Identification of the current state of the selected RUL model.

Figure 7 .

 7 Figure 7. Path estimation e) Estimation of the RUL. This latter is obtained by using the temporal parameters of the stay duration in each state. In addition, a confidence value over the RUL is calculated based on the standard deviation values of the stay durations and the Bonferroni confidence interval as in (9).

Figure 8 .

 8 Figure 8. Test bed

Figure 9 .

 9 Figure 9. RMS discretisation

Figure 10 .

 10 Figure 10. RUL HSMM

Figure 11 .

 11 Figure 11. Simulation results: (a) RUL estimation for the bearing 2 in test N°2 using WPD; (b) prediction error for the bearing 2 in test N°2 using WPD; (c) RUL estimation for the bearing 2 in test N°2 using temporal features; and, (d) prediction error for the bearing 2 in test N°2 using temporal features.

TABLE I .

 I RMSE OF THE PREDICTION ERROR FOR EACH METHOD

	Method	HMM	HSMM	WPD/MoG-HMM
	RMSE	1.2322 * 10 5	2.8229 * 10 4	4.6679 * 10 3


Marie-Danièle Gauvain

Rafael Gouriveau
email: rafael.gouriveau@ens2m.fr

Noureddine Zerhouni

Christophe Varnier

Nadine Piat

Mike Hessabi

Defining and implementing a distributed and reconfigurable information system for prognostics A real world integrated predictive maintenance system

Keywords: Predictive maintenance, CBM, e-maintenance platform, modular architecture, prognotic module I

According to Condition Based Maintenance practitioners, various activities, ranging from data collection through the recommendation of specific maintenance actions, must be carried out to perform predictive maintenance. Nevertheless, in practice, (and in spite of recommendations like those ones of the OSA-CBM standard), defining and implementing a computer software system for CBM is not a trivial task. That can be mostly explained by the necessity of providing a distributed application that enables to share data and information in an easy but effective manner in-between various actors from various industrial plants. Following that, the aim of the paper is to describe a collaborative software that has been developed in the society e-m@systec. Its simple architecture, as well as its evolving and customizable capabilities make the global information system as useful for distributed applications. The usage of JEE technology improves the portability of the system. This software is well adapted to support predictive maintenance strategies. Thereby and as for an illustration, an example related to a prognostic problem is also described.

INTRODUCTION

The growth of reliability, availability or safety of a system is a determining factor regarding the effectiveness of industrial maintenance. Thereby, the implementation of provisional strategies is a good way to improve the availability of processes, to ensure the smallest variations of products qualities or the direct costs falling [START_REF] Leger | Integration of maintenance in the enterprise: towards an enterprise modelling based framework compliant with proactive maintenance strategy[END_REF]. Furthermore, sustainable development involves the integration of economical strategies beside social and environmental ones for the optimization of processes. This major provocation of triple performance outlined a new and interesting research area: concepts like corrective or preventive maintenance were progressively completed by predictive and proactive maintenance [START_REF] Muller | Formalisation of a new prognosis model for supporting proactive maintenance implementation on industrial sytem[END_REF]. In these maintenance strategies, "prognostic" takes a growing place and is recognized as a key feature. However, it is obvious that prognostic can not be seen as a single maintenance task as its applicability, cost and effectiveness can vary from an industrial plant to another. Also, the whole aspects of failure analysis and prediction must be viewed as a set of activities that all must be performed. This aspect is highlighted within the Condition-Based Maintenance concept.

According to [START_REF] Lebold | Open standards for condition-based maintenance and prognostic systems[END_REF], Condition Based Maintenance "entails the maintenance of equipments based on an assessment of current and projected condition (or health)". The increasing use of CBM strategy (and thereby of CBM systems) is mainly due to the growing needs of reducing maintenance and logistics costs, of improving equipment availability, and of protecting against failure of critical equipments. Also, industrials show a growing interest in this thematic which is becoming a major research framework as mentioned in recent papers [START_REF] Ciarapica | Managing the condition-based maintenance of a combined-cycle power plant: an approach using soft computing techniques[END_REF][START_REF] Heng | Rotating machinery prognostic: State of the art, challenges and opportunities[END_REF][START_REF] Jardine | A review on machinery diagnostics and prognostic implementing condition-based maintenance[END_REF].

Nevertheless, in practice, defining and implementing a computer software system for CBM is not a trivial task. Indeed, beyond the aspects inherent to the usage of "physical" devices like intelligent sensors or table computers, various problems follow from the distributed aspect of the application and the integration effort needed. As for examples, let note the diversity of actors that are involved in a real world application (technicians, managers…), the heterogeneity of useful data (event data, sensor data…), the types of indicators that should be provided, the necessity of exchanging data between the modules and others information systems like SCADA, CMMS and ERP, the goal of operating in a plug-and-play fashion, etc. Following that, the aim of this paper is to discuss some problems that follow from the objective of implementing a distributed CBM information system by describing a real world software suite. The society e-m@systec has developed an emaintenance platform that enables to share data and information in between various actors and applications in order to provide a global distributed maintenance system.

The paper is organized as follows. First CBM concept is briefly described, and the main requirements pointed out in literature to develop a computerized CBM system are given. Then, the software suite from e-m@systec is presented, as well as its components. The whole aims at discussing the distributed and integrative aspects of this platform. Following that, a closer look on the prognostic module definition and implementation is made in order to illustrate the capabilities of such an emaintenance platform. Finally, section V summarizes conclusions of this paper and outlines guidelines for possible futures works.

II. CBM ARCHITECTURES

A. CBM systems -an overview

Many works have been done around the e-maintenance concept like the review on existing platforms provided by [START_REF] Muller | On the concept of emaintenance: Review and current research[END_REF]. To facilitate the CBM architectures development and to improve the interchangeability of different components, the MIMOSA consortium (Machinery Information Management Open System Alliance) proposed an Open System Architecture for Condition Based Maintenance (OSA-CBM) [START_REF] Lebold | Open standards for condition-based maintenance and prognostic systems[END_REF]. As for an application example, let point out the Watchdog Agent concept described in [START_REF] Djurdjanovica | Watchdog Agent -an infotronicsbased prognostics approach for product performance degradation assessment and prediction[END_REF] that aims at implementing some components of the OSA-CBM in a distributive manner.

OSA-CBM recommends the development of seven types of modules in order to cover the tasks that are useful to perform conditional and predictive maintenances: a sensor module, a signal processing module, a condition monitoring module, a health assessment module, a prognosis module, a decision support module, and a presentation module. These modules are generally represented as communicating thanks to internet or a local network like in Figure 1 [START_REF] Lebold | Open standards for condition-based maintenance and prognostic systems[END_REF]. [START_REF] Bengtsson | Condition based maintenance system technologywhere is development heading?[END_REF] provides an overview of standards that aim at facilitating the development of each one of the modules. Whithin all references, the ISO 13374-2 standard is noticeable in that it has been created to formalize the recommendations of OSA-CBM [START_REF]Condition monitoring and diagnostics of machines -Data processing, communication and presentation -Part 2: Data processing[END_REF]. This standard can now be seen as a central work, and e-m@systec also wished to base the development of its platform on it.

B. ISO 13374-2 standard

ISO 13374-2 has been created to facilitate communication between different software for monitoring and diagnosis (CM&D) [START_REF]Condition monitoring and diagnostics of machines -Data processing, communication and presentation -Part 2: Data processing[END_REF]. To achieve this goal, the ISO 13374-2 advocates respecting the informational and processing architectures. This processing architecture is composed of 6 blocks (Figure 2).

• The data acquisition (DA) block collects analog, digital and manual data and converts analog data into digital data. The output of the module is digital data with timestamp and data quality indicator. • The data manipulation (DM) block processes the data in order to extract and select descriptors of interest (features) for the monitoring or diagnosis processes. Inputs from this block are either data from the DA block or from the DM block (cascaded data). • The state detection (SD) block aims at determining the state of a system or component. It also should generate alerts. SD block may make use of current and historical DA and DM outputs, as well as of SD data if needed (cascade data). • The health assessment (HA) block determines the current health status of equipment and establishes a diagnosis to determine the cause of the failure. This block uses all data needed from previous blocks. The main outputs are the health grade, the diagnosed faults, the recommendations, the explanation and a level of confidence. • The block of prognosis (PA) has the primary purpose of determining the future states of an equipment and to estimate its remaining useful life (RUL) for a projected operational context. A level of confidence should also be provided, as well as recommendations and explanations. Any kind of input data shall be used. • The advisory generation (AG) block aims at integrating information from previous modules and external constraints (availability) in order to recommend optimized actions.

C. Implementation requirements

The processing blocks must be adapted according to real implementation constraints. As for an example, each block needs an important data history whose workflow must be identified. Different algorithms can be used with static or dynamic configurations. The blocks may also have a Human-Machine Interface (HMI). For blocks HA, PA and GA, there are interfaces with external systems to recover past and future actions on equipment and operational data, and to quickly advise when to stop machine for emergency and launch new applications for assistance. The GA module also needs external constraints such as availability, security, cost, etc. The ISO 13374-2 also point out that all modules defined in software may contain the functionality of one or more blocks.

ISO 13374-2 provides the basic requirements for open software architectures information to be processed, communicated, and displayed by various software packages without specific protocols. Beyond the aspects inherent to the usage of "physical" devices like intelligent sensors or table computers, various problems follow from the distributed aspect of the application and the integration effort needed. Notably, which is the good way to implement a CBM architecture considering the data heterogeneity, the need of exchanging data between the modules and other information systems? Indeed, this aspect is unavoidable for real industrial applications: all maintenance actors do not require the same information. Also, they must be provided with contextual information. The purpose of next section is to present an architecture that enables to face with those problems. This architecture has been developed at e-m@systec in the framework of SMAC project (Semantic-maintenance and life cycle) (see Acknowledgment section).

III. E-M@SYSTEC SOFTWARE SUITE : A DISTRIBUTED AND RECONFIGURABLE INFORMATION SYSTEM

A. e-m@systec software suite overview e-m@systec global solution aims at providing advanced functionalities to simplify maintenance tasks in practice, from management to implementation. To perform the various maintenance activities (planning of interventions, inventory management, diagnostics, monitoring, maintenance strategies selection, etc.), the required information must be easily accessible and exchanged. That can be obtained thanks to the main core "e-m@web" of the software suite that allows the data centralization and redistribution (Figure 3). Let have a look on the 4 main major features that follow from it.

1) Access to data from the control/command at the operational level: the connection to SCADA (Supervisory Control And Data Acquisition) systems enables e-m@web to gather the data provided by sensors.

2) Access to available information in dedicated software tools: e-m@web interfaces the information coming from the maintenance-oriented systems tools such as DMS (Document management system), CMMS (Computerized Maintenance Management System) and ERP (Entreprise Resource Planning).

3) Provide specific applications for the implementation of an intelligent maintenance: e-m@web also offers specific modules dedicated to the anticipation (e-m@pron), the failure diagnostics (e-m@diag), the optimization of spare parts and interventions (e-m@log).

4) Facilitate representation with a HMI (Human-Machine

Interface) offering contextualized access: the em@real module provides support for the maintenance interventions. The software suite of e-m@systec is notably composed of e-m@web, e-m@diag and e-m@pron, whose main functionalities are the following. Event and sensor data are centralized by e-m@web, which can connect to different CMMS, ERP and SCADA systems to retrieve relevant data for the various maintenance processes. The module e-m@diag is a diagnosis module that is based on knowledge capitalization techniques like case-based reasoning. Prognostics of progressive failure are performed thanks to the e-m@pron module.

These three main modules are obviously not sufficient to perform support to a global maintenance. The e-m@sytec software suite integrates thereby the remaining functionalities defined in ISO 13374-2. An illustration is given in Figure 4 and can be briefly described as follows.

• The DA module is found in the CMMS data for event data such as work requests, the stock of spare parts and ERP data for event data such as the cost of spare parts and in the SCADA for sensor data; • The DM module is a part in the SCADA and one other in e-m@web; • The SD module is also located either in the SCADA or in e-m@web; • The HA module is in e-m@diag module;

• The PA module is in e-m@pron module;

• The AG module is the element the most important of e-m@web that use all data of the other tools.

B. The e-m@systec software suite as an integrating system

The e-m@systec software suite is a distributed, modular, portable and reconfigurable platform. Main advantages of these characteristics are the followings.

• The interest of a distributed platform is to perform the computations on different machines in order to reduce the global complexity of implementation. Another advantage is the exchange of experiences from various maintenance sites that enriches the knowledge base. • The modular platform enables to use only the necessary functionality. For example, if only conditional and corrective maintenances are required, there is no need to install the e-m@pron module. • Work environment constraints as operating systems, Windows or Linux, are no longer a problem thanks to the portability of the software suite. • Reconfigurability allows the adaptation of the platform to any maintenance system according to specific needs.

Three aspects are at least relevant to discuss the main characteristics of the software suite.

1) Several actors

Different actors can access the e-m@systec software suite. Depending on the connected role, contextual information varies. There are 5 different roles (administration roles are not considered here): the production operator, the maintenance worker, the manager, the expert and the top manager, as can be seen in Figure 5. The production operator is the user of maintained equipments. This role creates a work request for corrective maintenance when an equipment failure occurs. The maintenance worker is responsible of the maintenance task of equipments. The manager oversees the maintenance and human resources, and can access to all information related to his team. The top manager checks if the objectives are met and therefore has access to available indicators. The expert provides his knowledge and feedback on the equipments, for example, the configuration of e-m@diag and e-m@pron must be performed by an expert. These different roles are the default roles to facilitate the implementation of the platform. According to specific requirements and thanks to the reconfigurability characteristic of the platform, appropriate roles can however be created as needed.

2) Technology

In order to implement a distributed system, the various elements developed within the e-m@systec software suite are in the portable language JEE (Java Entreprise Edition), which facilitates the creation of distributed applications. More precisely, implementation is performed thanks to the Jboss free application server, which is the most commonly used. It uses the Seam framework that eases the development of Web applications, and the integration of JSF (JavaServer Faces), EJB 3 (Enterprise Java Bean) and JPA (Java Persistence API). JSF is a user interface framework. EJB is a reusable component designed to be deployed on application servers. JPA is an interface defining the mapping of objects within the database. The used database is PostgreSQL. A thin client is used, which has the advantage to require only a web browser to be installed. Figure 6 shows the various elements described above.

3) Communication between the differents modules

The e-m@web module has many ways to communicate with different tools depending on their technology. Between 2 e-m@systec tools, communication is done using EJB Session, which provides a service to customers via the RMI (Remote Method Invocation) protocol. Various web services are provided by PcVue, which is a SCADA. For example em@web can ask PcVue to return the last value of a sensor. There is also a connection with socket that is a lower levels' protocol. For example, the communication between a sensor of Senseor [START_REF] Senseor | [END_REF] (one of e-m@systec parterns) and e-m@web is made by socket. The different types of communication are shown in Figure 7.

A. Scenario and informational flow

The aim of the prognostic process is to determine when a machine will be considered as in a failure mode, and to give this information at the right time and at the right person, in order to open a work request if necessary. Let's take a simple scenario to illustrate these needs.

In a few words, there is an informational flow from the sensor to the practitioner in charge of managing the maintenance task. This flow can be schematized as depicted in Figure 8. (For clarity reasons and in order to illustrate the complementarities of e-m@systec modules, same colors than those of Figure 4 have been used). The first step is performed by the e-m@pron module that aims at saving the relevant data on the behavior of the equipment under study (thanks to monitoring devices), at estimating future values of these descriptors, and at performing a classification step in order to provide the health state of the equipment at any time. According to this last information, an alert or alarm can be raised (or not) which can finally lead to generate a work request and send emails to the maintenance manager.

Figure 9 depicts the information flow by taking into account the architecture of the e-m@systec software suite. (Here again, colors from Figure 4 are maintained). Two sites are represented: the first one is the manufactory in which the maintained equipment is located, and the other one states for a remote building in which can be located the manager. The manufactory has a SCADA and a server that houses the SCADA connector and the e-m@pron module. An other server is situated in the building and houses the remote e-m@web.

B. Performing prognostics

As briefly explained before, 3 steps are needed to perform prognostic: data archiving, prediction and classification.

1) Data archiving

To forecast, the e-m@pron module needs to make an interesting data archiving. This can be made thanks to a functionality of e-m@web: the historization of data (named the SCADA connector) that aims at labeling all data with an index of time, and at transmitting them to e-m@pron module. This last one is able to archive those data.

2) Prediction

Prediction aims at estimating the future values of data until a forecasting horizon set by the user. For that purpose, the e-m@pron module is based on the uses of a neuro-fuzzy system as a prediction tool. The underlying algorithm is presented in [START_REF] El-Koujok | Error estimation of a neuro-fuzzy predictor for prognostic purpose[END_REF] and is based on an exTS (evolving extended Takagi-Sugeno system).

3) Classification

The remote e-m@web module houses a classification functionality which calculates a set period. The classification aims at transforming the predicted values at any time "t+h" into most probable classes describing the health state of the equipment (normal, degraded, critical behavior). Eeach classification requires thereby results from the prediction algorithm of e-m@pron module. When classification is performed, whether a warning or an alarm is raised and em@web can create new work request and / or send an email to the person concerned by the information.

C. Degradation data simulation

The aim of this part is to illustrate the scenario with a simulation. The simulated degradation is a first-order chemical reaction introduced by [START_REF] Meeker | An Accelerated Life Test Model Based on Reliability Kinetics[END_REF]. It describes the growth of failurecausing conducting filaments of chlorine-copper compounds in printed-circuit boards. Let note CH 1 the amount of chlorine available for reaction and CH 2 a proportion of the amount of failure-causing chlorine-copper compounds at time "t". Under appropriate conditions of temperature, humidity, and electrical charge, there is a chemical reaction in which copper combines with chlorine (CH 1 ) to produce (CH 2 ) with a constant degradation rate (r 1 ):

CH 2 (t) = CH 1 (0) . [1 -exp(-r 1 .t)] (1)
where CH 1 (0) is the initial amounts of chlorine available for reaction.

In this paper, the proposed approach to perform prognostic assumes that no understanding of the degradation phenomena is necessary as the exTS predictor would track it. Thus, the mathematical expression in (1) was not used as a model but to generate realistic simulation data: this was done by simulating degradation rates (r 1 ) and by adding a random value (uniform distribution) as a noise to the calculated value of CH2(t).

An amount of 150 degradation data samples were generated and entered into the SCADA as if it would have been provided by a real plant (Figure 10). Following that, data where stored thanks to the data archiving functionality of e-m@pron, and were used to train the predictive model. Another degradation data sample has been generated to be used as a data simulation. When applying, e-m@pron module provides future values. For that purpose, at any time "t", 4 regressors (the 4 last data) were used as inputs from the prediction system (the exTs system) in order to perform predictions at "t+1". Multi-step ahead predictions (at any "t+h") were performed by applying the cascade techniques that aims at using results from prediction at "t+i" as inputs for prediction at "t+i+1". This configuration is realized by an expert and other type of long term approaches can be considered. In experiments, predictions were provided from time "50". Figure 11 depicts the results as presented by em@pron module.

The classification step is configured by an expert role. In this example a threshold of 85% of chlorine-copper compounds was set as critical with respect to the application (i.e. limit for the failure mode). When this limit is exceeded, an alert is triggered and an email is send to the manager. At any time, an email can also be sent to inform from the remaining useful life (RUL) of the equipment (in this example, failure will probably occurs on November the 28 th between 5h and 6h. A work request can thereby be performed in order to start with the scheduling of the maintenance task. Conditional Based Maintenance (CBM) and predictive maintenance are now considered as key feature since the uses of provisional strategies is a good way to improve the availability of processes, to ensure the smallest variations of products qualities or the direct costs falling. Nevertheless, in practice (and in spite of recommendations like those ones of the OSA-CBM standard), defining and implementing a computer software system for CBM is not a trivial task. That can be mostly explained by the necessity of providing a distributed application that enables to share data and information in an easy but effective manner in-between various actors from various industrial plants. Following that, the aim of the paper was to describe a collaborative software that has been developed in the society e-m@systec. The global software suite and some of its functionalities and modules have been described. Its simple architecture, as well as its evolving and customizable capabilities make the global information system as useful for distributed applications. The usage of JEE technology improves the portability of the system. This software is well adapted to support predictive maintenance strategies. Thereby and as for an illustration, an example related to a prognostic problem has also been described. For that purpose, a scenario of a prognostic application has been presented in order first, to illustrate the informational flow that is required, and secondly to show what characteristics of the software suite are powerful to perform this type of maintenance activity.

Figure 1 .

 1 Figure 1. Distributed architecture of Condition Based Maintenance [3]

Figure 2 .

 2 Figure 2. Data processing block diagram -ISO 13374-2 [10]

Figure 3 .

 3 Figure 3. e-m@systec software suite architecture

Figure 4 .

 4 Figure 4. Blocks of ISO 13374-2 in the software suite of e-m@systec

Figure 5 .

 5 Figure 5. Actors diagram of the software suite

Figure 6 .

 6 Figure 6. Technology representation

Figure 7 .

 7 Figure 7. Communications representation

Figure 8 .Figure 9 .

 89 Figure 8. Prognostics scenario -informational flow

2 Figure 10 .

 210 Figure 10. Degradations dataset

Figure 11 .

 11 Figure 11. Simulation result

AKNOWLEDGMENT

This work has been carried out and partially fund in the framework of SMAC project (Semantic-maintenance and life cycle), supported by European program Interreg IV between France and Switzerland.


Mohamed Hedi Karray

Brigitte Chebel-Morello

Noureddine Zerhouni
email: noureddine.zerhouni@femto-st.fr

A Formal Ontology for Industrial Maintenance

The rapid advancement of information and communication technologies has resulted in a variety of maintenance support systems and tools covering all sub-domains of maintenance. Most of these systems are based on different models that are sometimes redundant or incoherent and always heterogeneous. In order to create a common and shared language, we are developing a domain ontology of industrial maintenance adopting METHONTOLOGY approach to manage the lifecycle development of this ontology that we have called IMAMO (Industrial MAintenance Management Ontology). The ontology developed can be exploited to ensure semantic interoperability and to generate new knowledge that supports decision making in the maintenance process.

Introduction

Industrial maintenance is a fundamental function in the business process and thus requires the development of computer systems [START_REF] Liyanage | Towards a value-based view on operations and maintenance performance management[END_REF]. It covers all domains of a business, from the plant and the equipment to be maintained, to the organization according to different strategies (preventive maintenance, predictive maintenance, corrective maintenance), to managing operators and material (handling, hoisting) and spare parts, to the computer-assisted diagnostic systems, to documentation management, etc. Various maintenance support systems and tools have begun to involve and to be essential for maintenance process management to cover all these sub-domains as CMMS, diagnostic support system, prognostic system, resource management systems as (ERP) and other systems. All these systems are currently based on different models that are usually complementary, but sometimes redundant, sometimes incoherent and always heterogeneous.

The principal problem confronted by these systems is to provide the means to move from coexistence to the interoperability and cooperation of different applications within the same environment.

Indeed, different researchers [2,3,4 and 5] are in agreement that Ontology engineering is recognized as the key technology to deal with this. Ontologies specify the semantics of terminology systems in a well defined and unambiguous manner [START_REF] Guarino | Formal Ontology and information systems[END_REF], by formally and explicitly representing shared understanding about domain concepts and relationships between concepts. With Ontology intended meanings of terminologies and logical properties of relations are specified through ontological definitions and axioms in a formal language. The employment of a consistent Ontology is useful because maintenance support systems' users can have identical semantics for all concepts. All maintenance systems share the common Ontology of maintenance, so have an interoperable communication.

Additionally, we consider that a common neutral model is the most feasible solution in maintenance systems to enable data sharing or integration in heterogeneous applications. With a common Ontology model, it is possible for maintenance information to be created once, re-used and enriched during the equipment lifecycle. This reduces maintenance duration by eliminating the need to recreate data models repeatedly and increases maintenance quality by eliminating errors and using experience of previous maintenance activities. Ontology model organizes data and knowledge of a certain domain of interest (application) in a manageable manner. It should contain the definitions of all application objects (e.g. diagnostic, documentation) within that domain, as well as constraints and relationships between objects.

This, sharing of knowledge via the ontology allows to each system to exploit all the knowledge of the other systems. As well, the reasoning methods which can be applied on the ontology provide an added value to this knowledge while it can generate new knowledge that users cannot notice. This generated knowledge can be exploited by all systems and then gives a surplus to maintenance actors usually in the aim to provide the right information in the right format to the Right people to do the Right things at the right time.

For these reasons, we provide in this work (in the scope of SMAC project1 ) a domain ontology of maintenance domain to be shared and integrated in the maintenance platform as well as its integrated applications.

When a new ontology is going to be built, several basic questions arise related to the methodologies, tools and languages to be used in its development process [START_REF] Obrst | Ontologies for Semantically Interoperable Systems[END_REF]. From several methodologies developed to formalize ontologies creation we adopt METHONTOLOGY approach [START_REF] Gómez-Pérez | Towards a Method to Conceptualize Domain Ontologies[END_REF].

In the formalization phase, a UML ontological model is built in collaboration with maintenance experts; this ontology encloses 8 models classified as unavoidable for the maintenance process which are (1) the structural model presenting the equipment composition, (2) the functional model which characterizes different functionalities of the equipment and its components, (3) the dysfunctional model, (4) the event model which defines the triggering event launched after failures and/or degradation, and (5) the informational model which presents various resources (documents, human, software, tools…) related to the equipment and maintenance tasks, (6) the interventional model presenting concepts related to the intervention process, [START_REF] Corcho | Methodologies, tools and languages for building ontologies: Where is their meeting point?[END_REF] teh Strategy model presenting managerial aspects about maintenance strategy and contracts and (8) Process model presenting all technical, administrative and managerial process.

After that, to make the ontology operational, in the implementation phase of METHONTOLOGY we transform the UML model to PowerLOOM, a logic-based representation language for ontology presentation. Some proposed metrics [START_REF] Tatir | Ontology Evaluation and Ranking using OntoQA[END_REF] are then used to characterize the ontological model.

The remainder of this paper focuses the development process of IMAMO (Industrial MAintenance Management Onotlogy). Hence the rest of sections will be organized as follows. Section two is devoted to addresses the first three phases specification of METHONOLTOGY which are knowledge acquisition and conceptualization of the ontology. Section three is dedicated at the development of the formalization reusing and implementation of IMAMO. In section 3, the evaluation phase, a business-oriented approach based on cases of use is adopted to evaluate the ontology at the application level. Finally, we conclude the paper and we give some perspectives and guidelines to future work.

IMAMO development process

Fernandez and al. in [START_REF] Gómez-Pérez | Towards a Method to Conceptualize Domain Ontologies[END_REF] assert that the ontology development process refers to the activities needed in order to build ontologies. In this context, METHONTOLGY has been proposed as a structured method to build ontologies. This methodology includes a set of activities, techniques, and deliverables to be produced after the execution of such activities using the corresponding techniques. The set of activities is {planning, specifying, acquiring knowledge, conceptualizing, formalizing, integrating, implementing, evaluating, producing documents, and maintenance}.

Specification

Domain

Knowledge acquisation

Creating an ontology is not a trivial task. It requires not only the skills of information technologies but also a significant knowledge in the modeled domain [START_REF] Frankovič | The role of ontology in building of knowledge systems for industrial applications[END_REF]. Hence, as mentioned in the specification document, we based our knowledge acquisition on standards, research projects and industrial experts in maintenance. Concerning standards, we adhere to the AFNOR norms and MIMOSA standards. The PROTEUS and PROMISE projects also serve as a base. Finally, we adopt the business expertise of various maintenance experts, managers and operators from different companies such as Cegelec SA France & Germany, Tornos (Switzerland), Peugeot (Belfort, France) and em@systec (France). Various research works such as [11, 12 and 13] are also taken into account.

AFNOR defines maintenance as "the combination of all technical, administrative and managerial actions during the life cycle of an item intended to retain it in, or restore it to, a state in which it can perform the required function". In concordance with this definition, Retour et al. [START_REF] Retour | [END_REF] present the maintenance function as a set of activities grouped into two subsets: activities with technical predominance and activities with management predominance.

Consequently, the concepts which should be identified must cover all these layers and activities. To facilitate our identification of concepts, we identified all those concepts related to each layer presented above. Identification of the main concepts of each layer is based on the models of MIMOSA CRIS, the PROTEUS project and the PROMISE SOM and SMAC projects.

Conceptualization

In this phase, Gomer-Perez et al recommend a set of intermediate representations for conceptualizing a domain ontology of objects [START_REF] Gómez-Pérez | Towards a Method to Conceptualize Domain Ontologies[END_REF].

Glossary of terms and data dictionary

Hence, we begin the conceptualization of IMAMO by building the glossary of terms. The concepts are first classified in the glossary respecting the four layers identified by Rasovska et al. presented above. We then refined this list of concepts by deepening the first classification. The second classification goes further than the first by breaking each layer down into sub layers. We note that some concepts are redundant in different layers or sub-layers. This is done purposely in order to count all the concepts in each layer so as to obtain a clearer vision and a more precise identification. Next we edit the data dictionary based on the European norm NF EN 13306:2001 published by AFNOR. Due to limits of space we will not show these steps in three separate tables, but we will present only the data dictionary in the formalization phase in order to gain a better understanding of the different models of the ontology (see next sections).

TOTh -2011 -

IMAMO

We note, however, that IMAMO will be a generic ontology; different details can be neglected and left to users according to their needs. In this case, users may adapt, involve and maintain the ontology.

Concept classification trees

After this classification, we edit the concept classification trees. We notice that the domain is very broad; nevertheless, the ontology that we develop will not contain a lot of trees. This is due to the aim of obtaining a rich ontology with different types of relations and not a hierarchical ontology like taxonomy. Is-a, is-componentof, has and other verbs are the relations supported by the ontology. Figure 1 summarizes concept classification trees of resources in IMAMO (i.e. is-a relations).

Fig. 1 -classification trees of resource in IMAMO

Edit rules

As mentioned above, rules will be left to user choice. We give here just some examples of rules that can be edited. We edit these rules by the description logics ALCQHI. Then rules can be translated and edited by the implementation language if it allows rules definition. Rules enrich the Ontology and allow more semantic reasoning as well as understandability.

For example thanks to the following defined rule the identification of critical components is possible without defining a new concept called critical component. The rule describe critical component as any physical equipment having the value of the propriety Functional-degree greats or equals to five.

CriticalComponent PhysicalEquipment 5

Formalization re-use and implementation phases 3.1 Formalization

The Unified Modeling Language (UML) would be a good candidate for representing ontologies and knowledge [START_REF] Cranefield | Networked Knowledge Representation and Exchange using UML and RDF[END_REF]. Knowledge expressed via UML is easily accessible for human comprehension. In an UML model, Knowledge can be changed easily due to the modular nature of object-oriented modeling. Also, new knowledge can be derived from UML models by reasoning about their contents [START_REF] Cranefield | Networked Knowledge Representation and Exchange using UML and RDF[END_REF]. With this standpoint, UML can be regarded as an appropriate candidate for knowledge representation. In this work we adopt the UML class diagram to formalize IMAMO. This choice is argued by the graphical expressivity and the semantics power of UML recommended in the various research works mentioned above. This fact facilitates the exchange between domain experts and the human understanding of the ontology. In the other hand, the ontology of the domain, although formalized independently of the methods of reasoning has a structure which depends on how acquired knowledge will be used for reasoning because experts deliver the knowledge adapted to their reasoning. Reasoning methods will be considered in the implementation phase.

We decompose the class diagram into seven models considered as inescapable for maintenance process according to the layers classification used in the conceptualization phase. These models are:

(1) The structural model presenting the equipment composition; related to the equipment analyses layer.

(2) The event model which define the triggering event launched after failures and/or degradation; related to the fault diagnosis and expertise layer.

(3) The functional and dysfunctional model which characterizes different functionalities of the equipments and its components as well as which is related to the fault diagnosis and expertise layer.

(4) The informational model which presents various resources (documents, human, software, tools, indicators…) related to the equipment and maintenance tasks as well as maintenance strategy and processes; related to resources management and maintenance strategy management layers.

(5) The interventional model presenting concepts related to the intervention process.

(6) The strategy model presenting managerial aspects about maintenance strategy and contracts.

TOTh -2011 -IMAMO [START_REF] Corcho | Methodologies, tools and languages for building ontologies: Where is their meeting point?[END_REF] The process model presenting all technical, administrative and managerial process.

Below we present the tow first models with the data dictionary containing definitions of the modeled concepts. Tangible, instantiated, serialized object, component, device, subsystem, functional unit, equipment or system that can be individually considered to be maintained. A physical equipment may be an entire facility, an entire functioning platform (such as an CH-47 Tail Number XYZ helicopter), or a component piece of equipment, such as a specific instance of a bearing. transportation equipment;

Particular Physical Equipment conveyance. A conveyance which may contain one or more area (s) of production, a set of maintenance teams, and a set of stores. For example: A fishing vessel off the coast has its own decomposition (motor allowing it to move...) as well a production area that cleans the fish and freeze. maintenance tool;

Particular physical equipment that used as tool for performing the maintenance activities. This type of physical equipment has to be maintained also. Component is an exploitation mode that can be played by a Physical Equipment. It has the particularity to be within superior physical equipment (e.g. motor3X57H). exploitation Mode;

Abstraction of a role played by equipment. It presents the state of exploitation that can take a physical equipment. It can be exploited as a component, a production equipment, a spare part or be under repair. equipment under repair mode; Specific exploitation mode affected to a Physical Equipment while it is during repair or located in a maintenance center to be repaired. production equipment mode; Specific exploitation mode affected to a Physical Equipment while it is exploited in a production tasks and/or located in a production area. Spare part mode; Specific exploitation mode affected to Physical equipment intended to replace corresponding physical equipment in order to restore the original required function of the physical equipment. Generally, it is located in a store. equipment location;

Position of a physical equipment in a production area (to locate and track the positions of equipment). area;

Particular geographical region (to manage multisite). sub area;

Region that makes up part of an area. site;

Place or setting of something. An area or plot of ground with defined limits on which a building, project, park, etc., is located or proposed to be located. Environmental or functional requirement defined to supervise (monitoring task) a specific physical equipment or a place (e.g. site) by the use of sensors and data acquisition systems. triggering event;

Something that happens at a given physical equipment and time that triggers a specific process of maintenance which is work request process. alarm;

Type of triggering event launched from a data acquisition system indicating that there is a measure from a sensor violating some conditions about a specific equipment or environment. improvement request;

Triggering event about a specific or general asking for the improvement of a physical equipment.

Knowing that an improvement is the combination of all technical, administrative and managerial actions, intended to ameliorate the dependability of a physical equipment, without changing its required function. event observed by user;

Type of triggering event about a dysfunction on a physical equipment observed by user which is a human resource. notification;

Type of triggering event informing about future events as planned maintenance or the prognostic RUL. prognostic;

Type of notification composed by the health status at a future time and the remaining useful life (RUL) of a physical equipment. It is the output of the prognostic tool. Prognostic tool; Software too or system allowing to predict and estimate the rest of time to failure and the risk of subsequent existence of one or more failure modes with a confidence level which is a value indicating the degree of certitude that the prognosis is correct. Maintenance scheduler;

Type of software resource that allows planning, allocation of significant amount of time, and high degree of coordination between different departments, and is typically initiated through a work order. It is considered as a software resource. Tab3-Data dictionary of event model

Reusing: integration and merge

While ontologies are built to be reused, Ontology reuse is one of the important issues in ontology construction. According to Pinto et al there are two different reuse TOTh -2011 -IMAMO processes [START_REF] Pinto | Some Issues on Ontology Integration[END_REF]: merge and integration. Both of these reuse processes are included in the overall process of ontology building. Merge is defined as the process of building ontology in one subject reusing two or more different ontologies on that subject [START_REF] Pinto | Some Issues on Ontology Integration[END_REF]. Otherwise, in an integration process source ontologies are aggregated, combined, assembled together, to form the resulting ontology, possibly after reused ontologies have suffered some changes, such as, extension, specialization or adaptation. We should note that both processes are adopted in this work.

To create IMAMO we started from models developed in PROTEUS project, we involved a first version of maintenance ontology published in [START_REF] Karray | towards a maintenance semantic architecture[END_REF]. This ontology, is composed by 62 concepts and 70 relations integrating the main concepts used in PROTEUS. Then, in the scope of SMAC project [17] we have done a mapping between this ontology with the PROMISE model. As result of this work, Matsokitis and Karray [18] proposed an involved version of this ontology by orienting it to maintenance field when integrating some concepts related to the maintenance area included in the MOF phase of PLM. This ontology called SMAC-model is formalized by UML and implemented with OWL-dl via PROTÉGÉ tool.

Then, we come back to maintenance scope, we integrating some concepts from SMAC-model related to the life cycle of equipment to take into account the beginning of life part concerning the design phase as well as the middle of life phase by tracking all the events and health states of the equipment and the end of life by the calculation of indicators supporting decision for reuse and disassembly. An example of some reused concepts integrated in IMAMO is presented in the next table. In addition, as mentioned above, MIMOSA-CRIS is considered as the reference of the domain, for this reason, when creating IMAMO we taken account classes used in this model. A mapping between MIMOSA-CRIS and IMAMO is done, some labels of reused concepts are changed but the alignment between these concepts is added as equivalence or subsumption rules after the mapping between the two ontologies.

IMAMO Concepts

From which ontology? In the other hand, other integration is possible as of the functional ontology proposed by Mizoguchi et al [START_REF] Kitamura | Functional Ontology for Functional Understanding[END_REF]. This ontology can be integrated under the concept Function The ontology of faults presented by Kitamura et al [START_REF] Kitamura | An Ontological Analysis of Fault Process and Category of Faults[END_REF] can be integrated to involve the dysfunctional model of IMAMO. As well as, task ontologies as the one presented in [START_REF] Ikeda | Task Ontology Makes It Easier To Use AuthoringTools[END_REF] by Ikeda et al can be integrated under the concept Task.

Implementation

We translate the UML model of IMAMO to PowerLoom. We chose to work with PowerLoom version 3.2.0 despite version 4.0 is actually available because the version 3.2.0 is a stable version unlike to the forth version which is a beta version yet.

In addition, we note that a PowerLoom exporter for the Protégé editor has been implemented. It can write ontologies using the Protégé frame language in Power-Loom, either fully native or with support for the system concepts from Protégé. Moreover The PowerLoom GUI (or knowledge editor) a Java-based graphical client for PowerLoom is now standardly included and available with PowerLoom starting with version 4.0 [22].

We present in the following a part of the structural model of the equipment implemented by PowerLOOM. Each UML class is translated into a PowerLOOM concept using "DEFCONCEPT" command. Associations and attributes of classes are translated into PowerLOOM relation or function using "DEFFUNCTION" and "DEFRELATION" commands.

Evaluation and maintenance

The aim of our evaluation is to highlight the added value of IMAMO to maintenance systems and actors as well as in order to provide new users with sufficient information to promote the exploit of this ontology (the extent of the maintenance domain coverage). Another aim of this evaluation is to focus the weak points of this ontology to facilitate maintenance and evolution tasks.

Our approach of evaluation is composed on two main steps [START_REF] Brank | A survey of ontology evaluation techniques[END_REF]: the quality of the formalization model and the business oriented evaluation containing the evaluation of applicability, efficiency and simplicity for interoperability.

Quality of the model

In accordance with Tartir et al [START_REF] Tatir | L'ontologie développée peut être exploité pour assurer l'interopérabilité sémantique et de générer de nouvelles connaissances qui supporte la prise de décision dans le processus de maintenance[END_REF], assessing the quality of an Ontology is important for several reasons including allowing the Ontology developer to automatically recognize areas that might need more work, allowing the Ontology user to know what parts of the Ontology might cause problems. Different dimensions are available to assess the quality of an ontology. We are interesting to quality metrics presented by [START_REF] Tatir | L'ontologie développée peut être exploité pour assurer l'interopérabilité sémantique et de générer de nouvelles connaissances qui supporte la prise de décision dans le processus de maintenance[END_REF]. We use metrics of schema evaluation to evaluate the success of the Ontology UML model of real-world domain of maintenance. How classes are organized, the depth, the richness, breadth, and height balance of the Ontology schema inheritance tree can play a role in a quality assessment.

To understand used metrics and bellow discussion please refers to [START_REF] Tatir | L'ontologie développée peut être exploité pour assurer l'interopérabilité sémantique et de générer de nouvelles connaissances qui supporte la prise de décision dans le processus de maintenance[END_REF]. We notice that the UML class diagram of IMAMO contains 187 Relations (P), 103 Concepts (classes) (C), 60 Subclasses (SC) and 40 Attributes (att).

The first metric is called Relationship Richness (RR). This metric reflects the diversity of relations and placement of relations in the Ontology. The RR of our ontological model is 75%. It exceeds largely the average. This means that our Ontology is not a hierarchic Ontology. It is not just a hierarchy of subclasses but it maintains a balance between inheritance relations and role associations. This is due to the inclusion of domain concepts and proves that the ontological model is business oriented and responds to business needs of maintenance.

The second used metric is called Attribute Richness (AR). The number of attributes that are defined for each class can indicate both the quality of Ontology design and the amount of information pertaining to instance data. In general we assume that the more slots that are defined the more knowledge the Ontology conveys. The AR of IMAMO is 0.38. This result shows the poverty of the ontological model in terms of attributes. The result gives as average 0.38 attributes per concept which is very low. This is known to us from the beginning because when constructing the model we focus our interest on the concepts presentation and not its details information by the identification of attributes. Although we know that these details are very interesting for the quality and richness of the Ontology, this is a very difficult to implement because the Ontology must use expressive and unambiguous terms. In this context, it is a difficult task to be generic more than in the context of concepts. However, in our future work, collaborations with business experts are envisaged to identify attributes that may be generic for related maintenance concepts (e.g. details of classes of the UML ontological model).

The third used metric is called Inheritance Richness (IR). This measure describes the distribution of information across different levels of the Ontology's inheritance tree or the fan-out of parent classes. This is a good indication of how well knowledge is grouped into different categories and subcategories in the Ontology. This measure can distinguish a horizontal Ontology from a vertical Ontology or an Ontology with different levels of specialization. The IR obtained of IMAMO is 0.58. This result is near to the average. This shows that in the context of knowledge details, our Ontology maintains the balance between generality and explicitness. The ontological model is hybrid; it is neither vertical nor horizontal. We consider this result as a reached target, because our first goal was to build a generic ontological model to the maintenance domain, but at the same time not very light, so that it covers as possible all maintenance aspects (concepts).

Business evaluation of the ontology 4.2.1 Application use case

The application and tests IMAMO was done on the pallet transfer system. It represents a flexible production system. It is composed of five robotized working stations which are served by a transfer system of pallets organized into double rings (internal and external). Each station is equipped with pneumatic actuators (pushers, pullers and indexers) and electric actuators (stopper) as well as a certain number of inductive sensors (proximity sensors). An inductive read/write module allows to identify and locate each pallet and to provide information relative to required operation in a concrete station. The working station is situated on the external ring and contains pneumatic and electric actuators (puller, pusher, indexer, and stopper) as well as inductive sensors.

The following PowerLOOM code specifies how we can assert the PHYSICAL-EQUIPMENT SISTRE, the EQUIPMENT-MODEL PLATEFORME, as well as associations PHYSICAL-EQUIPMENT-CONSTRUCTOR "Bosch" of SISTRE, the top-model EQUIPMENT-HAS-TOP-MODEL of SISTRE which is PLATEFORME and the association EQUIPMENT-COMPONENT-COMPOSED to describe the composition of the physical equipment SISTRE: TOTh -2011 -We provide a second example concerning two maintenance systems S1 and S2. The first uses the MIMOSA-CRIS model, and the second uses IMAMO. The equipment SISTRE fails. S1 sends an intervention request to S2. S2 needs all information about the equipment composition and previous intervention on the equipment. An equipment is modeled by the concept ASSET in the MIMOSA-CRIS model. In IMAMO an equipment is defined by the concept PHYSICAL-EQUIPMENT. We show a sequence of PowerLOOM examples to demonstrate how the reasoning engine can solve this problem and how it manages to get the information expected (needed) by S2.

Firstly we ask the PowerLOOM system of the Ontology used in S2 to list all equipment which it knows, after that if it knows that SISTRE is an equipment:

ONTOLOGIE-MAINTENANCE |= (RETRIEVE ALL (PHYSICAL-EQUIPMENT ?PE))

There are 3 solutions: #1: ?PE=TEST02 #2: ?PE=TEST01 #3: ?PE=TEST

ONTOLOGIE-MAINTENANCE |= (ASK (PHYSICAL-EQUIPMENT SISTRE)) UNKNOWN ONTOLOGIE-MAINTENANCE |= (ASK (not (PHYSICAL-EQUIPMENT SISTRE))) UNKNOWN

So the system of S2 doesn't know if SISTRE is an equipment. To ensure an understandable exchange between S1 and S2, it suffices to add in the knowledge base an equivalence rule defining ASSET as a concept equivalent to PHYSICAL-EQUIPMENT. This will allow to S2 to get all information about all concepts having as type ASSET.

(DEFCONCEPT PHYSICAL-EQUIPMENT ((?A ASSET))) (DEFCONCEPT ASSET ((?PE PHYSICAL-EQUIPMENT)))

After that we assert that SISTRE is an ASSET (ASSERT (ASSET SISTRE))

When we ask if ASSET is physical equipment the reasoning engine answer true:

ONTOLOGIE-MAINTENANCE |= (ASK (PHYSICAL-EQUIPMENT SISTRE)) TRUE

So, when the S2 system considers that ASSET as PHYSICAL-EQUIPMENT, it can obtain composition information of SISTRE from S1 while the two systems shares the same knowledge base.

Conclusion

Maintenance domain contains a variety of maintenance support systems and tools covering all its sub-domains. Contrariwise the largest part of these systems are based on different models that are sometimes incoherent and always heterogeneous. To respond this problem, we propose to create a domain ontology for industrial maintenance that we called IMAMO (Industrial MAintenance Management Ontology).

In this paper we presented the development lifecycle of IMAMO. From various exiting methodology of ontology construction, we adopted METHONTLOGY approach to manage the lifecycle of our maintenance ontology.

To develop this ontology, we are based on different standards and previous projects elaborated in the domain of industrial maintenance. The formalization of the ontology is done via UML class diagram which provides a rich conceptualization of the complex domain of maintenance accompanied by the data dictionary. To be operational, a logic-based representation language called PowerLOOM characterised by its power and efficient reasoning engine is used to implement IMAMO. Afterwards, different approaches are applied to evaluate the proposed ontology in two levels. The first one is to characterize the ontological model and the functional quality of the ontology. The second level is applied in order to show how IMAMO can resolve semantic interoperability problem.

Concerning shortage of this work needed to be addressed in future work, more collaboration with maintenance experts from industrial and academic communities to evolve and enrich the proposed ontology is needed. In addition, as perspectives, we aim set up of a web site containing documentation about the ontology and allowing the possibility to make maintenance and evolution activities.

Fig 2 -

 2 Fig 2-Structural model

  view of physical composition of the equipment. It is composed by the various components models of the components composing a physical equipment. component model; Conceptual view of a component (e.g. model of electrical motor). Component mode;

  or supply reserved of physical equipment for future use. production area; Specific area to do production tasks. period; Time interval. functional period; Typical period during which the equipment must perform certain functions. Tab 2 -Data dictinary of the structural model

Figure 3

 3 Figure 3-Event model

(

  DEFMODULE "/PL-KERNEL-KB/PL-USER/ONTOLOGIE-MAINTENANCE" :DOCUMENTATION "Module for Maintenance" :INCLUDES ("PL-USER")) (IN-MODULE "/PL-KERNEL-KB/PL-USER/ONTOLOGIE-MAINTENANCE") (IN-DIALECT :KIF) (DEFCONCEPT COMPONENT) (DEFCONCEPT PHYSICAL-EQUIPMENT) (DEFRELATION PHYSICAL-EQUIPMENT-ID ((?C PHYSICAL-EQUIPMENT) (?ID STRING))) (DEFRELATION PHYSICAL-EQUIPMENT-TYPE ((?C PHYSICAL-EQUIPMENT) (?TYPE STRING))) ………. (DEFCONCEPT EQUIPMENT-MODEL) (DEFRELATION EQUIPMENT-HAS-TOP-MODEL ((?E PHYSICAL-EQUIPMENT) (?MG EQUIPMENT-MODEL))) (DEFRELATION EQUIPMENT-MODEL-INHERITS ((?MG1 EQUIPMENT-MODEL) (?MG2 EQUIPMENT-MODEL))) (DEFRELATION EQUIPMENT-COMPONENT-COMPOSED ((?E PHYSICAL-EQUIPMENT) (?C COMPONENT))) TOTh -2011 -IMAMO (DEFRELATION EQUIPMENT-COMPOSED ((?E PHYSICAL-EQUIPMENT) (?COM PHYSICAL-EQUIPMENT)))

TOTh

Table 10 -

 10 Example of reuse table

	Physical equipment	PROMISE: Product --MIMOSA-CRIS: Asset
	Equipment Model	MIMOSA-CRIS: Model --PROMISE: As-designed-product
	Equipment group	MIMOSA-CRIS: Asset type --PROMISE: product group
	Site	MIMOSA-CRIS: site -SMAC-Model: Location site
	Triggering event	MIMOSA-CRIS: Event type --PROMISE: Event
	Measure	MIMOSA-CRIS: Measurement Event --PROMISE: Field
		Data
	Equipment location / Geo-	MIMOSA-CRIS: Geoposition
	location system
	Alarm	MIMOSA-CRIS: Alarm type -SMAC-Model: Alarm
	Process pattern	MIMOSA-CRIS: Work Management Type --SMAC-model:
		process

http://smac.univ-fcomte.fr TOTh -2011 -

Acknowledgment

This work was carried out and funded in the framework of SMAC project (Semantic-maintenance and life cycle), supported by Interreg IV programme between France and Switzerland.

The java API of PowerLOOM gives the possibility to query the knowledge base (e.g. assertion of the Ontology). In this example we ask PowerLOOM engine to list all Physical equipment. The given answer is not just the physical equipment SISTRE but its composition. In our Ontology we defined that a Physical-equipment can be composed by Physical-equipments.

PL-USER |= (load "ontologie-maintenance.plm") PL-USER |= (in-module "ONTOLOGIE-MAINTENANCE") ONTOLOGIE-MAINTENANCE |= (RETRIEVE ALL (PHYSICAL-EQUIPMENT ?PE))

There are 28 solutions: #1: ?PE=COURROIE #2: ?PE=CONVOYEUR #3: ?PE=DETECTEUR #4: ?PE=ACTIONNEUR #5: ?PE=TEST ………… #28:?PE=TAP-INT

The second example show how PowerLOOM reasoning engine take account inheritance (subclasses). We launch a query to list all ACTIONNEUR and then we launch a query to ask only ACTIONNEUR-ELECTRIQUE. The first answer includes the answer of the second query due the sub-class relation.

ONTOLOGIE-MAINTENANCE |= (RETRIEVE ALL (ACTIONNEUR ?