design and development of a maintenance knowledge- base
TRANSCRIPT
Design and Development of a Maintenance Knowledge-
Base System Based on CommonKADS Methodology
Alireza Arab Maki
Navid Shariat Zadeh
Master Thesis
Department Production Engineering and Management
School of Industrial Engineering and Management
Royal Institute of Technology
SE-10044 Stockholm, Sweden
June 2010
Abstract
The objective of this thesis is to design and develop a knowledge base model to support the
maintenance system structure. The aim of this model is to identify the failure modes which
are the heart of maintenance system through the functional analysis and then serves as a
decision support system to define the maintenance tasks and finally to implement a preventive
maintenance task. This knowledge base management system is suitable to design and develop
maintenance system since it encompasses all necessary steps in maintenance area. Moreover,
it is capable of being integrated with other knowledge base systems. The structure and the
environment of this knowledge base system is flexible to allow users to deploy different kinds
of tools which they will. It is also a well structured approach to develop, debug, upgrade and
trace.
In this thesis, the CommonKADS methodology is used as the knowledge base methodology.
At the first step, a knowledge base system is developed to create the maintenance system
infrastructure. To implement this, Reliability-Centered Maintenance (RCM) has been chosen
as the method to design a maintenance system. In order to make it more specified, a Spindle
subsystem is taken as a case study to make the model clearer. Secondly, another knowledge
base system is developed for decision making process to select the suitable maintenance task
and finally, a general knowledge base model is developed for condition-based monitoring on
Spindle.
In chapter 1, background, previous works and gap analysis have been surveyed. Then in
chapter 2 the methodology and tools have been discussed and described. Design and
development the knowledge base for maintenance system is described in detail in chapter 3
and finally in chapter 4, the conclusion and the future works are presented.
Keywords: Knowledge base systems, CommonKADS methodology, Maintenance, Condition-
based Monitoring (CBM), Reliability-Centered Maintenance (RCM)
Acknowledgement
During the work with this thesis, we have received a lot of help from Mr. Jerzy Mikler as our
thesis supervisor. We would like to express our sincere gratitude to him. Also we would like
to thanks the officials of Production Engineering and Management department for preparing
appropriate environment to work and research. We want to thank our parents for their
financial and never ending support, for the help in our studies and for its success.
Alireza Arab Maki and Navid Shariat Zadeh
Stockholm, June 2010
Table of Contents
Chapter 1 – Introduction
1 Introduction …………………………...…………………………………………... 2
1.1 Background ……………………………………………………………………...... 2
1.2 Previous Researches …………………..…………………………………………... 3
1.2.1 Condition-Based Monitoring ……………………………………………………... 3
1.2.2 CBM using Neural Network ………….…………………………………………... 5
1.2.3 CBM using Bayesian Network ……….…………………………………………... 7
1.3 Gap Analysis ………………………….…………………………………………... 10
1.4 Thesis Objectives ……………………..…………………………………………... 11
1.5 Delimitation …………………………..…………………………………………... 11
Chapter 2 – Methodology and Tools
2 Methodology and Tools …………………………………………………………... 13
2.1 The Methodology ……………………..…………………………………………... 13
2.1.1 Model Structure …………………………………………………………………... 13
2.1.2 Some Terminology ………………………………………………………………... 16
2.1.3 Organizational Model ………………...…………………………………………... 16
2.1.4 Impact and Improvement Analysis: Task and Agent Modelling …………..……... 19
2.1.5 Recommendations and Actions ……….…………………………………………... 23
2.1.6 Knowledge Model …………………….…………………………………………... 23
2.1.6.1 Role of Knowledge Model ………………………………………………………... 23
2.1.6.2 Knowledge Model Overview ……………………………………………………... 23
2.1.6.2.1 Domain Knowledge …………………..…………………………………………... 24
2.1.6.2.2 Inference Knowledge ……………………………………………………………... 25
2.1.6.2.3 Task Knowledge ……………………………...…………………………………... 25
2.2 Reliability-Centered Maintenance (RCM) ………………………………………... 27
2.2.1 Background …………………………...…………………………………………... 27
2.2.2 Functions ……………………………...…………………………………………... 28
2.2.3 Functional Failure …………………….…………………………………………... 28
2.2.4 Failure Modes ………………………...…………………………………………... 28
2.2.5 Symptoms and Consequences …….…………………..…………………………... 28
2.2.6 Failure Management Techniques ……..…………………………………………... 29
2.2.7 Task Selection Process ………………..…………………………………………... 29
2.3 Integrated Condition Monitoring and Fault Prognosis .…………………………... 31
2.3.1 Measurable Parameters ……………….…………………………………………... 32
2.3.2 Selection of Proper CBM Equipment ...…………………………………………... 32
2.3.2.1 Energized Testing …………………….…………………………………………... 32
2.3.3 The System to Analyze the Collected Data ..……………………………………... 33
2.4 CUSUM Control Charts …………………………………………………………... 33
2.4.1 Description ………………………………………………………………………... 34
Chapter 3 - Design and Develop the Knowledge Base for Maintenance System
3 Design and Develop the Knowledge Base for Maintenance System ……………... 36
3.1 General Description …………………..…………………………………………... 36
3.2 Organization Model Analysis ………...…………………………………………... 36
3.3 Knowledge Intensive Task Model Analysis ………….…………………………... 39
3.3.1 Task 2 - Analyze the Machinery and Determine the Failure Modes ……………... 39
3.3.2 Task 3 - Realizing the Maintenance Task .………………………………………... 54
3.3.3 Task 5 – Implementation Of Preventive Maintenance Task .……………………... 61
Chapter 4 - Conclusion and Future Works
4 Conclusion and Future Works ………..…………………………………………... 86
4.1 Conclusion ………………………………………………………………………... 86
4.2 Future Works ……………………………………………………………………... 86
Appendix A – FMEA of Spindle System …...….………………………………………... 87
References …………………………………………..………………………………………... 89
2
Chapter 1 – Introduction
1 Introduction
1.1 Background In order to run a successful manufacturing company, continuous improvement must be
considered and implemented in the areas of safety, quality and reliability. To achieve this, one
of the most important processes which must be subject of improvement is maintenance
process. Improvement of safety, quality, reliability and dependability in a plant is directly
associated to the maintenance system in a company. Amelioration in these areas will result in
cost reduction and more internal and external customer satisfaction which helps to create a
competitive market. Moreover, it has been proved that the maintenance cost is one of the main
parts of life cycle cost of a product or asset.
There are two main types of maintenance task:
- Corrective maintenance: The strategy behind this approach is to let the equipment
fail (also called run to failure) and then start to cover the damaged equipment. This
approach is suitable just in case that the equipments’ failures’ consequences are not
neither safety nor environmental.
- Preventive maintenance: The strategy behind this approach is to maintain the
equipment before the failure occurs. This approach has two main methods like time-
based maintenance and condition-based monitoring. This approach is suitable when an
unplanned stoppage of the equipment result in high equipment downtime, high cost of
repairing equipment, extensive repair time and high penalty associated with the loss of
production which all decrease the effectiveness and efficiency of the factory
dramatically.
Nowadays, the question is that how to design a maintenance system and make a decision
about the suitable maintenance strategy. There are many methods to achieve the mentioned
purpose. Failure Mode and Effect Analysis (FMEA) has been used to analyze all the possible
failure modes. Statistical analysis using the historical data has been used for time-based
maintenance and recently thanks to the technological improvement in the areas of sensors,
data capturing and analysis software and hardware; many plants utilize computer control
systems for condition-based monitoring of their equipments. Also, Reliability-Centered
Maintenance (RCM) technique has been adopted as a strong method to analyze the functions,
functional failures, failure mode and consequences. This technique includes decision rules to
determine different maintenance tasks such as redesign, run to failure, scheduled restoration,
etc.
3
Implementation and application of such method for maintenance result in generating huge
amount of data, information and knowledge which must be managed in a proper way. This
information management must contain generating, storing, analyzing and dispatching the data
among whole process. The main works which are done in this area are briefly presented in
next section (1.2) however; the lack of a well-structured comprehensive model to design and
implement a maintenance management system is noticed. Therefore, the aim of this thesis is
to design a knowledge base management system in maintenance area which encompasses
necessary tasks in the areas such as failure mode analysis, maintenance task decision making
and finally supporting the implementation of selected task.
To achieve this goal, the following methodology, techniques and assumption are used in this
thesis:
CommonKADS Methodology: This methodology is used to deal with the knowledge base
management and it is described in Chapter 2. The reasons to choose this methodology are:
- Gradually extension of the methodology as a result of feedback from practitioner and
scientists over the years,
- It is not a technology-push approach
- Its ability to model the complex systems taking easy steps.
Reliability-Centered Maintenance (RCM) Technique: As described in Chapter 2, this
technique has been chosen because of its interesting nature of analysis which starts from the
system functions and allow to define failure modes.
Condition-Based Monitoring (CBM): This method is a dynamic preventive maintenance
which is able to online monitoring of systems and detects degradation on components in early
stages. Thus, one of its techniques called multi-sensor and multi-parameter condition
monitoring and fault diagnosis is chosen to design the knowledge base management system.
To show how to implement this knowledge based maintenance system, a spindle system has
been chosen as a case study.
1.2 Previous Researches
Many researchers and authors designed and developed knowledge based systems in
maintenance area. These knowledge based systems are called expert systems in their
researches literature. Most of the jobs which are done in this area can be categorized into three
areas of Condition-Based Monitoring (CBM), condition-based monitoring (CBM) using
neural network and condition-based monitoring (CBM) using Bayesian networks.
1.2.1 Condition-Based Monitoring
Condition Based Monitoring or CBM is a type of preventive maintenance (PM) where, it
monitors the condition of specific areas of plant and equipment. This can be done
4
automatically with the use of instrumentation such as machinery vibration analysis and
thermal imaging equipment or manually. This is particularly suited to continuous process
plants where plant failure and downtime can be extremely costly. During the past years, CBM
has totally changed thanks to measurement technology development [1]. In order to develop a
CBM system, the following steps are taken:
Step 1 - Identifying the parameters to monitor: In order to determine the monitoring
requirements, first the failure modes which would be expected to find must be listed.
Secondly, the measurable parameters which can show the presence of approaching failures
should be identified. This is usually done by vibration analysis, temperature and pressure
analysis [2].
Step 2 - Determining the way to measure and measurement instruments
Step 3 – Identifying the monitoring strategy: These strategies include setting of alarm limit
for an unacceptable percentage change in a parameter value and parameter or data that
deviates from normal operating conditions.
Elements of a typical CBM system are as below [1]:
- Database: Since a huge volume of data is generated in CBM, the existence of a database is
necessary to store and retrieve the monitoring information.
- Routs: The major advance in recent years in collection of CBM data has been the advent
battery power data collector. These are digital instruments which are able to be programmed
with a series of criteria for each measurement point. The effect of these data collectors has
been to minimize the amount of interactions required by a user in collecting machinery
condition information. A major example of this, is the organization of data, which are desired
to be collected, into a logical sequence or route around the machines. The essential element of
the route management is the scheduling of the right measurement at the right time.
- Data Input: Although the data collector can collect the vast majority of data, there is a need
to integrate the data from other sources.
- Reports: a major focus of the maintenance system is to provide information on machine
problems at the earliest possible time and ignore all data on machines that are operating
within normal bonds. Communication of the information that a machine is showing abnormal
behaviour is usually achieved through a report [3].
- Plots: when a condition indicator shows deviation beyond the expected norms, the next
stage is usually investigation of the exceptions. This investigation must firstly verify that it is
indeed a steady trend toward the break down and secondly determine the cause of the
deviation. To do this, spectrum pictures including plots known as waterfall maps showing
historical spectrum data are used. This is especially suitable when vibration is a parameter in
CBM.
5
1.2.2 CBM using Neural Network
Artificial neural network simulation can be defined as a parallel distributed processor that can
store experimental knowledge and make it available for future use. The knowledge is obtain
through a learning process and stored in inter-neuron connection strength which are called
synoptic weights. This learning process can be supervised or unsupervised with respect to
pattern classification. Supervised learning is used when the classification of all training input
pattern is known. For example each training pattern would be classified as a normal mode
pattern or a pattern representing one of the fault modes. This is the context of fault diagnosis
problem which must be investigated. Figure 1.1 shows the general approach to use the neural
network in CBM.
R. P. Leger et. al., 1996 [4] used artificial neural network for fault detection and diagnosis.
Their proposed FDD strategy was tested on a model of heat transport system of a CANDU
nuclear reactor. Their model monitored the temperature, flow and pressure of different
components of a nuclear reactor. Adyles Arato Junior et. al., 2010 [5] designed a neural
network model which uses vibration signals in order to condition-based monitoring of a
power plant. Their model is able to detect the faults in early stages and automatic diagnosis of
the root causes. R. C. M. Yam et. al., 2001 [6] used a CBM system by adding the capability of
intelligent condition-based fault diagnosis and the power of predicting the equipment
deterioration. Chang-Ching Lin and Hsien-Yu Tseng, 2004 [7] used a neural network
application for reliability modelling and condition-based predictive maintenance. They
quantified the time between maintenance (TBM) using the Weibull distribution. The
difference between this application and traditional Weibull analysis is that they assumed a
reliability parameter as the output of neural network [8].
Figure 1.1 – Neural Network in CBM general approach
6
Neural networks which are used in CBM, belong to two main categories. The first one can
store sequential information in the form of historical data and can be used in forecasting. For
example, in an recurrent neural network (RNN) as shown in figure 1.2, the input nodes are
taken as the value of the current condition Xt and values of previous time-series condition
(Xt-1, Xt-2, Xt-3, …, Xt-d, …, and Xn). The value of the output (X’t +1) can provide a one-step
ahead prediction of a time-series condition, which is a function of the current value Xt and
time-lagged values of the previous condition (Xt-1, Xt-2, …, Xt-d, …, and Xn). This model is
suitable when the condition-based monitoring is done based on one parameter such as
vibration. The predicted value X’t +1 of a time series, one-step ahead in the future, is given as:
X’t +1 = F(Xt-1, Xt-2, Xt-3, …, Xt-d, …, and Xn)
where,
d is time lag
X’t +1 is the predicted value
Xt is the value of current condition
Xt-d is the values of previous condition lagged by time d
The intermediate neuron may be represented mathematically by the following equations:
∑=
=p
j
jkjkxw
0
υ ( )kk
y υφ=
where
p = total number of inputs to neuron k,
wkj = input weights to neuron k,
Xj = output values from the previous layer,
vk = input to the transfer function of neuron k,
ø = transfer function of neuron k,
yk = output from neuron k.
The second category has the same structure but the intermediate nodes can be of several
layers and the inputs can be the status different parameters [9].
Neural Network is a strong approach for trend prediction in condition based monitoring
however it should be trained by either historical data of a machine in a normal condition or
defining some fault scenarios which both lead to increase the uncertainty of the model.
7
Figure 1.2 – Neural Network with three layers used for fault trend prediction. The nodes in the first layer
show the parameter value in the predefined time lags and the last node in the third layer shows the
predicted value.
1.2.3 CBM using Bayesian Network
In the early stages of maintenance knowledge, many efforts have been taken to quantify the
reliability of systems in order to estimate the time intervals for implementing the preventive
maintenance actions. Traditionally, this is done by gathering the component failure data from
the historical data and estimating probability distribution of components life time, and finally
predicting a components life time by choosing certain reliability. Nowadays, this could not be
the case because of lack of historical failure data since the aim of modern maintenance system
is not to let the equipments run to failure. One of the approaches to deal with this problem is
simulation. Monte Carlo simulation has been applied in the situation of possessing low
amount of information and data [10]. However, in some critical systems such as nuclear
power plants and other power plants, the reliability interaction of different subsystems and
components is so complex which can not be modelled using traditional statistical approach
and Monte Carlo simulation is not suitable. To cope with this problem, when the focus is on
quantifying the reliability, researchers have designed Bayesian Networks using expert
opinions for preventive maintenance.
Bayesian Networks, known as BNs, provide an efficient way to represent the degradation
process of an industrial system or machines. BNs are some graphical model introduced by
Pearl [11] and Lauritzen and Spiegelhalter [12]. BNs represent a relation between graph and
probability theories. The random variable of the probabilistic model is described with the
vertices of the graph where edges describe the dependencies measured by conditional
probability.
G. Celeux et. al., 2005 [13] used a Bayesian Network to present a nuclear plant mechanical
system degradation. By applying the Bayesian Network, they could identify most critical parts
8
with low reliability and analyze the influence of maintenance actions on the reliability of
different components. Haitao Guo et. al, 2009 [14] applied Bayesian network for reliability
analysis of wind turbines with incomplete failure data collected from after the date of initial
installation. H. Boudali and J.B Dugan, 2004 [15] presented a Baysian network reliability
modelling and analysis framework. Their Bayesian network is the discrete time model. They
calculated failure probability and reliability according to discrete time simulation.
Bayesian Networks describe conditional independence and analyze probable casual
relationship between random variables. Figure 1.3 represents a Bayesian Network for a sub-
components of a reactor coolant pump observed on the French nuclear plants. Random
variables are represented by the vertices of the graph and indicate the state of a component i.e.
healthy or damaged.
Figure 1.3 – Bayesian Network of a system degradation process
The above Bayesian Network is built from experts opinions. These Bayesian Network
contains 22 discrete variables. 17 variables are binary and the other five ones have three
states. Variables have been divided in 4 sets. environmental variables A = {PI3,Ad,Ab, PI6,
9
PI4,Ag,DJ, PI2,DI}, degradation variables M = {M1′,M1′′,M2,M3,M4,M5,M6}, observation
variables O = {O1,O2,O2′,O2′′,O5} and finally the variable of interest: the state of the system
(E).
Now some definitions are given as below:
Definition 1: A directed graph is a couple G = (V,E), where V = (X1, . . . ,Xn) denotes the
vertices of the graph and E = (e1, . . . , em) denotes a part of Cartesian product V × V , where
ei is called the edges of the graph.
If (Xi,Xj) lies in E, then this element is called an edge. It is denoted Xi → Xj , Xi is called the
source and Xj the target of the edge. For directed graph, the parents and the children of the
vertices are defined as follows:
Definition 2: If a directed edge has source Xi and target Xj, then Xi is called the parent of Xj
and Xj is called the son or child of Xi. The set of the parents of Xj is denoted pa(Xj) and the set
of children of Xi is denoted ch(Xi).
In a directed graph, the oriented paths are defined as follows:
Definition 3: An oriented path is a set of distinct vertices Xi, . . . , Xj such that (Xk−1,Xk) is an
edge for all k = i + 1, . . . , j. This path is denoted Xi → Xj. A cycle is a path such that Xi = Xj.
Directed graph without cycle are called Directed Acyclic Graphs (DAG).
Now the Bayesian Network is defined as below:
Definition 4: A Bayesian Network is
- a set of variables V , defining the vertices, and a set of edges between variables E,
- each variable has a finite number of exclusive states,
- variables and edges define a directed acyclic graph, denoted G = (V,E),
- for each variable Y with its parents X1, . . . ,Xn, is associated a conditional probability
P(Y | X1, . . . ,Xn). When a variable has no parent, the last quantity becomes a marginal
probability P(Y).
The denomination ”Bayesian Networks” comes from the well-known Bayes theorem. In a
BN, the joint probability can be written as follows (recursive factorization):
( ) ( )( )∏=
=n
i
iin XpaXPXXP1
1,...,
Where pa(Xi) is the set of parents of vertex Xi.
The last node E in figure 1.3, shows the current state of whole system. In order to calculate
this, experts must carefully assign conditional probability of nodes. Then by calculating the
10
conditional probability of different nodes, the most influential components which affect the
whole system reliability are determined. Also it is possible to add another node such as
maintenance tasks in order to analyze their influence on the system reliability.
Bayesian Networks are usable for complex simulation of real world and can hold the
knowledge in form of collections of probability so they can simulate human intuition and
conclusions and are easy to apply for model and simulation tests. They are also readable for
human in contrast to neural networks and preserve knowledge of experts. On the other hand,
they are less exactly that neural networks but more efficient and it is difficult to examine the
solution of the network. Also it is difficult the get the probability knowledge.
1.3 Gap Analysis
By considering knowledge base application in different maintenance tasks which are
explained briefly in previous sections, following shortages could be concluded:
- There is a lack of a suitable standard to design a knowledge base system for
maintenance.
- All the current knowledge base systems concentrate on one area of maintenance
systems such as CBM without considering other tasks of the whole maintenance
system and their interactions. Even in one task like CBM, there are different
knowledge base systems for example to monitor vibration and oil debris there are two
different knowledge base systems because the system vendors are different so they use
different measurement technology and difference knowledge base models.
- Maintenance system is one of the systems in a plant so the maintenance knowledge
base system should be easily integrated with the other knowledge base system in the
plant.
Regarding mentioned shortages it would be worthwhile to create a comprehensive
infrastructure to design a knowledge base system in maintenance area. This system must have
the following characteristics:
- It should have a suitable environment to gather all the methods which are previously
deployed in maintenance area such as neural network, Bayesian Networks, etc.
- It should cover all the maintenance tasks such as failure mode analysis, decision
making on maintenance task and implementation within the maintenance area.
- It should have the potential to upgrade by adding different knowledge base systems
within the maintenance area because designing a knowledge base system in
maintenance area can be implemented gradually not as the same time.
11
- Methodology and methods used to develop such a system must be easy to apply as
well as flexible to use in other knowledge base applications.
- It should be capable to import other knowledge base systems.
- It should have a learning process in order to update itself based on knowledge and
information generated during run time.
1.4 Thesis Objective
In order to design a model which fulfils the above characteristics, it is decided to use the
CommonKADS methodology as the knowledge base model. At the first step, a knowledge
base system is developed to create the maintenance system infrastructure. The aim of this
system is to identify the failure modes which are the heart of maintenance system. To
implement this, Reliability-Centered Maintenance (RCM) has been chosen as the method. In
order to make it more specified, a Spindle subsystem is taken as a case study to make the
model clearer. Secondly, another knowledge base system is developed fro decision making
process to select the suitable maintenance task and finally, a general knowledge base model is
developed for condition-based monitoring on Spindle. This model is general in order to
present the path which should be followed to model more complicated and complex systems.
1.5 Delimitation
Since the technical data, information, drawing and components of the Spindle system were
not available, in this thesis a typical Spindle system and its components has been assumed for
the case study. Since the aim of this thesis is to create a general structure and environment to
design the knowledge base system which satisfies the mentioned characteristics in previous
section, this limitation does not interfere with the objectives of the thesis. In other words, the
proposed model is capable to be customized according to the users needs. Moreover, it is
assumed that the feasibility study results are positive to implement this model.
13
Chapter 2 – Methodology and Tools
2 Methodology and Tools
2.1 The Methodology [16] CommonKADS methodology is consist of a number of elements. These elements are
illustrated in the form of a pyramid. The methodological pyramid has five layers, where each
consecutive layer is built on top of the previous ones shown in Figure 2.1.
There are a number of principles and rules concerning each layer. The significant issue for
developing each layer is to form the baseline and rationale of the approach. These principles
are based on the lessons learned about knowledge-system development.
Knowledge engineering is not some kind of “mining from the expert’s head,” but consists of
constructing different aspect models of human knowledge. [CommonKADS Book]
world view
theory
methods
tools
use feedbackcase studies
application projects
CASE toolsimplementation environments
life-cycle model, process model,guidelines, elicitation techniques
graphical/textual notationsworksheets, document structure
model-based knowledge engineeringreuse of knowledge patterns
Figure 2.1 – CommonKADS Methodological Pyramid
2.1.1 Model Structure Figure 2.2 presents the CommonKADS model structure that is the practical expression of the
principle underlying knowledge analysis. It includes different section of the CommonKADS
knowledge-engineering methodology which should be developed in order to create a
comprehensive knowledge management system.
In order to design and develop any kind of knowledge-based system, the following questions
must be answered:
14
1. Why? Why is a knowledge system a potential help or solution? For which problems?
Which benefits, costs, and organizational impacts does it have? Understanding the
organizational context and environment is the most important issue here.
2. What? What is the nature and structure of the knowledge involved? What Is the
nature and structure of the corresponding communication? The conceptual description
of the knowledge applied in a task is the main issue here.
3. How? How must the knowledge be implemented in a computer system? How do the
software architecture and the computational mechanisms look? The technical aspects
of the computer realization are the main focus here.
Figure 2.2 – The CommonKADS Model Structure
All these questions are answered by developing (piece of) aspect models. CommonKADS has
a predefined set of models, each of them focusing on a limited aspect, but together providing
a comprehensive view:
- Organization model: The organization model analyzes the main characteristics of an
organization in order to find out the problems and opportunities for knowledge
systems. Moreover, it includes the feasibility study and the impacts of the intended
knowledge system on the organization.
- Task model: Tasks are the sub-processes of a business process. The task model
analyzes the task layout, its input and output, preconditions and performances criteria
and the needed resources and competences.
- Agent model: Agents are executors of a task. An agent can be human, an information
system, or any other entity which are able to perform a task. The agent model
describes the features of agents, in particular their competences, authority to act, and
15
constraints in this respect. Moreover, it lists the communication links between agents
in carrying out a task.
- Knowledge Model: The aim of the knowledge model is to determine the types and
structure of knowledge used in executing a task. Also it identifies all the roles of
knowledge-system components contributing in problem-solving. This makes the
knowledge model an important tool to communicate with experts and users about the
problem-solving features of a knowledge system, during both development and system
execution.
- Communication model: Since several agents may participate in a task, it is important
to have communication protocol to present all the transactions between the agents.
This is done by the communication model, in a conceptual and implementation-
independent way, just as with the knowledge model.
- Design model: the above CommonKADS models together can be seen as constituting
the requirements specification for the knowledge system, broken down in different
aspects. The design model presents the specification of the knowledge system in term
of architecture, implementation platform, software modules, representational
constructs, and computational mechanisms which are necessary to implement the
functions in knowledge and communication models.
Together, the organization, task, and agent models analyze the organizational environment
and the corresponding critical success factors for a knowledge system. The knowledge and
communication models create the conceptual description of problem-solving functions and
data that are to be handled and delivered by a knowledge system. The design model converts
this into a technical specification that is the basis for software system implementation. Thus
process is depicted in above figure 2.2. It should be noted, however, it is not necessary to
construct all the models. This depends on the goals of the project as well as the experiences
gained in running the project. Thus, a judicious choice is to be made by the project
management. Accordingly, a CommonKADS knowledge project produces three types of a
products or deliverables:
1. CommonKADS model documents
2. Project management information
3. Knowledge system software
It should be emphasized that knowledge systems and their engineering are not life forms
totally unrelated to other species of information systems and management. In what follows,
we will see that CommonKADS has been influenced by other methodologies, including
structured systems analysis and design, object orientation, organization theory, process
reengineering, and quality management.
16
2.1.2 Some Terminology
All the concepts used in CommonKADS methodology are defined as below:
Domain: Domain is some area of interest. Example domain is maintenance system area.
Domains can be hierarchally structured. For example, maintenance process can be split into
number of subdomains such as functional analysis, failure mode analysis, condition based
monitoring, etc.
Task: A task is a piece of work that needs to be done by an agent. In this research the
primarily interest is in “knowledge intensive” tasks: tasks in which knowledge plays a key
role. Example tasks are functional analysis, functional failure analysis, failure mode analysis,
condition based monitoring and prognosis.
Agent: An agent is any human or software system able to execute a task in a certain domain.
For example, a maintenance staff can carry out the task of diagnosing complaints uttered by
malfunction of the system. A knowledge system might be able in execute the task of
monitoring the spindle of a cutting machine.
Application: An application is the context provided by the combination of a domain and a
task carried out by one or more agents.
Application domain/task: these two terms are used to refer to the domain and/or task
involved in a certain application.
Knowledge-based system: The term “knowledge-based system” (KBS) has been used for a
long time and stems from the first generation architecture in which the two main components
are a reasoning engine and a knowledge base. In recent years the term has been replaced by
the more neutral term “knowledge system”. It is worthwhile pointing out that there is no fixed
borderline between knowledge systems and “normal” software systems. Every system
contains knowledge to some extent. This is increasingly true in modern software applications.
The main distinction is that in a knowledge system one assumes there is some explicit
representation of the knowledge included in the system. This raises the need for special
modelling techniques.
Expert System: one can define an expert system as a knowledge system that is able to
execute a task that, if carried out by humans, requires expertise. In practice the term is often
used as a synonym for knowledge(-based) system.
2.1.3 Organizational Model
The first part of the organization model focuses on problem and opportunities. The issues are
illustrated in figure 2.3. Opportunities, problems and knowledge-oriented solutions must
always be evaluated within a broader business perspective so it is important to get a real and
17
explicit understanding of this context. In order to do this, tables 2.1 (OM-1) and 2.2 (OM-2)
gives the worksheets which explains the various aspects to consider. Table 2.3 (OM.-3) helps
to performing the process breakdown and table 2.4 (OM-4) is used to analyze the knowledge
assets.
Figure 2.3 – Overview of the components of the CommonKADS organization model
Organization Model Problems and Opportunities Worksheet OM-1
Problems and opportunities Make a shortlist of perceived problems and opportunities, based on
interviews, brainstorm and visioning meetings, discussions with managers,
et cetera.
Organizational context
Indicate in a concise manner key features of the wider organizational context, so as to put the listed opportunities and problems into a proper perspective.
Important features to consider are:
1. Mission, vision, goals of the organization
2. Important external factors the organization has to deal with
3. Strategy of the organization
4. Its value chain and the major value drivers
Solutions
List possible solutions for the perceived problems and opportunities, as
suggested by the interviews and discussions held, and the above features of
the organizational context.
Table 2.1 – Problems and Opportunities Worksheet OM-1
Organization Model
Problems &
Opportunities
GeneralContext
(Mission,Strategy,
Environment,CSF's,...)
PotentialSolutions
OM-1 OM-2
OrganizationFocus AreaDescription:
Structure
Process
People
Culture & Power
Resources
Knowledge
OM-3 OM-4
ProcessBreakdown
KnowledgeAssets
18
Organization Model Variant Aspects Worksheet OM-2
Structure Give a structure chart of the considered (part of) the organization in terms of
its departments, groups, units, sections, ...
Process Sketch the layout (for example by a diagram) of the business process at hand.
A process is the relevant part of the value chain that is focused upon. On its
turn, a process is decomposed into tasks, which are detailed in Worksheet
OM-3.
People Indicate which staff members are involved, as actors or stakeholders,
including decision makers, providers, users or beneficiaries (`customers') of
knowledge.
Resources Describe the resources that are utilized for the business process. These may
cover different types, such as: 1. Information systems and other computing resources.
2. Equipment and materials.
3. Social, interpersonal, and other (non-knowledge) skills and competencies.
4. Technology, patents, rights.
Knowledge Knowledge represents a special resource exploited in a business process.
Because of its key importance in the present context, it is set apart here. The
description of this component of the organization model is given separately,
in Worksheet OM-4 on knowledge assets.
Culture and Power Pay attention to the `unwritten rules of the game', including styles of working
and communicating (`the way we do things around here') and informal
influencing relationships and networks.
Table 2.2 – Variant Aspects Worksheet OM-2
Organization Model Process Breakdown Worksheet OM-3
No (identifier)
Task (Task name)
Performed by (agent)
Where? (location)
Knowledge
asset
Knowledge
Intensive?
Significance
Table 2.3 – Process Breakdown Worksheet OM-3
Organization Model Knowledge Assets Worksheet OM-4
Knowledge
Asset
(see OM-3)
Possessed
by Agent
(see OM-3)
Used in
Task
(see OM-3)
Right
Form?
Yes/no
Right
Place?
Yes/no
Right Time?
Yes/no
Right
Quality?
Yes/no
Table 2.4 – Knowledge Assets Worksheet OM-4
19
2.1.4 Impact and Improvement Analysis: Task and Agent Modelling
Task model deals with the global task layout, its input and outputs, prerequisites, performance
criteria, needed resources and competences. Figure 2.4 shows the roles in maintenance
knowledge base system.
Figure 2.4 – Overview of different roles in task definition in designing a maintenance knowledge base system
Different roles in maintenance knowledge base system development are as below:
Knowledge Users: A knowledge user utilizes directly or indirectly of the knowledge system
which in the maintenance area could be the maintenance employees, production workers and
production scheduling staff.
Project Manager: The knowledge project manager is responsible for the project development
of the maintenance knowledge system.
Knowledge Manager: Knowledge manager determines different knowledge strategies at the
business level. The knowledge manager initiates knowledge development and knowledge
distribution activities.
20
In case that the feasibility study outcome is positive, it’s time to take the next step and to
focus on the features of the relevant tasks, the agents that carry them out, and on the
knowledge items used by the agents in executing tasks. For their description, CommonKADS
offers the task and agent models. Figure 2.5 illustrates the CommonKADS task model. The
outcomes of task model is detailed insight into the impact of a knowledge system, and
especially what improvement actions are possible or necessary in the organization in
conjunction with the introduction of a knowledge system.
Figure 2.5 – Overview of the CommonKADS task model
The notion of task has also emerged as a critical one in the theory and methodology of
knowledge systems and of knowledge sharing and reuse. Thus, a link is needed between the
notion of task in the human and organizational sense of the word, and the more information
systems oriented concept will be employed later on. The CommonKADS task model serves as
this linking pin between the organizational aspect and the knowledge-system aspect of a task.
A task is a subpart of a business process that:
- Represents a goal oriented activity adding value to the organization;
- Handles inputs and deliver desired outputs in a structured and controlled way;
- Consumes resources;
- Requires (and provides) knowledge and other competences;
- Is carried out according to given quality and performance criteria;
- Is performed by responsible and accountable agents.
Table 2.5 (TM-1) represents different parts of a task model which should be determined and
explained .
21
Task Model Task Analysis Worksheet TM-1
TASK Task identifier and Task name
ORGANIZATION Indicate the business process this task is a part of, and where in the organization
(structure, people) it is carried out
GOAL AND VALUE Describe the goal of the task and the value that its execution adds to the process
this task is a part of
DEPENDANCY AND
FLOW
Input tasks: tasks delivering inputs to this task
Output tasks: tasks that use (some of) the outputs of this task
You can use a data flow diagram or an activity diagram here to describe this.
OBJECTS HANDLED Input objects: The objects, including information and knowledge items, that are
input to task
Output objects: The objects, including information and knowledge items, that
are delivered by the task as output Internal objects: Important objects (if any), including information and
knowledge items, that are used internally within the task but are not input or
output to other tasks.
You may want to include a class diagram here to describe the information
objects handled by the task.
TIMING AND
CONTROL
Describe frequency and duration of the task.
Describe the control relation with other tasks. For this you may want to use a
state diagram or an activity diagram.
Describe control constraints:
(I) Preconditions that must hold before the task can be executed.
(II) Postconditions that must hold as result of execution of the task.
AGENTS The staff members (cf. OM-2/3, People) and/or the information systems (cf.
OM-2/3, Resources) that are responsible for carrying out the task
KNOWLEDGE AND
COMPETENCE
Competencies needed for successful task performance. For the knowledge
items involved, there is a separate worksheet TM-2. List other relevant skills and competencies here. Indicate which elements of the task are knowledge-
intensive.
Note that tasks can also deliver competencies to the organization, and it may be
worthwhile to indicate that here.
RESOURCES Describe and preferably quantify the various resources consumed by the task
(staff time, systems and equipment, materials, financial budgets)
The description is typically a refinement of the resource description in OM-2
QUALITY AND
PERFORMACE
List the quality and performance measures that are used by the organization to
determine successful task execution
Table 2.5 – Task Analysis Worksheet TM-1
Next item of knowledge and competence is a significant items in the task model. For this
reason, it is again modelled by means of separate worksheet TM-2 as shown in table 2.6. it is
also useful to consider the information from the individual agents point of view. This is done
in commonKADS agent model, illustrated in table 2.7 as AM-1.
22
Task Model Knowledge Item Worksheet TM-2
NAME
POSSESSED BY
USED IN
DOMAIN
Knowledge Item
Agent
Task Identifier and name
Wider domain the knowledge is embedded in (specialist field, discipline;
branch of science or engineering, professional community)
Nature of knowledge Bottleneck / to be Improved?
formal, rigorous
empirical, quantitative
heuristic, rules of thumb
highly specialized, domain
specific
experience-based
action-based
incomplete
uncertain, may be
incorrect
quickly changing
hard to verify
tacit, hard to transfer
Form of knowledge
Mind
Paper
Electronic
Action skill
Other
Availability of knowledge
Limitations in time
Limitations in space
Limitations in access
Limitations in quality
Limitations in form
Table 2.5 – Knowledge Item Worksheet TM-2
Agent Model Agent Worksheet AM-1
TASK Name of the agent
ORGANIZATION Indicate how the agent is positioned in the organization, as inherited from the OM-worksheet descriptions, including the type (human, information system),
function, position in the organization structure, ...
INVOLVED IN List of Tasks (cf. TM-1)
COMMUNICATION
WITH
List of agent names
KNOWLEDGE List of knowledge items possessed by the agent (cf. TM-2)
OTHER COMPETENCES List of other required or present competences of the agent
RESPONSIBILITIES
AMD CONSTRAINTS
List of responsibilities the agent has in task execution, and of restrictions in this
respect. Constraints may refer to limitations in authority, but also to inside or
outside legal or professional norms, or the like
Table 2.6 – Knowledge Item Worksheet TM-2
23
2.1.5 Recommendations and Actions
Finally, with the worksheet TM-1, TM-2, and AM-1 we have controlled all information
related to the task and agent models (See Figure. 2.4 above). The remaining step is to
integrate this information into a document for managerial decision making about changes and
improvements in the organization.
Proposed actions for improvement are accompanying measures, but are not part of the
knowledge systems work itself. However, they are highly important for ensuring commitment
and support from the relevant players in the organization. The major issues for decision
making here are:
- Are organizational changes recommended and if so, which ones?
- What measures have to be implemented regarding specific tasks and workers
involved? In particular, what improvements are possible regarding use and availability
of knowledge?
- Have these changes sufficient support form the people involved? Are further
facilitating actions called for?
- What will be the further direction of the knowledge system project?
This completes the organization task-agent analysis. Even without building knowledge
systems, it is likely that this analysis brings to the surface many measures and improvements
that lead to better use of knowledge by the organization.
2.1.6 Knowledge Model
2.1.6.1 Role of the Knowledge Model
Detailed requirements engineering is split in CommonKADS into two parts. The knowledge
model specifies the knowledge and reasoning requirements of the prospective system, the
communication model specifies the needs and desires regarding to the interfaces with the
other agents. Figure 2.6 illustrates the role of the knowledge model in relation to other
models.
2.1.6.2 Knowledge Model Overview
A knowledge model encompasses three parts, each part captures a related group of knowledge
structure. Each part is called a knowledge category. The first category is called the domain
knowledge. This category specifies the domain specific knowledge and information types,
that is concerned in an application. The second part of the knowledge model contains the
inference knowledge. The inference knowledge describes the basic inference steps that are
needed to make using the domain knowledge. The third category of knowledge model is task
knowledge. Task knowledge describes what gaols and application follows and how these
goals can be determined through decomposition into subtasks and finally inferences.
24
Figure 2.6 – Schematic view of the role of the knowledge model in relation to other models
2.1.6.2.1 Domain Knowledge
The domain knowledge describes the main static information and knowledge objects in an
application domains and includes domain schema and knowledge base. The domain schema is
a schematic description of domain-specific knowledge and information through a number of
type definitions. Knowledge base contains instances of the types specified in the domain
schema.
In practice, the domain schema must specify the three main modelling constructs including
concept, relation and rule type and knowledge base which are defined as below:
Concept: a concept describes a set of objects or instances which occurring in application
domain as which share similar characteristics. An example of a concept could be a gear box in
a diagnosis domain in maintenance area. Features of concept can be described as an attribute.
An attribute can hold a value: a piece of information that instances of the concept can hold.
Relation: a relation between concepts is defined with the relation or binary relation construct.
Relations are defined through a specification of arguments. For each argument, the cardinality
can be defined. An example of a relationship could be causing relationship between a failure
mode and functional failure concepts in the failure mode analysis domain.
Rule Type: Rule types indicated the logical relationships between two logical statements. The
logical statements in such rules are typically expressions about and attribute value of a
concept. So these rules are a special type of relationship. The following logical sentences
could be an example of a rule type in the spindle diagnosis domain.
25
Shaft.failure = crack -> Spindle-Behaviour.status = Axial speed in Z
direction no/less/more than desired speed
Knowledge Base: A domain schema describes domain knowledge types such as concept,
relation and rule type. A knowledge base contains instances of those knowledge types.
2.1.6.2.2 Inference Knowledge
The inference knowledge in knowledge model describes the lowest level of functional
decomposition. These basic information processing units are called inferences in knowledge
modelling. An inference performs a primitive reasoning step. Typically, inference uses
knowledge contain in some knowledge base to derive new information from its dynamic
input. An example of inference could be select a failure mode from the failure mode domain
knowledge to assess and identify the maintenance task.
An inference is described in term of functional roles. There are two types of knowledge roles
called dynamic roles and static roles. Dynamic roles are the run-time inputs and outputs of
inferences. Each invocation of inference usually has different instantiations of the dynamic
roles. As an example a Cover inference that uses a failure casual model to find a root cause
that could explain a malfunction of the spindle. Such an inference would have two dynamic
knowledge roles. An input role complaint, indicating a domain object representing a
functional failure about the behaviour of the system, and an output role hypothesis,
representing a single failure mode as a candidate solution. Static roles, on the other hand, are
more or less stable over time. Static roles specify the collection of domain knowledge that is
used to make the inference. For example, the above-mentioned inference Cover could use the
state dependency network which shows the failure dependencies of different components of a
spindle in prognosis task.
Transfer function is a function that transfers information items between the reasoning agents
describe in the knowledge model and the outside world (another system or user). And
example of transfer functions could be Obtain which is used whenever the reasoning agent
request a piece of information form an external agent. The reasoning agent has the initiative
and the external agents hold the information items.
2.1.6.2.3 Task Knowledge
Reasoning always has a “reason”. In the other word, an important aspect of knowledge is
what one wants to do with it. What are the goals intended to achieve by applying knowledge?
Task knowledge is the knowledge category that describes these goals and the strategies that
will be employed for realizing goals. Task knowledge is typically described in a hierarchical
fashion. As an example, top level tasks could be status monitoring of a subsystem and at the
lowest level of task decomposition, the task is linked to inferences and transfer functions such
as Cover, Predict, Compare and Obtain.
26
A task method describes how a task is realized through the decomposition into sub-functions.
The core part of the method is formed by the control structure. This control structure
describes in what order the sub-functions should be implemented. The control structure
typically reads like a small program in which the sub-functions are the procedures and the
roles act as parameters of the procedures.
The architecture of the knowledge model components is illustrated in figure 2.7.
Figure 2.7 – Architecture of the knowledge model subsystems. The dotted lines indicate method invocation
paths, the solid lines are information access path.
dynamic role
datatypedomain-mappingcurrent binding
access/updatefunctions
task
I/O rolesmethod
execute
transferfunction
I/O roles
task method
intermediate rolescontrol specification
execute
static role
domain-mapping
access functions
domain model
domain-model nameuses
access functionsinferencing functions
inference
I/O rolesstatic rolesmethod
give-solutionmore-solutions?has-solution?
inference method
algorithm speclocal vars
execute
domain construct
27
2.2 Reliability-Centered Maintenance (RCM)
2.2.1 Background
Over the past twenty years, maintenance has changed, perhaps more so than any other
management discipline. The changes are due to a huge increase in the number and variety of
physical assets (plant, equipment and buildings) which must be maintained throughout the
world, much more complex designs, new maintenance techniques and changing views on
maintenance organization and responsibilities. Maintenance is also responding to changing
expectations. These include a rapidly growing awareness of the extent to which equipment
failure affects safety and the environment, a growing awareness of the connection between
maintenance and product quality, and increasing pressure to achieve high plant availability
and to contain costs.
The key challenges facing modern maintenance strategies can be stated as below:
• to select the most appropriate techniques to deal with each type of failure process in
order to fulfil all the expectations of the owners of the assets, the users of the assets
and of society as a whole
• in the most cost-effective and enduring fashion
• with the active support and co-operation of all the people involved.
RCM provides a framework which enables users to respond to these challenges, quickly and
simply. It does so because it never loses sight of the fact that maintenance is about physical
assets. If these assets did not exist, the maintenance function itself would not exist. So RCM
starts with a comprehensive review of the maintenance requirements of each asset in its
operating context.
Reliability-Centered Maintenance (RCM) can be defined as a process used to determine the
maintenance requirements of any physical asset in its operating context. RCM process asking
seven questions about the assets under review. These questions are as below [17]:
• what are the functions and associated performance standards of the asset in its present
operating context?
• in what ways does it fail to fulfill its functions?
• what causes each functional failure?
• what happens when each failure occurs?
• in what way does each failure matter?
• what can be done to predict or prevent each failure?
• what should be done if a suitable proactive task cannot be found?
28
2.2.2 Functions
The first step in RCM is to determine and define the functions of each asset in its operating
context and in term of its performance. These functioned can be categorize in two ways:
• primary functions, The expected operational task of an asset in fist place. This
category covers functions like speed, motion and product quality. e capacity, product
quality and customer service.
• secondary functions, The operational tasks more than fulfilling its primary functions.
This category covers areas like safety, control, comfort, protection and efficiency of
operation.
2.2.3 Functional Failure
The objectives of maintenance are defined by the required functions and standard
performance of the assets under consideration. The reason which can stop an asset to perform
its standard function is a failure. So RCM deals with the identification of the failures in an
asset. This process can be done in two level:
• firstly, by identifying what circumstances amount to a failed state then
• secondly, by asking what events can cause the asset to get into a failed state.
In RCM, the failure states are known as functional failures.
2.2.4 Failure Modes
The next step after identifying the functional failures is to identify all events which are likely
to cause each of these failure states. These events are called failure modes. "Reasonably
likely" failure modes include those which have occurred on the same or similar equipment
operating in the same context, failures which are currently being prevented by existing
maintenance regimes, and failures which have not happened yet but which are considered to
be real possibilities in the context in question.
2.2.5 Symptoms and Consequences
The next phase in RCM is to identify the consequences happens when a functional failure
occurs. It is these consequences which affect the system and the assets which it is tried to
prevent. The RCM process, categorize these consequences into four classes:
• Hidden failure consequences: Hidden failures have no direct impact, but they expose
the organization to multiple failures with serious, often catastrophic, consequences.
(Most of these failures are associated with protective devices which are not fail-safe.)
• Safety and environmental consequences: A failure has safety consequences if it could
hurt or kill someone. It has environmental consequences if it could lead to a breach of
any corporate, regional, national or international environmental standard.
29
• Operational consequences: A failure has operational consequences if it affects
production (output, product quality, customer service or operating costs in addition to
the direct cost of repair)
• Non-operational consequences: Evident failures which fall into this category affect
neither safety nor production, so they involve only the direct cost of repair.
2.2.6 Failure Management Techniques
Failure consequences evaluation enables us to put attempt on the considerable and important
functions and take away the energy from those which are little or has no effect on the
performance of the system. It also encourages us to think more broadly about different ways
of managing failure, rather than to concentrate only on failure prevention. In RCM context,
failure management techniques are divided into two categories:
• Proactive tasks: these tasks are done before a failure happens to prevent the system
falls into a failure state. It is also known and predictive or preventive maintenance.
• Default actions: these actions are done after a fail state happens. These actions are
selected when there is no possible proactive task can be identified.
RCM divides proactive tasks into three categories as below:
• scheduled restoration tasks
• scheduled discard tasks
• scheduled on-condition tasks.
RCM also categorizes default actions into three main categories as below:
• failure-finding: Failure-finding tasks entail checking hidden functions periodically to
determine whether they have failed
• redesign: redesign entails making any change to the built-in capability of a system.
This includes modifications to the hardware and also covers changes to procedures.
• no scheduled maintenance (Run to Failure): as the name implies, this default entails
making no effort to prevent failure modes and so those failures are simply allowed to
occur and then repaired.
2.2.7 RCM Task Selection Process
A great advantage of RCM is that it provides simple and precise criteria for decision about the
maintenance technique. The task selection process in RCM is as below:
• for hidden failures, a proactive task is worth doing if it reduces the risk of the multiple
failure associated with that function to an acceptably low level. If such a task cannot
be found then a scheduled failure-finding task must be performed. If a suitable failure-
30
finding task cannot be found, then the secondary default decision is that the item may
have to be re-designed.
• for failures with safety or environmental consequences, a proactive task is only worth
doing if it reduces the risk of that failure on its own to a very low level indeed, if it
does not eliminate it altogether. If a task cannot be found which reduces the risk of the
failure to an acceptably low level, the item must be redesigned or the process must be
changed.
• if the failure has operational consequences, a proactive task is only worth doing if the
total cost of doing it over a period of time is less than the cost of the operational
consequences and the cost of repair over the same period. In other words, the task
must be justified on economic grounds. If it is not justified, the initial default decision
is no scheduled maintenance. (If this occurs and the operational consequences are still
unacceptable then the secondary default decision is again redesign).
• if a failure has non-operational consequences a proactive task is only worth doing if
the cost of the task over a period of time is less than the cost of repair over the same
period. So these tasks must also be justified on economic grounds. If it is not justified,
the initial default decision is again no scheduled maintenance, and if the repair costs
are too high, the secondary default decision is once again redesign.
This approach means that proactive tasks are only specified for failures which really need
them, which in turn leads to substantial reductions in routine workloads. This routine work
also means that the remaining tasks are more I likely to be done properly. This together with
the elimination of counterproductive tasks leads to more effective maintenance. Compare this
with the traditional approach to the development of maintenance policies. Different steps
which should be performed to do the RCM analysis is depicted in figure 2.8.
31
Figure 2.8 – Reliability-Centered Maintenance Structure
2.3 Integrated Condition Monitoring and Fault Prognosis
The purpose of condition-based monitoring is to detect faults. Monitoring is usually applied to
machine and its subsystems where failures can be predicted. This task can be done by
measuring the continuous-state variables. These variables can be used not only for predicting
failures in early stages but also can form a base for failure prognosis in a more accurate way.
Therefore, the designed requirements of a monitoring system and fault prognosis system must
identify and select certain sensor signals that can describe the behaviour of the system
appropriately. In order to design and develop an appropriate condition-based monitoring the
following steps must be carried out:
1- Identify the possible failures mode in the machine which could be done through the
functional analysis of the subsystem using RCM technique in section 2.2.
2- Identify the measurable parameters on the subsystems which can show the presence of
the failures.
32
3- Selection of proper CBM equipments. This requires a review of the technologies and
the capabilities of each equipment.
4- Design the condition monitoring systems
5- Design the hardware system which must show the place of different sensors, hardware
for signal processing and machinery control system.
6- Design the software system to collect, process and distribute the data within
monitoring process.
2.3.1 Measurable Parameters
Considering the sensitivity and ease of data acquisitions, the parameters which can be
monitored in the spindle case include power, vibration, temperature and pressure. And the
elements monitored are spindle feed in Z axis and hydraulic and pneumatic transmissions.
These elements and parameters are summarized in table 2.7 [18, 19].
1- Power parameters monitored are voltage (U), drive spindle current (Is), Z- axis drive motor
currents (Iz). Power (P) is calculated using equations Pz=Ulz,
2- Vibration parameters at the spindle and the feed axes in Z direction
3- Temperature parameters are the temperatures of the spindle motor (Ts), and the drive
motors of the Z axis (Tz).
(4) Pressure parameters include the pneumatic, hydraulic oil pressures of revolving devices
(Pr) and coolant pressure (Pc).
Parameters
Vibration Object V C Pw
X Y Z Temp Pr
Spindle U Is Ps axs ays azs Ts
Z axis U Iz Pz axz ayz azz Tz
Pr
Pc
Table 2.7 – Monitored objects and parameters for CBM of spindle system
2.3.2 Selection of Proper CBM Equipment
The available technologies which are used for CBM are categorized into De-Energized and
Energized testing equipments. For this thesis the concentration is on Energized testing
equipments as below [20]:
2.3.2.1 Energized Testing:
- Vibration Analysis: Mechanical vibration is measured through a transducer providing
overall vibration values and FFT analysis. These values provide indicators of
mechanical faults and degree of faults, can be trended and will provide information on
some electrical and rotor problems that vary based upon the loading of the motor.
33
Requires a working knowledge of the system being tested. This test can detect bearing,
shaft and gears cracks well in advance of a fault.
- Infrared Analysis: provides information on the temperature difference between
objects. Faults are detected and trended based upon degree of fault. Excellent for
detecting loose connections and other electrical faults with some ability to detect
mechanical faults. Requires a working knowledge of the system being tested. This test
can detect faults in spindle and power system.
- Ultrasonic Instruments: This measures low and high frequency noise. Will detect a
variety of electrical and mechanical issues towards the late stages of fault. Readings
will vary with load. Requires a working knowledge of the system being tested.
- Voltage and Current measurements: This will provide limited information on the
condition of the motor and power system and spindle. Readings will vary with load.
- Pressure measurements: This will provide limited information on the condition of
hydraulic system.
2.3.3 The System to Analyze the Collected Data
There are many ways to analyze the collected data in condition-based monitoring. In some
cases, many of the measurements may already be made by statistical process control (SPC)
systems and it would seem obvious to link directly into the condition-based monitoring
system. However, the frequency of performing the measurements needs to be determined in
order to be able to indicate change resulting from degradation of the health f the machine or
subsystem. Generally the cost and the complexity of a direct interface into such a system is
large when compared to the cost of walking across to a screen of the SPC computer and login
the data into the electronic notepad of a data collector. Therefore, in this thesis, it is decided to
use SPC to monitor and detect the degradation in the system. Hence, a particular control chart
called CUSUM control chart is chosen and explained in next section 2.4.
2.4 CUSUM Control Charts
As it is mentioned in Introduction chapter, one part of this thesis focuses on designing a
knowledge management system for monitoring and prognosis task. As explained in section
2.3, some parameters are extracted for condition based monitoring of the spindle. Now a
technique which can analyze and indicates the deviation in parameters value is needed. It is
important to note that this method must be able to analyze the data with respect to both target
value and significant shift from the previous monitored data. Surveying different data analysis
charts, it is concluded that CUSUM control chart is a suitable method to achieve the
mentioned goals because of their capability to detect small shifts of measured data from the
target value as well as the deviation from previous monitoring cycles and its ease of use.
34
2.4.1 Description
A CUSUM control chart is a data analysis technique for determining if a value of a parameter
in measurement process has gone out of statistical control. This technique calculates a mean
cumulative sum control chart. There are many ways on how CUSUM control charts are
executed. A typical CUSUM control chart is illustrated in figure 2.9. The parameters needed
on the control chart are defined as follows [4]:
SHi = max [0,SHi* + SHi-1]
SLi = max [0,SLi* + SLi-1]
Where
SHi* = High side cumulation term = (xi – target) – k
SLi* = Low side cumulation term = – (xi – target) – k = (target – xi) – k
SHi-1 and SLi-1 are the previous values of SH and SL
xi is the average sample reading.
k is set a fraction of the deviation from target which is desired to be detected quickly usually
it is equal to one half of the deviation.
If either SH or SL goes above the control limit (h), indicates that a significant reason caused
the process goes out of control limit and intervention in the process is required.
Figure 2.9 – Typical CUSUM control chart scheme
36
Chapter 3 – Design and Develop the Knowledge Base for
Maintenance System
3 Design and Develop the Knowledge Base for Maintenance System
3.1 General Description
To develop a maintenance knowledge base system, first the organization model is
implemented. The organization in this thesis is the maintenance system. In the organization
model, first the problems and opportunities to develop a knowledge base system are
identified. Next step is to analyze various aspects of the organization. Then the process break
down of the organization is defined and the knowledge assets are determined. According to
knowledge assets analysis, knowledge intensive tasks are selected to model in knowledge
base system. These knowledge intensive tasks which are the subject of this thesis are Analyze
the machinery and determine the failure modes, Realizing the maintenance task and
Implementation of preventive maintenance task. Finally, the selected tasks are modeled and
coded.
3.2 Organization Model Analysis
As discussed in chapter 2, table 3.1 (worksheet OM-1) represents the problems and
opportunities of the maintenance system to be solved by knowledge base system. Then
various aspect of the organization is illustrated in table 3.2 (worksheet OM-2) and the process
breakdown of organization is listed in table 3.3 (worksheet OM-3) and finally the knowledge
assets are represented in table 3.4 (worksheet OM-4).
Organization Model Problems and Opportunities Worksheet OM-1
Problems and opportunities 1. What are the functions and associated performance standards of the asset
in its present operating context?
2. In what ways does it fail to fulfill its functions?
3. What causes each functional failure?
4. What happens when each failure occurs?
5. In what way does each failure matter?
6. What can be done to predict or prevent each failure?
7. What should be done if a suitable proactive task cannot be found?
Organizational context
Mission: to identify the maintenance strategies, maintenance tasks,
responsibilities and resources
External actors: knowledge manager, project manager, knowledge user,
maintenance analyzer, MKS developer
Strategy: Design and implementing proactive maintenance solutions
Solutions
Proactive maintenance using Condition-based monitoring and automation
Table 3.1 – Problems and Opportunities Worksheet OM-1
37
Organization Model Variant Aspects Worksheet OM-2
Structure We assume the general maintenance structure including maintenance
manager, maintenance supervisor and staff who are in mutual relationship
with production and production planning departments.
Process It is shown in figure 3.1.
People Maintenance staff
Resources 1. catalogues
2. drawings
3. standards
4. information systems
5. maintenance equipment and spare parts
6. technical experts
Knowledge In worksheet OM-4
Culture and Power We assume a company in which there is no specific procedures to design the maintenance processes and proactive maintenance.
Table 3.2 – Variant Aspects Worksheet OM-2
Figure 3.1 – Process Schema
38
Organization Model Process Breakdown Worksheet OM-3
No (identifier)
Task (Task name)
Performed by (agent)
Where? (location)
Knowledge
asset
Knowledge
Intensive? Significance
1 Identify all the
machineries in
production line
Maintenance
Employees
Consultants
Maintenance
Process
Production
Database
Yes correct asset should be selected to be improved
2 Analyze the
machinery and
determine the failure modes
Maintenance
Employees
Maintenance
Process
Catalogue,
Standards,
Experts
Yes The output of this analysis is basis of predictive maintenance strategies
3 Realizing the
maintenance
Task
Maintenance
Employees
Maintenance
Process
Failure
modes,
cost/Benefit
analysis
Yes This activity
specifies the different tasks which must be done for maintenance
4 Identify the
resources to
implement the
maintenance
Maintenance
Employees
Maintenance
Process
Resources Yes Resources must be
available to implement the identified strategies
5 Implementation
Of preventive
maintenance
Task
Maintenance
Employees
Maintenance
Process
Resources,
Task 3
Yes ---
6 Audit Maintenance
Employees,
QA
Maintenance
Process
All above
tasks
Yes The output of this activity is a basis for continuous improvement
Table 3.3 – Process Breakdown Worksheet OM-3
Organization Model Knowledge Assets Worksheet OM-4
Knowledge
Asset
(see OM-3)
Possessed
by Agent
(see OM-3)
Used in
Task
(see OM-3)
Right
Form?
Yes/no
Right
Place?
Yes/no
Right Time?
Yes/no
Right
Quality?
Yes/no
Catalogue,
Standards,
Experts
OM-3 Task 2
Failure
modes,
cost/Benefit
analysis
OM-3 Task 3
Resources OM-3 Task 4, 5
Table 3.4 – Knowledge Assets Worksheet OM-4
39
3.3 Knowledge Intensive Task Model Analysis
3.3.1 Task 2 - Analyze the Machinery and Determine the Failure Modes
Figure 3.2 shows the task and task method and associated inferences to identify the failure
modes. Choosing the inferences at the lowest level must be carefully done because each
inference has its own ability limitation and scope.
Figure 3.2 – Task and task method inferences to Analyze the machinery and determine the failure modes
Task Method
This task is initiated by the user through a Receive transfer function. This transfer function
uses the list of subsystems in the domain schema. Then each subsystem can be selected via a
Select inference. A specify inference is used to specify the functions of each selected
subsystems. Having each function by a select inference followed by a specify inference, the
functional failures of each function in identified. Selecting each functional failure by a select
inference, the functional failure consequences of each functional failure is determined by a
specify inference and finally by selecting each consequences by a select inference, the failure
modes are determined using the final specify inference. The task method is illustrated in
figure 3.3. All the knowledge roles are collected from the domain schema represented in
figures 3.4, 3.5, 3.6 and 3.7.
40
Figure 3.3 – Task method to Analyze the machinery and determine the failure modes
Figure 3.4 – Domain Schema of Analyze the machinery and determine the failure modes task
41
Figure 3.5 – Graphical representation of supertype of the concept of functional failures
Figure 3.6 – Graphical representation of supertype of the concept of failure modes
Figure 3.7 – Graphical representation of supertype of the concept of functional failure consequences
42
Here, the total knowledge base for this task is described in the standard way. Knowledge base
rules in defining subsystem functions, functional failures, functional failure consequences and
failure modes have been done according to FMEA table in Appendix A.
KNOWLEDGE-MODEL Failure-Mode-Assignment;
DOMAIN-KNOWLEDGE Failure-Mode-Assignment;
DOMAIN-SCHEMA assignment-schema;
CONCEPT machinery-sub-systems;
ATTRIBUTE:
Part-Number: NATURAL;
Name: STRING;
Specification: STRING;
END CONCEPT machinery-sub-systems;
CONCEPT sub-system-functions;
DESCRIPTION:
“This concept holds all the primary and secondary functions of a system”;
ATTRIBUTE
Number: NATURAL;
Name: STRING;
Specification: STRING;
Requirement: STRING;
Type: Function-Type-Value;
END CONCEPT sub-system-functions;
VALUE-TYPE Function-Type-Value;
TYPE: STRING;
VALUE-LIST: “Safety, Comfort, Structural integrity, Economy, Efficiency of
operations, Compliance with regulations and laws, Esthetics”;
END VALUE-TYPE Function-Type-Value;
CONCEPT sub-system-functional-failures;
DESCRIPTION:
“This concept holds all the functional failures of a system”;
ATTRIBUTE
Number: NATURAL;
Name: STRING;
Type: Function-Failure-Type-Value;
Specification: STING;
END CONCEPT sub-system-functional-failures;
VALUE-TYPE Function-Failure-Type-Value;
TYPE: STRING;
VALUE-LIST: “No motion, No flow, More flow, More velocity, More pressure,
More temperature, Less flow, Less velocity, Less pressure, Less
temperature, Additional activity, Partial activity, Reverse activity,
Unexpected activity”;
END VALUE-TYPE Function-Failure-Type-Value;
CONCEPT sub-system-functional-failures-consequences;
DESCRIPTION:
“This concept holds all the functional failures consequences”;
ATTRIBUTE
Name: STRING;
Type: Function-Failure-Type-Value;
Specification: STING;
END CONCEPT sub-system-functional-failures-consequences;
43
CONCEPT sub-system-failure-modes;
DESCRIPTION:
“This concept holds all the failure modes”;
ATTRIBUTE:
Number: NATURAL;
Name: STRING
Description: STRING;
Measurability: Boolean;
Measuring Feature: Measuring-Feature-Type-Value;
Category: Failure-Mode-Category-Type-Value;
Consequence: Consequences-Type-Value;
END CONCEPT sub-system-failure-modes;
VALUE-TYPE Measuring-Feature-Type-Value;
TYPE: STRING;
VALUE-LIST: “None, Vibration, AE, Thermal, Pressure”;
END VALUE-TYPE Measuring-Feature-Type-Value;
VALUE-TYPE Failure-Mode-Category-Type-Value;
TYPE: STRING;
VALUE-LIST: “Deterioration, Lubrication Failure, Dirt, Disassembly, Human
error”;
END VALUE-TYPE Failure-Mode-Category-Type-Value;
VALUE-TYPE Consequences-Type-Value;
TYPE: STRING;
VALUE-LIST: “Safety, Hidden, Operational, non-operational”
END VALUE-TYPE Consequences-Type-Value;
BINARY-RELATION Owns;
DESCRIPTION:
“Relationship between machine subsystems and sub system functions”;
ARGUMENT-1: machinery-sub-systems;
CARDINALITY: 1+;
ARGUMENT-2: sub-system-functions;
CARDINALITY: 1+;
ATTRIBUTE: NONE;
END BINARY-RELATION Owns;
BINARY-RELATION Owns;
DESCRIPTION:
“Relationship between System Function and functional failure”;
ARGUMENT-1: sub-system-functions;
CARDINALITY: 1+;
ARGUMENT-2: sub-system-functional-failures;
CARDINALITY: 1+;
ATTRIBUTE: NONE;
END BINARY-RELATION Owns;
BINARY-RELATION Owns;
DESCRIPTION:
“Relationship between functional failure and functional failure
consequences”
ARGUMENT-1: sub-system-functional-failures;
CARDINALITY: 1+;
ARGUMENT-2: sub-system-functional-failures-consequences;
CARDINALITY: 1+;
ATTRIBUTE: NONE;
44
END BINARY-RELATION Owns;
BINARY-RELATION Owns;
DESCRIPTION:
“Relationship between functional failure consequences and Failure Mode”
ARGUMENT-1: sub-system-functional-failures-consequences;
CARDINALITY: 1+;
ARGUMENT-2: sub-system-failure-modes;
CARDINALITY: 1+;
ATTRIBUTE: NONE;
END BINARY-RELATION Owns;
RULE-TYPE machinery-sub-system-sub-system-functions-dependencies;
DESCRIPTION: ”Rule stating the relationship between the machinery sub
systems and sub system functions”;
ANTECEDENT:
Machinery-sub-systems;
CADIBNALITY 1+;
CONSEQUENT:
Sub-system-functions;
CADIBNALITY 1+;
CONNECTION-SYMBOL:
Has-sub-system-function;
END RULE-TYPE machinery-sub-system-sub-system-functions-dependencies;
RULE-TYPE sub-system-function-sub-system-functional-failure-dependencies;
DESCRIPTION: ”Rule stating the relationship between the system functions
and functional failures”;
ANTECEDENT:
Sub-system-functions;
CADIBNALITY 1+;
CONSEQUENT:
Sub-system-functional_failure;
CADIBNALITY 1+;
CONNECTION-SYMBOL:
Has-functional-failure;
END RULE-TYPE sub-system-function-sub-system-functional-failure-
dependencies;
RULE-TYPE sub-system-functional-failure-sub-system-functional-failure-
consequences-dependencies;
DESCRIPTION: ”Rule stating the relationship between the functional failure
and functional failure consequences”;
ANTECEDENT:
Sub-system-functional-failures;
CARDINALITY 1+;
CONSEQUENT:
Sub-system-functional-failure-consequences;
CARDINALITY 1+;
CONNECTION-SYMBOL:
Has-functional-failure-consequences;
END RULE-TYPE sub-system-functional-failure-sub-system-functional-failure-
consequences-dependencies;
RULE-TYPE sub-system-functional-failure-consequences-sub-system-failure-
mode-dependencies;
45
DESCRIPTION: ”Rule stating the relationship between the functional failure
consequences and failure mode”;
ANTECEDENT:
Sub-system-functional-failures-consequences;
CARDINALITY 1+;
CONSEQUENT:
Sub-system-failure-modes;
CARDINALITY 1+;
CONNECTION-SYMBOL:
Has-Failure-Mode;
END RULE-TYPE sub-system-functional-failure-consequences-sub-system-
failure-mode-dependencies;
KNOWLEDGE-BASE functional-failure-description;
USES:
System function-Specification FROM assignment schema
EXPRESSIONS:
Assignment rules;
Sub-System-Functions.Name = “Provide rotary motion to the workpiece holding
device”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “Rotation Speed Variation”;
Sub-System-Functions.Name = “Provide rotary motion to the workpeice holding
device”;
HAS-Assignment
Sub-System-Functional-Failures.Name = “no rotation”;
Sub-System-System-Functions.Name = “Provide rotary motion to the workpeice
holding device”;
HAS-Assignment
Sub-System-Functional-Failures.Name = “spindle is not rotating around C
axis”;
Sub-System-System-Functions.Name = “Provide axial motion to the workpeice
holding device”;
HAS-Assignment
Sub-System-Functional-Failures.Name = “speed variation in C axis”;
Sub-System-System-Functions.Name = “Provide axial motion to the workpeice
holding device”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “no motion in C axis”;
Sub-System-System-Functions.Name = “movement to the desired Z position”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “Z positioning error”;
Sub-System-System-Functions.Name = “Holding the tool holding device by
means of suitable radial thrust bearing”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “Holding the tool holding device with
inappropriate stiffness”;
Sub-System-System-Functions.Name = “Holding the tool holding device by
means of suitable radial thrust bearing”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “inappropriate transferring torque”;
Sub-System-System-Functions.Name = “convey coolant to the spindle head”;
HAS-Assignment
46
Sub-system-Functional-Failures.Name = “convey coolant with pressure
variation”;
Sub-System-System-Functions.Name = “convey coolant to the spindle head”;
HAS-Assignment
Sub-system-Functional-Failures.Name = “no coolant convey”;
END KNOWLEDGE-BASE functional-failure-description;
KNOWLEDGE-BASE functional-failure-consequences-description;
USES:
System functional failure-Specification FROM assignment schema
EXPRESSIONS:
Assignment rules;
Sub-System-Functional Failure.Name = “Rotation Speed Variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “Rotation Speed Variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool wear”;
Sub-System-Functional Failure.Name = “Rotation Speed Variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “Rotation Speed Variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
Sub-System-Functional Failure.Name = “spindle is not rotating around C
axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “spindle is not rotating around C
axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool wear”;
Sub-System-Functional Failure.Name = “spindle is not rotating around C
axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “spindle is not rotating around C
axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
Sub-System-Functional Failure.Name = “no rotation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “operation can not be
done”;
Sub-System-Functional Failure.Name = “speed variation in C axis”;
HAS-Assignment
47
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “speed variation in C axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool wear”;
Sub-System-Functional Failure.Name = “speed variation in C axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “speed variation in C axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
Sub-System-Functional Failure.Name = “no motion in C axis”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “operation can not be
done”;
Sub-System-Functional Failure.Name = “Z positioning error”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “dimension inaccuracy in
workpiece geometery”;
Sub-System-Functional Failure.Name = “Z positioning error”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool collision and
collapse”;
Sub-System-Functional Failure.Name = “Z positioning error”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “Zero degree orientation
inaccuracy”;
Sub-System-Functional Failure.Name = “Holding the tool holding device with
inappropriate stiffness”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “Holding the tool holding device with
inappropriate stiffness”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool wear”;
Sub-System-Functional Failure.Name = “Holding the tool holding device with
inappropriate stiffness”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “Holding the tool holding device with
inappropriate stiffness”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
Sub-System-Functional Failure.Name = “inappropriate transferring torque”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “loose cutting tool”;
48
Sub-System-Functional Failure.Name = “convey coolant with pressure
variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “convey coolant with pressure
variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “convey coolant with pressure
variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “crack in pipe wall”;
Sub-System-Functional Failure.Name = “convey coolant with pressure
variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “increase the temperature
in workpiece-tool interface”;
Sub-System-Functional Failure.Name = “convey coolant with pressure
variation”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
Sub-System-Functional Failure.Name = “no coolant convey”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “increase the temperature
in workpiece-tool interface”;
Sub-System-Functional Failure.Name = “no coolant convey”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
Sub-System-Functional Failure.Name = “no coolant convey”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “tool wear”;
Sub-System-Functional Failure.Name = “no coolant convey”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “inefficient energy
consumption”;
Sub-System-Functional Failure.Name = “no coolant convey”;
HAS-Assignment
Sub-system-Functional-Failure-Consequences.Name = “workpiece deformation”;
END KNOWLEDGE-BASE functional-failure-consequences-description;
KNOWLEDGE-BASE failure-mode-description;
USES:
Functional Failure Consequences-Specification FROM assignment schema
EXPRESSIONS:
Assignment rules;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
49
HAS-Assignment
Sub-System-Failure-Mode.Name = “Bearing unsteadiness”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “Bearing wear”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “untightened nuts”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “gear wear out”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “inappropriate excess power”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “Problem in hydraulic system”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “wear out of steep angle taper”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “wear out of grip tongs”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “misalignment of tow bar with steep angle
taper and grip tongs”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “input error from central control system”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “corrosion of nuts”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “corrosion of screws”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
50
HAS-Assignment
Sub-System-Failure-Mode.Name = “corrosion in gears”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “corrosion in flange joints”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “crack in gears”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “crack in flange joints;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “misalignment of shaft to the connection of
the motor”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “unstiffness connection of the shaft to the
motor”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “wear out of steep angle taper”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “wear out of grip tongs”;
Sub-System-Functional-Failure-Consequences.Name = “inaccurate workpiece
surface finish and roughness”;
HAS-Assignment
Sub-System-Failure-Mode.Name = “signal error from control system”;
/* This part is done using FMEA tables and the above rules are just a part
of this knowledge base. Due to the huge amount of rules, we have just
summarized this part however all can be find in FMEA tables*/
END KNOWLEDGE-BASE failure-mode-description;
END DOMAIN-KNOWLEDGE Failure-Mode-Assignment;
INFERENCE-KNOWLEDGE assignment-inferences;
KNOWLEDGE-ROLE sub-system-selection;
TYPE: DYNAMIC;
DOMAIN-MAPPING: Machinery-sub-system;
END KNOWLEDGE-ROLE sub-system-selection;
51
KNOWLEDGE-ROLE sub-system-list;
TYPE: STATIC;
DOMAIN-MAPPING: Machinery-sub-system;
END KNOWLEDGE-ROLE sub-system-selection;
KNOWLEDGE-ROLE sub-system-functions-specification;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functions;
END KNOWLEDGE-ROLE sub-system-functions-specification;
KNOWLEDGE-ROLE sub-system-functions-list;
TYPE: STATIC;
DOMAIN-MAPPING: sub-System-functions;
END KNOWLEDGE-ROLE sub-system-functions-list;
KNOWLEDGE-ROLE sub-system-functions-selection;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functions;
END KNOWLEDGE-ROLE sub-system-functions-selection;
KNOWLEDGE-ROLE sub-system-functional-failure-specification;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functional-failures;
END KNOWLEDGE-ROLE sub-system-functional-failure-specification;
KNOWLEDGE-ROLE sub-system-functional-failure-list;
TYPE: STATIC;
DOMAIN-MAPPING: sub-System-functional-failures;
END KNOWLEDGE-ROLE sub-system-functional-failure-list;
KNOWLEDGE-ROLE sub-system-functional-failure-selection;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functional-failures;
END KNOWLEDGE-ROLE sub-system-functional-failure-selection;
KNOWLEDGE-ROLE sub-system-functional-failure-consequences-specification;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functional-failures-consequences;
END KNOWLEDGE-ROLE sub-system-functional-failure-consequences-
specification;
KNOWLEDGE-ROLE sub-system-functional-failure-consequences-list;
TYPE: STATIC;
DOMAIN-MAPPING: sub-System-functional-failures-consequences;
END KNOWLEDGE-ROLE sub-system-functional-failure-consequences-list;
KNOWLEDGE-ROLE sub-system-functional-failure-consequences-selection;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-functional-failures-consequences;
END KNOWLEDGE-ROLE sub-system-functional-failure-consequences-selection;
KNOWLEDGE-ROLE sub-system-failure-mode-specification;
TYPE: DYNAMIC;
DOMAIN-MAPPING: sub-System-failures-mode;
END KNOWLEDGE-ROLE sub-system-failure-mode-specification;
KNOWLEDGE-ROLE sub-system-failure-mode-list;
TYPE: STATIC;
DOMAIN-MAPPING: sub-System-failures-mode;
END KNOWLEDGE-ROLE sub-system-failure-mode-list;
52
INFERENCE Select;
RULES:
INPUT:
Machinery-sub-system-list;
OUTPUT:
Machinery-sub-system;
SPECIFICATION: “Input is a set of sub systems. Output is one of the sub
systems.”
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: Lookup;
RULES:
INPUT:
Machinery-sub-system;
OUTPUT:
Sub-system-functions;
STATIC:
Sub-System-Functions;
SPECIFICATION: “this inference is a simple lookup of the functions”
END INFERENCE Specify;
INFERENCE Select;
RULES:
INPUT:
Sub-system-functions;
OUTPUT:
Sub-system-function;
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: Lookup;
RULES:
INPUT:
Sub-system-function;
OUTPUT:
Sub-system-functional-failures;
STATIC:
Sub-System-Functional-Failures;
END INFERENCE Specify;
INFERENCE Select;
RULES:
INPUT:
Sub-system-functional-failures;
OUTPUT:
Sub-system-functional-failure;
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: Lookup;
RULES:
INPUT:
Sub-system-functional-failure;
OUTPUT:
Sub-system-functional-failures-consequences;
STATIC:
Sub-System-Functional-Failures-Consequences;
END INFERENCE Specify;
53
INFERENCE Select;
RULES:
INPUT:
Sub-system-functional-failures-consequences;
OUTPUT:
Sub-system-functional-failures-consequence;
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: Lookup;
RULES:
INPUT:
Sub-system-functional-failures-consequences;
OUTPUT:
Sub-system- failures-modes;
STATIC:
Sub-System-Failures-Modes;
END INFERENCE Specify;
END INFERENCE-KNOWLEDGE assignment-inferences;
TASK-KNOWLEDGE assignment-failure-modes;
TASK assignment-failure-modes;
ROLES:
INPUT:
Machinery-sub-system;
OUTPUT:
Sub-system-failure-modes;
END TASK assignment-failure-modes
TASK-METHOD assignment-failure-modes
REALIZES:
Sub-system-failure-modes;
DECOMPOSITION:
INFERENCES:
Select, specify, Select, specify, Select, specify, Select, specify;
TRANSFER-FUNCTIONS: receive;
ROLES:
INTERMEDIATES:
Machinery-sub-systems;
Machinery-sub-system;
Sub-System-functions;
Sub-System-function;
Sub-system-functional-failures;
Sub-system-functional-failure;
Sub-system-functional-failures-consequences;
Sub-system-functional-failures-consequence;
Sub-system-failure-modes;
CONTROL-STRUCTURE:
Receive(Machinery-sub-systems);
Select(Machinery-sub-systems -> Machinery-sub-system);
WHILE SIZE(Sub-system-functions) > 1 DO
Specify(Machinery-sub-system -> sub-system-functions);
Select(sub-system-functions -> sub-system-function);
WHILE SIZE(Sub-system-functional-failure) > 1 DO
Specify(sub-system-function -> sub-system-functional-failures);
Select(sub-system-functional-failures -> sub-system-functional-failure);
WHILE SIZE(Sub-system-functional-failure-consequences) > 1 DO
Specify(sub-system-functional-failure -> sub-system-functional-failures-
consequences);
54
Select(sub-system-functional-failures-consequences -> sub-system-
functional-failures-consequence);
Specify(sub-system-functional-failures-consequence -> sub-system-failure-
modes);
Sub-system-functional-failure-consequences := Sub-system-functional-
failure-consequences SUBTRACT Sub-system-functional-failure-consequence;
END WHILE;
Sub-system-functional-failures := Sub-system-functional-failures SUBTRACT
Sub-system-functional-failure;
END WHILE;
Sub-system-functions := Sub-system-functions SUBTRACT Sub-system-function;
END WHILE;
END TASK-METHOD assignment-failure-modes
END TASK-KNOWLEDGE assignment-failure-modes;
END KNOWLEDGE-MODEL Failure-Mode-Assignment;
3.3.2 Task 3 - Realizing the Maintenance Task
Figure 3.2 shows the task and task method and associated inferences to realize the
maintenance task.
Figure 3.8 – Task and task method inferences to realize the maintenance task
55
Task Method
This task is initiated by the Receive transfer function which includes all the failure modes
from the previous task. By a Select inference, a failure mode is selected and then a Specify
inference, determines the failure mode cost, consequences and the maintenance task technical
feasibility. Then the decision about the maintenance task is taken using an Evaluate inference.
The task method is illustrated in figure 3.9. All the knowledge roles are collected from the
domain schema represented in figure 3.10.
Figure 3.9 – Task method to realize the maintenance task
Figure 3.10 – Domain Schema of realizing the maintenance task
56
Here, the total knowledge base for this task is described in the standard way.
KNOWLEDGE-MODEL Maintenance-Task-Selection
/* Knowledge model for the identification of maintenance strategy and
approach in the spindle case study */
DOMAIN-KNOWLEDGE Maintenance-Task-Selection
DOMAIN-SCHEMA assessment
CONCEPT failure mode;
DESCRIPTION:
“This concept holds all the failure modes”;
ATTRIBUTE:
Number: NATURAL;
Name: STRING;
Description: STRING;
Measurability: Boolean;
Measuring Feature: Measuring-Feature-Type-Value;
Category: Failure-Mode-Category-Type-Value;
Consequence: Consequences-Type-Value;
END CONCEPT Failure mode;
VALUE-TYPE Measuring-Feature-Type-Value;
TYPE: STRING;
VALUE-LIST: “None, Vibration, AE, Thermal, Pressure”;
END VALUE-TYPE Measuring-Feature-Type-Value;
VALUE-TYPE Failure-Mode-Category-Type-Value;
TYPE: STRING;
VALUE-LIST: “Deterioration, Lubrication Failure, Dirt, Disassembly, Human
error”;
END VALUE-TYPE Failure-Mode-Category-Type-Value;
VALUE-TYPE Consequences-Type-Value;
TYPE: STRING;
VALUE-LIST: “Safety, Hidden, Operational, non-operational”;
END VALUE-TYPE Consequences-Type-Value;
CONCEPT Maintenance-Task-Selection;
DESCRIPTION:
“This concept holds all the maintenance strategy solution”;
SUPER-TYPE-OF Default, Proactive;
END CONCEPT maintenance strategy solution;
CONCEPT Default;
DESCRIPTION:
“Default Maintenance Strategy based on RCM”;
SUB-TYPE-OF Maintenance-Task-Selection;
ATTRIBUTE:
Category: Default-Category-Type-Value;
Strategy Cost: NATURAL;
Tech. Feasibility: Boolean;
END CONCEPT Default;
VALUE-TYPE Default-Category-Type-Value;
TYPE: STRING;
VALUE-LIST: “RTF, Redesign, Failure Finding”
END VALUE-TYPE Default-Category-Type-Value;
57
CONCEPT Proactive;
DESCRIPTION:
“Proactive Maintenance Strategy based on RCM”;
SUB-TYPE-OF Maintenance-Task-Selection;
ATTRIBUTE:
Category: Proactive-Category-Type-Value;
Sensor Type: Proactive-Sensor-Type-Value;
Cost: NATURAL;
Period: Proactive-Period-Type-Value;
Tech. Feasibility: Boolean;
END CONCEPT Proactive;
VALUE-TYPE Proactive-Category-Type-Value;
TYPE: STRING;
VALUE-LIST: “Acoustic Emission, Vibration Analysis, Temperature, Position
Accuracy, None”;
END VALUE-TYPE Proactive-Category-Type-Value;
VALUE-TYPE Proactive-Sensor-Type-Value;
TYPE: STRING;
VALUE-LIST: “Inferometer, Accelerometer, dynamometer, Thermometer, None ”;
END VALUE-TYPE Proactive-Sensor-Type-Value;
VALUE-TYPE Proactive-Period-Type-Value;
TYPE: STRING;
VALUE-LIST: “Online processing, Time Intervals”;
END VALUE-TYPE Proactive-Period-Type-Value;
BINARY-RELATION Owns;
DESCRIPTION:
“Maintenance strategy and method relationship with failure mode”
ARGUMENT-1: failure mode;
CARDINALITY: 1+;
ARGUMENT-2: maintenance task selection;
CARDINALITY: 1+;
ATTRIBUTE: NONE;
END BINARY-RELATION Owns;
BINARY-RELATION indicates;
DESCRIPTION:
“relationship between Maintenance task selection and failure mode
maintenance task”
ARGUMENT-1: Maintenance-Task-Selection;
CARDINALITY: 1+;
ARGUMENT-2: Failure-Mode-Maintenance-Task;
CARDINALITY: 1;
ATTRIBUTE: NONE;
END BINARY-RELATION indicates;
BINARY-RELATION indicates;
DESCRIPTION:
“relationship between failure mode and failure mode maintenance task”
ARGUMENT-1: Failure-Mode;
CARDINALITY: 1+;
ARGUMENT-2: Failure-Mode-Maintenance-Task;
CARDINALITY: 1;
ATTRIBUTE: NONE;
END BINARY-RELATION indicates;
58
CONCEPT failure-mode-maintenance-task;
ATTRIBUTE:
TRUTH-VALUE: STRING;
END CONCEPT failure-mode-criterion;
RULE-TYPE Failure Mode-Requirement;
ANTECEDENT:
Failure Mode;
CARDINALITY 1+;
CONSEQUENT:
Failure-mode-criterion;
CARDINALITY 1+;
END RULE-TYPE Failure Mode-Requirement;
END DOMAIN-SCHEMA assessment
KNOWLEDGE-BASE Decision-Rule
Failure Mode.Consequence = Hidden
AND
Proactive.Tech_Feasibility = 1
INDICATES
failure-mode-maintenance-task.truth-value = Proactive;
failure_mode.Consequence = Hidden AND
Proactive.Tech_Feasibility = 0
INDICATES
failure-mode-maintenance-task.truth-value = Redesign;
failure_mode.Consequence = Safety AND
Proactive.Tech_Feasibility = 1
INDICATES
failure-mode-maintenance-task.truth-value = Proactive;
failure_mode.Consequence = Safety
AND
Proactive.Tech_Feasibility = 0
INDICATES
failure-mode-maintenance-task.truth-value = Redesign
failure_mode.Consequence = Operational AND
Cost.Proactive < Failure Mode.Cost of Failure
INDICATES
failure-mode-maintenance-task.truth-value = Proactive;
failure_mode.Consequence = Operational AND
Cost.Proactive > Failure Mode.Cost of Failure AND
Cost.Default > Failure Mode.Cost of Failure
INDICATES
failure-mode-maintenance-task.truth-value = Redesign
failure_mode.Consequence = Operational AND
Cost.Proactive > Failure Mode.Cost of Failure AND
Cost.Default < Failure Mode.Cost of Failure
INDICATES
failure-mode-maintenance-task.truth-value = RTF
failure_mode.Consequence = Non-Operational AND
Cost.Proactive < Failure Mode.Cost of Failure AND
INDICATES
59
failure-mode-maintenance-task.truth-value = Proactive;
failure_mode.Consequence = Non-Operational AND
Cost.Proactive > Failure Mode.Cost of Failure AND
Cost.Default > Failure Mode.Cost of Failure
INDICATES
failure-mode-maintenance-task.truth-value = Redesign;
failure_mode.Consequence = Non-Operational AND
Cost.Proactive > Failure Mode.Cost of Failure AND
Cost.Default < Failure Mode.Cost of Failure
INDICATES
failure-mode-maintenance-task.truth-value = RTF
END KNOWLEDGE-BASE Decision-Rule;
END DOMAIN-KNOWLEDGE Maintenance-Task-Selection;
INFERENCE-KNOWLEDGE Assessment-Inferences;
KNOWLEDGE-ROLE Failure-Mode-Description;
TYPE: STATIC;
DOMAIN-MAPPING:
Failure-Mode;
END KNOWLEDGE-ROLE Failure-Mode-Description;
KNOWLEDGE-ROLE Failure-Mode-Selection;
TYPE: DYNAMIC;
DOMAIN MAPPING: Failure Mode;
END KNOWLEDGE-ROLE Failure-Mode-selection;
KNOWLEDGE-ROLE Decision-Norms-Specification;
TYPE: DYNAMIC
DOMAIN MAPPING: Maintenance-Task-Selection;
DOMAIN MAPPING: Failure-Mode;
END KNOWLEDGE-ROLE Decision-Norms-Specification;
KNOWLEDGE-ROLE Maintenance-Task-Selection;
TYPE: STATIC;
DOMAIN MAPPING: Maintenance-Task-Selection;
END KNOWLEDGE-ROLE Maintenance-Task-Selection;
KNOWLEDGE-ROLE Failure-Mode;
TYPE: STATIC;
DOMAIN MAPPING: Failure-Mode;
END KNOWLEDGE-ROLE Failure-Mode;
KNOWLEDGE-ROLE Maintenance-Task-Decision;
TYPE: DYNAMIC;
DOMAIN MAPPING: Maintenance-Task-Selection;
DOMAIN MAPPING: Failure-Mode;
END KNOWLEDGE-ROLE Maintenance-Task-Decision;
INFERENCE Select;
ROLES:
INPUT:
Failure Modes;
OUTPUT:
Failure Mode;
STATIC:
Failure-Mode;
60
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: Lookup;
ROLES:
INPUT:
Failure Mode;
Maintenance-Task-Selection;
OUTPUT:
Failure Mode Cost and Consequence and related Maintenance Task Tech.
Feasibility;
END INFERENCE Specify;
INFERENCE Evaluate;
ROLES:
INPUT:
Failure Mode Cost and Consequence and related Maintenance Task Tech.
Feasibility;
OUTPUT:
Maintenance Task Decision;
END INFERENCE Select;
END INFERENCE KNOWLEDGE Assessment-Inferences;
TASK-KNOWLEDGE assessment-tasks;
TASK assess-failure-mode;
DOMAIN-NAME Identification of maintenance task;
GOALS:
“Assess the failure modes to decide a maintenance solution”;
ROLES:
INPUT:
Failure-Mode;
OUTPUT:
“Choose a maintenance task for a particular failure mode”
END TASK assess-failure-mode;
TASK-METHOD assess-through-select-and-evaluate;
REALIZES:
Maintenance Task;
DECOMPOSITION:
INFERENCES:
Select, specify, evaluate
RULES:
INTERMEDIATE:
Failure-Modes;
Failure-Mode;
Failure-mode-cost-and-consequence-and-related-maintenance-tasks-
feasibility;
Decision;
CONTROL-STRUCTURE:
WHILE SIZE(Failure-Modes) > 1 DO
Select(Failure-Modes -> Failure-Mode);
Specify(Failure-Mode -> Failure-mode-cost-and-consequence-and-related-
maintenance-tasks-feasibility);
Evaluate(Failure-mode-cost-and-consequence-and-related-maintenance-tasks-
feasibility -> Decision)
Failure-Modes := Failure-Modes SUBTRACT Failure-Mode;
END WHILE
END TASK-METHOD assess-through-select-and-evaluate;
61
END TASK-KNOWLEDGE assessment-tasks;
END KNOWLEDGE-MODEL Maintenance-Task-Selection;
3.3.3 Task 5 – Implementation Of Preventive Maintenance Task
(Monitoring and Prognosis)
Figure 3.11 shows the task and task method and associated inferences to realize the
maintenance task.
Figure 3.11 – Task and task method of Implementation Of Preventive Maintenance Task (Monitoring and
Prognosis)
Task Method
This task performs two subtasks of monitoring and prognosis. First, the data from the system
is received using a Receive transfer function. Spindle monitoring parameters are collected.
These parameters are chosen according to FMEA analysis and CBM rules mentioned in
section 2.3. Using a Select inference, vector of monitoring parameters is selected from the
domain schema. A Specify inference, determines a norm for the selected vector of parameters.
Then a Compare inference, compare the norm and new findings. In case of deviation, the
prognosis part of the model comes to action. A Cover inference generates hypotheses which
are basically possible failure modes. This Cover inference uses the casual relationship defined
in domain schema and knowledge rule base. A Select inference, selects each failure modes
and a Specify inference determines the features of this failure mode. These features are the
parameters which can show the status of failure mode. A Select inference selects each feature
and using a Evaluate inference, the selected feature and received data from the system are
analyzed. The Evaluation inference uses the current data and the data from the pervious
monitoring cycle to assess if the components behave normally or not. These two conditions
are called minor and major disturbances. The task method is illustrated in figure 3.12. All the
62
knowledge roles are collected from the domain schemas represented in figures 3.13, 3.14,
3.15 and 3.16..
Figure 3.12 –Task method of Implementation Of Preventive Maintenance Task (Monitoring and
Prognosis)
Figure 3.13 – Monitoring Domain Schema
63
Figure 3.14 – Prognosis Domain Schema
Figure 3.15 – Domain Schema of determining the behaviour of components
65
Figure 3.18 – Sample casual relationship - 2
Here, the total knowledge base for this task is described in the standard way.
KNOWLEDGE-MODEL spindle-monitoring-and-prognosis
/* knowledge model for the online monitoring and prognosis tasks in the
spindle case study */
DOMAIN-KNOWLEDGE spindle-monitoring-and-prognosis
DOMAIN-SCHEMA monitoring-prognosis-schema
CONCEPT spindle-feature;
DESCRIPTION:
“the status of spindle is defined in this concept”;
ATTRIBUTES:
Status: UNIVERSAL;
OBSERVABLE: Boolean;
END CONCEPT spindle-state;
CONCEPT spindle-state;
ATTRIBUTES:
Observable: spindle-state-observable-type-value;
END CONCEPT spindle-state;
VALUE-TYPE spindle-state-observable-type-value;
TYPE: NOMINAL;
VALUE-LIST: {False}
END VALUE-TYPE spindle-state-observable-type-value;
CONCEPT spindle-observables;
ATTRIBUTES:
Observable: spindle-observables-observable-type-value;
66
END CONCEPT spindle-observables;
VALUE-TYPE spindle-observables-observable-type-value;
TYPE: NOMINAL;
VALUE-LIST: {True}
END VALUE-TYPE spindle-observables-observable-type-value;
CONCEPT Power;
ATTRIBUTES:
Status: power-status-value-type;
END CONCEPT Power;
VALUE-TYPE power-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {On,Off};
END VALUE-TYPE power-status-value-type;
CONCEPT Bearing;
ATTRIBUTES:
Status: bearing-status-value-type;
END CONCEPT Bearing;
VALUE-TYPE bearing-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE bearing-status-value-type;
CONCEPT Bolt-and-Nut;
ATTRIBUTES:
Status: bolt-and-nut-status-value-type;
END CONCEPT Bolt-and-Nut;
VALUE-TYPE bolt-and-nut-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE bolt-and-nut-status-value-type;
CONCEPT Main-Gear;
ATTRIBUTES:
Failure: main-gear-failure-value-type;
Vibration: Boolean;
Op-status: Boolean;
END CONCEPT Main-Gear;
VALUE-TYPE main-gear-failure-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE main-gear-failure-value-type;
CONCEPT Int-Gears;
ATTRIBUTES:
Failure: int-gears-failure-value-type;
Vibration: Boolean;
Op-status: Boolean;
END CONCEPT Int-Gears;
VALUE-TYPE int-gears-failure-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE int-gears-failure-value-type;
67
CONCEPT Screw;
ATTRIBUTES:
Status: screw-status-value-type;
END CONCEPT Screw;
VALUE-TYPE screw-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE screw-status-value-type;
CONCEPT Shaft;
ATTRIBUTES:
Failure: shaft-failure-value-type;
Vibration: Boolean;
Op-status: Boolean;
END CONCEPT Shaft;
VALUE-TYPE shaft-failure-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,crack};
END VALUE-TYPE shaft-failure-value-type;
CONCEPT Central-Control;
ATTRIBUTES:
Status: central-control-status-value-type;
END CONCEPT Central-Control;
VALUE-TYPE central-control-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,disconnect};
END VALUE-TYPE central-control-status-value-type;
CONCEPT Hydraulic-System;
ATTRIBUTES:
Status: hydraulic-system-status-value-type;
END CONCEPT Hydraulic-System;
VALUE-TYPE hydraulic-system-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {normal,failure};
END VALUE-TYPE hydraulic-system-status-value-type;
CONCEPT Coolant-Valve;
ATTRIBUTES:
Status: coolant-valve-status-value-type;
END CONCEPT Coolant-Valve;
VALUE-TYPE coolant-valve-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: {open,close,clogged};
END VALUE-TYPE coolant-valve-status-value-type;
CONCEPT Coolant-Pipe;
ATTRIBUTES:
Status: coolant-pipe-status-value-type;
END CONCEPT Coolant-Pipe;
VALUE-TYPE coolant-pipe-status-value-type;
68
TYPE: NOMINAL;
VALUE-LIST: {open,close,clogged,no flow};
END VALUE-TYPE coolant-pipe-status-value-type;
CONCEPT Spindle-Behaviour;
DESCRIPTION:
“this concept contains the abnormal behaviour of spindle which could be
noticed by human senses and is used as an input for COVER inference ”
ATTRIBUTES:
Status: spindle-behaviour-status-value-type;
END CONCEPT Coolant-Pipe;
VALUE-TYPE spindle-behaviour-status-value-type;
TYPE: NOMINAL;
VALUE-LIST: { normal, rotate no/more/less than desired speed, Axial speed in Z direction no/less/more than desired speed, Z positioning error,
no/less/more coolant convey};
END VALUE-TYPE spindle-behaviour-status-value-type;
CONCEPT Spindle-Monitoring-Status;
DESCRIPTION:
“This concept consists of measurable parameters to monitor the status of
spindle”
ATTRIBUTES:
Voltage: NATURAL;
Current: NATURAL;
X-vibration: NATURAL;
Y-vibration: NATURAL;
Z-vibration: NATURAL;
Temperature: NATURAL;
Pressure: NATURAL;
END CONCEPT Spindle-Monitoring-Status;
CONCEPT Spindle-Feature-Norms;
DESCRIPTION:
“This concept consists of norms for measurable parameters of spindle”
ATTRIBUTES:
Voltage-Range: NATURAL;
Current-Range: NATURAL;
X-vibration-Range: NATURAL;
Y-vibration-Range: NATURAL;
Z-vibration-Range: NATURAL;
Temperature-Range: NATURAL;
Pressure-Range: NATURAL;
AXIOMS:
Spindle-Feature-Norms.Voltage-Range < D
Spindle-Feature-Norms.Current-Range < E
Spindle-Feature-Norms.X-Vibration < A
Spindle-Feature-Norms.Y-Vibration < B
Spindle-Feature-Norms.Z-Vibration < C
Spindle-Feature-Norms.Temperature-Range < F
Spindle-Feature-Norms.Pressure-Range < Maxp
Spindle-Feature-Norms.Pressure-Range > Minp
END CONCEPT Spindle-Feature-Norms;
CONCEPT Failure-Mode-Types;
SUPER-TYPE-OF:
Shaft, Int-Gears, Bearing, Min-Gear, Cool-Pipe, Coll-Valve, Power,
Hydraulic-Sys;
END CONCEPT Failure-Mode;
69
CONCEPT Shaft;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Vibration: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SH*(i): REAL;
H: Real;
AXIOM:
SH(i)=Max{0,SH*(i)+SH(i-1)};
SH*(i)=Vibration(T(i))-Target-k;
END CONCEPT Shaft;
CONCEPT Int-Gears;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Vibration: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SH*(i): REAL;
H: Real;
AXIOM:
SH(i)=Max{0,SH*(i)+SH(i-1)};
SH*(i)=Vibration(T(i))-Target-k;
END CONCEPT Int-Gears;
CONCEPT Bearing;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Vibration: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SH*(i): REAL;
H: Real;
AXIOM:
SH(i)=Max{0,SH*(i)+SH(i-1)};
SH*(i)=Vibration(T(i))-Target-k;
END CONCEPT Bearing;
CONCEPT Main-Gear;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Vibration: REAL;
Target: REAL;
K: REAL;
70
SH(i): REAL;
SH*(i): REAL;
H: Real;
AXIOM:
SH(i)=Max{0,SH*(i)+SH(i-1)};
SH*(i)=Vibration(T(i))-Target-k;
END CONCEPT Main-Gear;
CONCEPT Cool-Valve;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Pressure: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SL(i): REAL;
SH*(i): REAL;
SL*(i): REAL;
H: Real;
AXIOM:
SH*(i)=Pressure(T(i))-Target-k;
SH(i)=Max{0,SH*(i)+SH(i-1)};
SL*(i)= Pressure(T(i))+Target-k;
SL(i)=Max{0,SL*(i)+SL(i-1)};
END CONCEPT Cool-Valve;
CONCEPT Cool-Pipe;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Pressure: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SL(i): REAL;
SH*(i): REAL;
SL*(i): REAL;
H: Real;
AXIOM:
SH*(i)=Pressure(T(i))-Target-k;
SH(i)=Max{0,SH*(i)+SH(i-1)};
SL*(i)= Pressure(T(i))+Target-k;
SL(i)=Max{0,SL*(i)+SL(i-1)};
END CONCEPT Cool-Pipe;
CONCEPT Power;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Voltage: REAL;
Current: REAL;
Temperature: REAL;
TempTarget: REAL;
K: REAL;
71
TSH(i): REAL;
TSL(i): REAL;
SH*(i): REAL;
SL*(i): REAL;
TH: Real;
AXIOM:
TSH*(i)=Temperature(T(i))-Target-k;
TSH(i)=Max{0,TSH*(i)+TSH(i-1)};
TSL*(i)= Temperature (T(i))+Target-k;
TSL(i)=Max{0,TSL*(i)+TSL(i-1)};
END CONCEPT Power;
CONCEPT Hydraulic-Sys;
DESCRIPTION:
“This concept stores the attribute values of the last monitoring cycle”
SUB-TYPE-OF:
Failure-Mode;
ATTRIBUTE:
Pressure: REAL;
Target: REAL;
K: REAL;
SH(i): REAL;
SL(i): REAL;
SH*(i): REAL;
SL*(i): REAL;
H: Real;
AXIOM:
SH*(i)=Pressure(T(i))-Target-k;
SH(i)=Max{0,SH*(i)+SH(i-1)};
SL*(i)= Pressure(T(i))+Target-k;
SL(i)=Max{0,SL*(i)+SL(i-1)};
END CONCEPT Hydraulic-Sys;
CONCEPT Failure-Class;
ATTRIBUTE:
Type: {Minor Disturbance, Major Disturbance};
END CONCEPT Failure-Class;
/* assessment knowledge type */
RULE-TYPE state-dependency
ANTECEDENT: Spindle-State;
CARDINALITY: 1;
CONSEQUENT: Spindle-Feature;
CONNECTION-SYMBOL:
CARDINALITY: 1;
Causes;
END RULE-TYPE state-dependency
RULE-TYPE Manifestation-Rule
DESCRIPTION: “Rules indicating the relationship between an internal state
and its external behaviour in terms of an observable value”
ANTECEDENT: Spindle-State;
CARDINALITY: 1;
CONSEQUENT: Spindle-Observables;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Has-manifestation;
END RULE-TYPE Manifestation-Rule
72
RULE-TYPE Central-Control-Power
DESCRIPTION: “Rules indicating the casual relationship between the states
of central control and power system.”
ANTECEDENT: Central-Control;
CARDINALITY: 1;
CONSEQUENT: Power;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Central-Control-Power;
RULE-TYPE Power-Main-Gear
DESCRIPTION: “Rules indicating the casual relationship between the states
of Power and main gear.”
ANTECEDENT: Power;
CARDINALITY: 1;
CONSEQUENT: Main-Gear;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Power-Main-Gear;
RULE-TYPE Main-Gear-Int-Gears;
DESCRIPTION: “Rules indicating the casual relationship between the states
of main gear and intermediate gears.”
ANTECEDENT: Main-Gear;
CARDINALITY: 1+;
CONSEQUENT: Int-Gears;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Main-Gear-Int-Gears;
RULE-TYPE Main-Gear-Int-Gears;
DESCRIPTION: “Rules indicating the casual relationship between the states
of main gear and intermediate gears.”
ANTECEDENT: Main-Gear;
CARDINALITY: 1+;
CONSEQUENT: Int-Gears;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Main-Gear-Int-Gears;
RULE-TYPE Int-Gears-Main-Gear;
DESCRIPTION: “Rules indicating the casual relationship between the states
of intermediate gears and main gear.”
ANTECEDENT: Int-Gears;
CARDINALITY: 1+;
CONSEQUENT: Main-Gear;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Int-Gears-Main-Gear;
RULE-TYPE Int-Gears-Shaft;
73
DESCRIPTION: “Rules indicating the casual relationship between the states
of intermediate gears and shaft.”
ANTECEDENT: Int-Gears;
CARDINALITY: 1+;
CONSEQUENT: Shaft;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Int-Gears-Shaft;
RULE-TYPE Shaft-Int-Gears;
DESCRIPTION: “Rules indicating the casual relationship between the states
of shaft and intermediate gears.”
ANTECEDENT: Shaft;
CARDINALITY: 1+;
CONSEQUENT: Int-Gears;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Shaft-Int-Gears;
RULE-TYPE Shaft-Bearing;
DESCRIPTION: “Rules indicating the casual relationship between the states
of shaft and bearing.”
ANTECEDENT: Shaft;
CARDINALITY: 1+;
CONSEQUENT: Bearing;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Shaft-Bearing;
RULE-TYPE Shaft-Bolt-and-Nut;
DESCRIPTION: “Rules indicating the casual relationship between the states
of shaft and bolt and nut.”
ANTECEDENT: Shaft;
CARDINALITY: 1+;
CONSEQUENT: Bolt-and-Nut;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Shaft-Bolt-and-Nut;
RULE-TYPE Shaft-Screw;
DESCRIPTION: “Rules indicating the casual relationship between the states
of shaft and screw.”
ANTECEDENT: Shaft;
CARDINALITY: 1+;
CONSEQUENT: Screw;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Shaft-Screw;
RULE-TYPE Bearing-Shaft;
74
DESCRIPTION: “Rules indicating the casual relationship between the states
of bearing and shaft.”
ANTECEDENT: Bearing;
CARDINALITY: 1;
CONSEQUENT: Shaft;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Bearing-Shaft;
RULE-TYPE Bolt-and-Nut-Shaft;
DESCRIPTION: “Rules indicating the casual relationship between the states
of shaft and bolt and nut.”
ANTECEDENT: Bolt-and-Nut;
CARDINALITY: 1+;
CONSEQUENT: Shaft;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Bolt-and-Nut-Shaft;
RULE-TYPE Screw-Shaft;
DESCRIPTION: “Rules indicating the casual relationship between the states
of screw and shaft.”
ANTECEDENT: Screw;
CARDINALITY: 1;
CONSEQUENT: Shaft;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Screw-Shaft;
RULE-TYPE Hydraulic-System-Main-Gear;
DESCRIPTION: “Rules indicating the casual relationship between the states
of hydraulic system and main gear.”
ANTECEDENT: Hydraulic-System;
CARDINALITY: 1;
CONSEQUENT: Main-Gear;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Hydraulic-System-Main-Gear;
RULE-TYPE Hydraulic-System-Int-Gears;
DESCRIPTION: “Rules indicating the casual relationship between the states
of hydraulic system and intermediate gears.”
ANTECEDENT: Hydraulic-System;
CARDINALITY: 1;
CONSEQUENT: Int-Gears;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Hydraulic-System-Int-Gears;
RULE-TYPE Coolant-valve-Coolant-Pipe;
DESCRIPTION: “Rules indicating the casual relationship between the states
of coolant valve and coolant pipe.”
ANTECEDENT: Coolant-Valve;
75
CARDINALITY: 1;
CONSEQUENT: Coolant-Pipe;
CARDINALITY: 1;
CONNECTION-SYMBOL:
Causes;
END RULE-TYPE Coolant-valve-Coolant-Pipe;
RULE-TYPE spindle-monitoring-status-spindle-feature-norms;
ANTECEDENT: Spindle-monitoring-Status;
CARDINALITY: 1+;
CONSEQUENT: Spindle-Feature-Norms;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Owns;
END RULE-TYPE spindle-monitoring-status;
CONCEPT spindle-monitoring-status-compare-rule;
ATTRIBUTES:
Value: {“out of range difference”, “in range difference”};
END CONCEPT spindle-monitoring-status-compare-rule;
RULE-TYPE Failure-Class-Failure-Attribute;
ANTECEDENT:
Failure-Class;
CARDINALITY: 0+;
CONSEQUENT:
Failure-Attribute;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Requires;
END RULE-TYPE Failure-Class-Failure-Attribute;
RULE-TYPE Failure-Class-Failure-Mode-Types;
ANTECEDENT:
Failure-Class;
Cardinality: 0+;
CONSEQUENT:
Failure-Mode;
CARDINALITY: 1+;
CONNECTION-SYMBOL:
Class-of;
END RULE-TYPE Failure-Class-Failure-Mode;
KNOWLEDGE-BASE monitoring-system;
USES:
Spindle-monitoring-Status FROM monitoring-prognosis-schema;
EXPRESSION:
/* requirements */
Spindle-Monitorng-Status.X-vibration > A /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Spindle-Monitorng-Status.Y-vibration > B /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
76
Spindle-Monitorng-Status.Z-vibration > C /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Spindle-Monitorng-Status.Voltage > D /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Spindle-Monitorng-Status.Current > E /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Spindle-Monitorng-Status.Temperature > F /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Spindle-Monitorng-Status.Pressure > MaxP /* set limit */
OR
Spindle-Monitorng-Status.Pressure < Minp /* set limit */
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Bearing-Monitoring-Status.vibration > G
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
shaft-Monitoring-Status.vibration > H
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Power-Monitoring-Status.Voltage > I
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Shaft-Monitoring-Status.Current > J
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Shaft-Monitoring-Status.Temperature > K
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Hydraulic-System-Monitoring-Status.Pressure > HPMax
OR
Hydraulic-System-Monitoring-Status.Pressure < HPMin
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
Int-Gears-Monitoring-Status.vibration > L
INDICATES
spindle-monitoring-status-compare-rule.value = “out of range difference”
END KNOWLEDGE-BASE monitoring-system;
KNOWLEDGE-BASE Spindle-Structure
USES:
State-dependency FROM monitoring-prognosis-schema;
77
Manifestation-Rule FROM monitoring-prognosis-schema;
EXPRESSIONS:
/* state dependencies */
/* Central Control */
Central control.status = disconnect –> Power.status = off
/* Power */
Power.status = off -> Main-Gear.op status = Stop
/* Main Gear */
Main-Gear.failure = crack -> Intermediate-Gears.failure = crack
Main-Gear.failure = crack -> Intermediate-Gears.vibration = True
Main-Gear.Vibration = True -> Intermediate-Gears.vibration = True
Main-Gear.Vibration = True -> Intermediate-Gears.failure = crack
Main Gear.op status = Stop -> Intermediate Gears.op status = stop
/* Intermediate Gears */
Intermediate-Gears.failure = crack -> Main-Gear.failure = crack
Intermediate-Gears.failure = crack -> Main-Gear.failure.vibration = True
Intermediate-Gears.Vibration = True -> Main-Gear.vibration = True
Intermediate-Gears.Vibration = True -> Main-Gear.failure = crack
Intermediate-Gears.op status = Stop -> Shaft.op status = stop
Intermediate-Gears.failure = crack -> Shaft.failure = crack
Intermediate-Gears.failure = crack -> Shaft.failure.vibration = True
Intermediate-Gears.Vibration = True -> Shaft.vibration = True
Intermediate-Gears.Vibration = True -> Shaft.failure = crack
/* Shaft */
Shaft.failure = crack -> Intermediate-Gears.failure = crack
Shaft.failure = crack -> Intermediate-Gears.vibration = True
Shaft.Vibration = True -> Intermediate-Gears.vibration = True
Shaft.Vibration = True -> Intermediate-Gears.failure = crack
/* Shaft – Bearing */
Shaft.failure = crack -> Bearing.failure = crack
Shaft.failure = crack -> Bearing.vibration = True
Shaft.Vibration = True -> Bearing.vibration = True
Shaft.Vibration = True -> Bearing.failure = crack
/* Shaft – Bolt and Nut and Screw */
Shaft.Vibration = True -> Bolt-and-Nut.status = crack
Shaft.Vibration = True -> Screw.status = crack
/* Bolt and Nut and Screw */
Bolt-and-Nut.status = crack -> Shaft.Vibration = True
Bolt-and-Nut.status = crack -> Shaft.failure = crack
Screw.status = crack -> Shaft.Vibration = True
78
Screw.status = crack -> Shaft.failure = crack
/* Bearing */
Bearing.failure = crack -> Shaft.failure = crack
Bearing.failure = crack -> Shaft.vibration = True
Bearing.Vibration = True -> Shaft.vibration = True
Bearing.Vibration = True -> Shaft.failure = crack
/* Hydraulic System */
Hydraulic-system.status = failure -> Main-Gear.failure = crack
Hydraulic-system.status = failure -> Main-Gear.op status = stop
Hydraulic-system.status = failure -> Main-Gear.vibration = True
Hydraulic-system.status = failure -> Intermediate-Gears.failure = crack
Hydraulic-system.status = failure -> Intermediate-Gears.op status = stop
Hydraulic-system.status = failure -> Intermediate-Gears.vibration = True
/* Coolant Valve */
Coolant-Valve.status = close -> Coolant-Pipe.status = no flow
/* manifestation rules */
/* Shaft - rotate function */
Shaft.vibration = True -> Spindle-Behaviour.status = rotate no/more/less
than desired speed
Shaft.failure = crack -> Spindle-Behaviour.status = rotate no/more/less
than desired speed
Shaft.op status = stop -> Spindle-Behaviour.status = rotate no/more/less
than desired speed
/* Shaft - Axial speed function */
Shaft.vibration = True -> Spindle-Behaviour.status = Axial speed in Z
direction no/less/more than desired speed
Shaft.failure = crack -> Spindle-Behaviour.status = Axial speed in Z
direction no/less/more than desired speed
Shaft.op status = stop -> Spindle-Behaviour.status = Axial speed in Z
direction no/less/more than desired speed
/* Shaft – Z Positioning */
Shaft.vibration = True -> Spindle-Behaviour.status = Z positioning error
Shaft.failure = crack -> Spindle-Behaviour.status = Z positioning error
Shaft.op status = stop -> Spindle-Behaviour.status = Z positioning error
79
/* Shaft – Power and Torque Transfer */
Shaft.vibration = True -> Spindle-Behaviour.status = power and torque
variation transfered to the tool holding device
Shaft.failure = crack -> Spindle-Behaviour.status = power and torque
variation transfered to the tool holding device
Shaft.op status = stop -> Spindle-Behaviour.status = power and torque
variation transfered to the tool holding device
Bearing.status = crack -> Spindle-Behaviour.status = power and torque
variation transfered to the tool holding device
Bearing.vibration = True -> Spindle-Behaviour.status = power and torque
variation transfered to the tool holding device
Hydraulic-system.status = failure -> Spindle-Behaviour.status =
no/less/more coolant convey
Coolant-Valve.status = close -> Spindle-Behaviour.status = no/less/more
coolant convey
/* Coolant Pipe */
Coolant-Pipe.status = close -> Spindle-Behaviour.status = no/less/more
coolant convey
Coolant-Pipe.status = clogged -> Spindle-Behaviour.status = no/less/more
coolant convey
Coolant-Pipe.status = no flow -> Spindle-Behaviour.status = no/less/more
coolant convey
END KNOWLEDGE-BASE Spindle-Structure
KNOWLEDGE-BASE Failure-Mode-Evaluation;
/* evaluation rules */
Shaft.SH(i) >= Shaft.H
Failure-Class.Type = Major Disturbance;
Shaft.SH(i) < Shaft.H
Failure-Class.Type = Minor Disturbance;
Int-Gears.SH(i) >= Int-Gears.H
Failure-Class.Type = Major Disturbance;
Int-Gears.SH(i) < Int-Gears.H
Failure-Class.Type = Minor Disturbance;
Bearing.SH(i) >= Bearing.H
Failure-Class.Type = Major Disturbance;
Bearing.SH(i) < Bearing.H
Failure-Class.Type = Minor Disturbance;
Main-Gear.SH(i) >= Main-Gear.H
Failure-Class.Type = Major Disturbance;
Main-Gear.SH(i) < Main-Gear.H
Failure-Class.Type = Minor Disturbance;
80
Cool-Pipe.SH(i) >= Cool-Pipe.H
OR
Cool-Pipe.SL(i) >= Cool-Pipe.H
Failure-Class.Type = Major Disturbance;
Cool-Pipe.SH(i) < Cool-Pipe.H
OR
Cool-Pipe.SL(i) < Cool-Pipe.H
Failure-Class.Type = Minor Disturbance;
Cool-Valve.SH(i) >= Cool-Valve.H
OR
Cool-Valve.SL(i) >= Cool-Valve.H
Failure-Class.Type = Major Disturbance;
Cool-Valve.SH(i) < Cool-Valve.H
OR
Cool-Valve.SL(i) < Cool-Valve.H
Failure-Class.Type = Minor Disturbance;
Power.Voltage(T(i)) >= (1+A%)*Shaft.vibration(T(i-1))
Failure-Class.Type = Major Disturbance;
Power.Voltage(T(i)) < (1+A%)*Power.Voltage(T(i-1))
Failure-Class.Type = Minor Disturbance;
Power.Current(T(i)) >= (1+A%)* Power.Current (T(i-1))
Failure-Class.Type = Major Disturbance;
Power.Current(T(i)) < (1+A%)* Power.Current (T(i-1))
Failure-Class.Type = Mainor Disturbance;
Power.TSH(i) >= Power.TH
OR
Power.TSL(i) >= Power.TH
Failure-Class.Type = Major Disturbance;
Power.TSH(i) < Power.TH
OR
Power.TSL(i) < Power.TH
Failure-Class.Type = Minor Disturbance;
Hydraulic-Sys.SH(i) >= Hydraulic-Sys.H
OR
Hydraulic-Sys.SL(i) >= Hydraulic-Sys.H
Failure-Class.Type = Major Disturbance;
Hydraulic-Sys.SH(i) < Hydraulic-Sys.H
OR
Hydraulic-Sys.SL(i) < Hydraulic-Sys.H
Failure-Class.Type = Minor Disturbance;
END KNOWLEDGE-BASE Failure-Mode-Evaluation;
END DOMAIN-KNOWLEDGE spindle-monitoring-and-prognosis
INFERENCE-KNOWLEDGE
KNOWLEDGE-ROLE Receive-Data;
81
TYPE: DYNAMIC;
DOMAIN-MAPPING Spindle-Monitoring-Status;
END KNOWLEDGE-ROLE Receive-Data;
KNOWLEDGE-ROLE Spindle-Features;
TYPE: STATIC;
DOMAIN-MAPPING Spindle-Feature-Norms;
END KNOWLEDGE-ROLE Spindle-Features;
KNOWLEDGE-ROLE Spindle-Feature;
TYPE: DYNAMIC;
DOMAIN-MAPPING SET-OF Spindle-Feature-Norms;
END KNOWLEDGE-ROLE Spindle-Feature;
KNOWLEDGE-ROLE Norm;
TYPE: DYNAMIC;
DOMAIN-MAPPING Spindle-Feature-Norms;
END KNOWLEDGE-ROLE Norm;
KNOWLEDGE-ROLE Difference;
TYPE: DYNAMIC;
DOMAIN-MAPPING monitoring-prognosis-schema;
END KNOWLEDGE-ROLE Difference;
KNOWLEDGE-ROLE Hypotheses;
TYPE: DYNAMIC;
DOMAIN-MAPPING Spindle-State;
END KNOWLEDGE-ROLE Hypotheses;
KNOWLEDGE-ROLE Casual-Model;
TYPE: STATIC;
DOMAIN-MAPPING state-dependency;
END KNOWLEDGE-ROLE Casual-Model;
KNOWLEDGE-ROLE Hypothesis;
TYPE: DYNAMIC;
DOMAIN-MAPPING Spindle-State;
END KNOWLEDGE-ROLE Hypothesis;
KNOWLEDGE-ROLE Hypothesis-Features;
TYPE: DYNAMIC;
DOMAIN-MAPPING Failure-Mode-Type;
END KNOWLEDGE-ROLE Hypothesis-Features;
KNOWLEDGE-ROLE Hypothesis-Feature;
TYPE: DYNAMIC;
DOMAIN-MAPPING Failure-Mode-Type;
END KNOWLEDGE-ROLE Hypothesis-Feature;
KNOWLEDGE-ROLE Evaluation-Result;
TYPE: DYNAMIC;
DOMAIN-MAPPING Failure-Mode-Evaluation;
END KNOWLEDGE-ROLE Evaluation-Result;
KNOWLEDGE-ROLE Complaint;
TYPE: DYNAMIC;
DOMAIN-MAPPING Spindle-Observables;
END KNOWLEDGE-ROLE Complaint;
82
INFERENCE Select;
ROLES:
INPUT: Spindle-Features;
OUTPUT: Spindle-Feature;
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: lookup;
ROLES:
INPUT: Spindle-Feature;
OUTPUT: Norm;
END INFERENCE Specify;
INFERENCE Compare;
DESCRIPTION:
“the parameter norms are comparing with the new findings”;
ROLES:
INPUT: Norm;
OUTPUT: Difference;
END INFERENCE Compare;
INFERENCE Cover;
DESCRIPTION:
“using the casual relationship of spindle to generate the hypotheses”;
ROLES:
INPUT: Difference;
OUTPUT: Hypotheses;
END INFERENCE Cover;
INFERENCE Select;
ROLES:
INPUT: Hypotheses;
OUTPUT: Hypothesis;
END INFERENCE Select;
INFERENCE Specify;
OPERATION-TYPE: lookup;
ROLES:
INPUT: Hypothesis;
OUTPUT: Hypothesis-Features;
END INFERENCE Specify;
INFERENCE Select;
ROLES:
INPUT: Hypothesis-Features;
OUTPUT: Hypothesis-Feature;
END INFERENCE Select;
INFERENCE Evaluate;
DESCRIPTION:
“evaluating the hypothesis feature according to the rules to determine the
failure class”;
ROLES:
INPUT: Hypothesis-Feature;
OUTPUT: Evaluation-Result;
END INFERENCE Evaluate;
83
TASK spindle-monitoring-and-prognosis;
ROLES:
INPUT:
Historical-data: “spindle and its components’ features data from previous
monitoring cycle”;
Complaint: “human sensible Spindle abnormal behavior –ex. no rotate”
OUTPUT:
Discrepancy: “indication of deviant system behaviour and prognosis of root
causes and its class as minor or major disturbance”;
END TASK spindle-monitoring-and-prognosis;
TASK-METHOD data-monitoring-and-prognosis;
REALIZES: spindle-monitoring-and-prognosis;
DECOMPOSITION:
INFERENCES:
Select, specify, compare, cover, select, specify, select, evaluate;
TRANSFER-FUNCTIONS: receive;
ROLES:
INTERMEDIATE:
finding: “some observed data about the system”;
parameter: “variable to check for deviant behaviour”;
norm: “expected normal value of the parameter”;
difference: “an indication of the observed norm deviation”;
Failure mode list: “active candidate failure mode”;
Hypothesis: “candidate failure mode”;
Hypothesis-features-value: “candidate features value of candidate failure
mode”
Failure mode feature list: “failure mode features”
Result: “Boolean indicating failure class – Major or Minor disturbances”;
CONTROL-STRUCTURE:
receive(new-finding);
select(new-finding -> parameter);
specify(parameter -> norm);
compare(norm + finding -> difference);
IF difference = TRUE
THEN
WHILE-NEW-SOLUTION cover(complaint or difference -> failure mode
hypothesis) DO
Failure mode list:= hypothesis ADD Failure mode list;
END WHILE
REPEAT
Select(Failure mode list -> hypothesis);
WHILE-NEW-SOLUTION DO
Specify(hypothesis -> hypothesis feature)
Failure mode feature list:= hypothesis feature ADD Failure mode feature
list;
END WHILE
Select(Failure mode feature list -> hypothesis feature)
Result := Evaluate(finding -> Hypothesis-features-value); “the result is
determined based on rule base identified in Failure-Mode-Evaluation
knowledge base”
FOR-EACH hypothesis feature IN Failure mode feature list DO
Failure mode feature list := Failure mode feature list SUBTRACT hypothesis
feature;
END FOR-EACH
84
FOR-EACH failure mode hypothesis IN Failure mode list DO
Failure mode list := Failure mode list SUBTRACT failure mode hypothesis;
END FOR-EACH
UNTIL
SIZE(Failure mode list <= 1;
END REPEAT;
END TASK-METHOD data-monitoring-and-prognosis;
86
Chapter 4 – Conclusion and Future Works
4 Conclusion and Future Works
4.1 Conclusion
Knowledge base management system in maintenance area is much more suitable if it is
designed and developed in a way that it encompasses all necessary steps in design of a
maintenance system. Moreover, it should have the ability to be integrated with other
knowledge base systems. The structure and the environment of the appropriate knowledge
base system should be flexible to allow users to deploy different kinds of tools which they
will. There should be a well structured approach to construct such a knowledge base system in
order to make it easy to develop, debug, upgrade and trace. CommonKADS methodology is a
very powerful methodology to design knowledge base systems which poses all the mentioned
characteristics. Furthermore, RCM is a thorough technique in order to design a maintenance
system and its tasks. The knowledge base system developed in this thesis is a model which
creates a general structure of a maintenance knowledge base system to be used as a base to
initiate the development of maintenance knowledge base systems and could be modified and
customized according to the users needs and requirements.
4.2 Future Works
The proposed knowledge base model for task 5 (Implementation of Preventive Maintenance
Task) is on the basis of the pattern, trend and spectrum analysis. Creating a knowledge base
system which can monitor and prognoses according to the functions specification and design
rules in a deterministic way would be very worthwhile.
87
Appendix A – FMEA Table of Spindle System
P
aram
ete
rs
can
be
mon
itored
for
fau
lt d
iagn
osi
s
po
wer,
vib
rati
on
at
the
spin
dle
in
x,y
,z
dir
ecti
on
, m
oto
r
tem
pera
ture
vib
rati
on
at
the
spin
dle
in
x,y
,z
dir
ecti
on
po
wer
po
wer,
vib
rati
on
at
the
spin
dle
in
x,y
,z
dir
ecti
on
, m
oto
r
tem
pera
ture
po
wer
Inte
rfa
ce
Hy
dra
uli
c
Sy
stem
,
Cen
tral
Co
ntr
ol
Sy
stem
Cen
tral
Co
ntr
ol
Sy
stem
Hy
dra
uli
c
Sy
stem
,
Cen
tral
Co
ntr
ol
Sy
stem
Hy
dra
uli
c
Sy
stem
,
Cen
tral
Co
ntr
ol
Sy
stem
Hy
dra
uli
c
Sy
stem
,
Cen
tral
Co
ntr
ol
Sy
stem
Fail
ure
Mo
de
1. co
rro
sio
n i
n n
uts
. 2
. co
rro
sio
n i
n
scre
ws.
3. co
rro
sio
n i
n g
ears
. 4
.
co
rro
sio
n i
n f
lan
ge j
oin
ts. 5
. cra
ck
in g
ears
. 6
. cra
ck
in
fla
ng
e j
oin
ts. 7
.
mis
ali
gn
men
t o
f sh
aft
in
co
nn
ecti
on
to m
oto
r. 8
. u
nst
iff
co
nn
ecti
on
of
shaft
to
mo
tor.
9. w
ear
ou
t o
f
steep
·an
gle
tap
er
10
. w
ear
ou
t o
f
gri
p t
on
gs.
11
. m
isali
gn
men
t o
f
1. F
ron
tal
head
is
no
t p
rop
erl
y
mo
un
ted
to
th
e g
uid
e s
lid
e o
f th
e
co
lum
n
1. S
ign
al
err
or
fro
m c
on
tro
l sy
stem
du
e t
o c
ab
le d
iscon
necti
on
2.
Dis
co
nn
ecti
on
fro
m h
yd
rau
lic
syst
em
1.B
eari
ng
un
stead
iness
. 2
.Beari
ng
wear.
3. u
nti
gh
ten
ed
nu
ts. 4
.
inap
pro
pri
ate
ex
cess
po
wer.
5
Pro
ble
m i
n h
yd
rau
lic s
yst
em
. 6
.
wear
ou
t o
f st
eep
·an
gle
tap
er.
7.
wear
ou
t o
f g
rip
to
ng
s. 8
.
mis
ali
gn
men
t o
f to
wb
ar
wit
h s
teel
an
gle
tap
er
an
d g
rip
to
ng
s. 8
.
Sig
nal
err
or
fro
m c
on
tro
l sy
stem
du
e t
o c
ab
le d
iscon
necti
on
1. S
ign
al
err
or
fro
m c
on
tro
l sy
stem
du
e t
o c
ab
le d
iscon
necti
on
2
.
Dis
co
nn
ecti
on
fro
m h
yd
rau
lic
syst
em
Ty
pe
op
era
tio
nal
op
era
tio
nal
op
era
tio
nal
op
era
tio
nal
op
era
tio
nal
Desc
rip
tio
n o
f in
flu
en
ce
of
Fu
ncti
on
al
Fa
ilu
res
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
. T
oo
l
Wear.
In
eff
icie
nt
en
erg
y
co
nsu
mp
tio
n. w
ork
peic
e
defo
rmati
on
.
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
. T
oo
l
Wear.
In
eff
icie
nt
en
erg
y
co
nsu
pti
on
. w
ork
peic
e
defo
rmati
on
.
Op
era
tio
n c
an
no
t b
e d
on
e
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
. T
oo
l
Wear.
In
eff
icie
nt
en
erg
y
co
nsu
mp
tio
n. w
ork
peic
e
defo
rmati
on
Op
era
tio
n c
an
no
t b
e d
on
e
Fu
ncti
on
al
Fail
ure
1.1
Sp
eed
Vari
ati
on
1.2
sp
ind
le i
s n
ot
rota
tin
g a
rou
nd
its
lo
cal
ax
is
1.3
No
Ro
tati
on
2.1
Ax
ial
Sp
eed
Vari
ati
on
in
Z d
irecti
on
mo
re t
han
ad
just
ed
level
2.2
No
ax
ial
mo
tio
n
Fu
ncti
on
Pro
vid
e r
ota
ry m
oti
on
to
th
e
wo
rkp
eic
e h
old
ing
dev
ice.
(50
<R
PM
<7
50
0)
(Ro
tati
on
wit
h
max
po
wer
of
15
and
max
to
rque
11
4 f
or
1 s
pin
dle
and
57
fo
r 2
spin
dle
s. R
ota
ttio
n w
ith
max
ax
ial
forc
e o
f 6
00
0 N
)
Pro
vid
e A
xia
l m
oti
on
to
th
e
wo
rkp
eic
e h
old
ing
dev
ice.
No
1
2
88
p
osi
tio
nin
g? -
po
wer,
vib
rati
on
at
the s
pin
dle
in x
,y,z
dir
ecti
on
vib
rati
on
at
the s
pin
dle
in x
,y,z
dir
ecti
on
po
wer
pre
ssu
re
pre
ssu
re
pre
ssu
re, p
ow
er
Cen
tral
Co
ntr
ol
Sy
stem
To
ol
ho
ldin
g
To
ol
ho
ldin
g
Co
oli
ng
pro
cess
Co
oli
ng
pro
cess
Co
oli
ng
pro
cess
1. w
ear
ou
t o
f an
gle
measu
rin
g i
nse
t. 2
.
imp
rop
er
co
nn
ecti
on
of
an
gle
measu
ring
inse
t. 3
. S
ign
al
err
or
fro
m C
en
tral
co
ntr
ol
syst
em
1. W
ear
ou
t o
f ra
dia
l
thru
st b
eari
ng
s. 2
.
Cra
ck
of
rad
ial
thru
st
beari
ng
s.
1. u
nre
gu
late
d c
oo
lan
t
valv
e
1. u
nre
gu
late
d c
oo
lan
t
valv
e. 2
. p
ipe
blo
ck
age. 3
. p
ipe w
all
cra
ck
. 4
. p
ipe
defo
rmati
on
.
1. u
nre
gu
late
d c
oo
lan
t
valv
e. 2
. p
ipe
blo
ck
age. 3
. p
ipe w
all
cra
ck
. 4
. p
ipe
defo
rmati
on
.
op
era
tio
nal
op
era
tio
nal
Safe
ty
op
era
tio
nal/
En
vir
on
men
ta
l op
era
tio
nal
op
era
tio
nal
Dim
en
sio
nal
inaccu
racy
in
wo
rkp
eic
e g
eom
etr
y. T
oo
l
co
llis
ion
an
d c
oll
ap
se.
Mis
sin
g 0
deg
ree o
rien
tati
on
for
too
l ex
ch
ang
e.
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
. T
oo
l
Wear.
In
eff
icie
nt
en
erg
y
co
nsu
mp
tio
n. w
ork
peic
e
defo
rmati
on
.
Co
llap
se D
isco
nn
ecti
on
of
cu
ttin
g t
oo
l fr
om
to
ol
ho
ldin
g d
evic
e d
uri
ng
op
era
tio
n.
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
.
Ineff
icie
nt
en
erg
y
co
nsu
mp
tio
n. C
rack
in
pip
e
wall
s
Incre
ase
th
e t
em
pera
ture
in
wo
rkp
eic
e/t
oo
l in
terf
ace.
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
and
hard
ness
. T
oo
l W
ear.
Ineff
icie
nt
en
erg
y
co
nsu
mp
tio
n. w
ork
peic
e
defo
rmati
on
.
Incre
ase
th
e t
em
pera
ture
in
wo
rkp
eic
e/t
oo
l in
terf
ace.
Inaccu
rate
wo
rkp
iece s
urf
ace
fin
ish
an
d r
ou
gh
ness
and
hard
ness
. T
oo
l W
ear.
Ineff
icie
nt
en
erg
y
co
nsu
mp
tio
n. w
ork
peic
e
defo
rmati
on
.
3.1
Z P
osi
tio
nin
g e
rro
r
4.1
Ho
ldin
g t
he t
oo
l
ho
ldin
g d
evic
e w
ith
inap
pro
pri
ate
sti
ffn
ess
4.2
In
ap
pro
pri
ate
tran
sferr
ing
to
rqu
e
5.1
Co
nv
ey
co
ola
nt
wit
h
pre
ssu
re m
ore
th
an
desi
red
5.2
Co
nv
ey
co
ola
nt
wit
h
pre
ssu
re l
ess
th
an
desi
red
5.3
No
co
ola
nt
co
nv
ey
an
d s
pra
y
Mo
vem
en
t to
th
e d
esi
red
Z
po
siti
on
Ho
ldin
g t
he t
oo
l h
old
ing
dev
ice
by
mean
s o
f su
itab
le r
ad
ial
thru
st
beari
ng
s
co
nv
ey c
oo
lan
t th
rou
gh
th
e
spin
dle
head
. S
pin
dle
in
tern
al
co
ola
nt
is p
roceed
ed
wit
h 8
0 b
ar
wh
ere
as
ex
tern
al
coo
lan
t su
pp
ly
need
s 3
bar.
3
4
5
89
References
[1] Alan Wilson, “Asset Maintenance Management: A Guide to Developing Strategy & Improving
Performances”, Published by Inc. in 2008 , 2nd Revised edition, Chapter 32, ISBN 13: 9780831133313.
[2] Bankim Shikari, “Automation in Condition Based Monitoring Using Vibration Analysis”, Dept. of
Mechanical Engineering Molana Azad National Institute of Technology, 2007.
[3] A. Verl, U. Heisel, M. Walther, D. Maier, “Sensorless Automated Condition Monitoring for the Control of
the Predictive Maintenance of Machine Tools“, CIRP Annals - Manufacturing Technology 2009 58:375-378.
[4] R. P. Leger, Wm. J. Garland, W. F. S. Pohelman, “Fault Detection and Diagnosis Using Statistical Control
Charts and Artificial Neural Networks“, Artificial Intelligence in Engineering 1998 12:35-47.
[5] Adyles Arato Junior, Fabricio Cesar Lobato de Almeida, “Automatic Fault Diagnosis by Application of
Neural Network System and Condition-Based Monitoring Using Vibration Signals”, Journal of Communication
and Computer 2010, Vol.7 No.1.
[6] R. C. M. Yam, P. W. Tse, L. Li, P. Tu, “Intelligent Predictive Decision Support System for Condition Based
Maintenance”, Int J Adv Manuf Technol 2001 17:383-391.
[7] Chang-Ching Lin, Hsien-Yu Tseng, “A Neural Network Application for Reliability Modelling and
Condition-Based Predictive Maintenance”, Int J Adv Manuf Technol (2005) 25:174-179.
[8] J.S. Albus, “A New Approach to Manipulator Control: The Cerebellar Model Articulation Controller”,
Journal of Dynamic Systems, Measurement and Control 1975 220-227.
[9] Jay Lee, Bruce M. Kramer, “Analysis of Machine Degradation Using a Neural Network Based Pattern
Discrimination Model”, Journal of Manufacturing Systems 12: 379-386.
[10] Cornel Resteanu, Ion Vaduva, Marin Andreica, “Monte Carlo Simualtion for Reliability Centered
Maintenance Management”, I. Lirkov, S. margenov and J. Wasniewski (Eds.): LSSC 2007, LNCS 4818
2008:148-156. Springer-Verlag Berling Heidelberg 2008.
[11] Pearl J., “Probabilistic Inference in Intelligent Systems”, San Matteo, CA: Morgan Kaufmann 1998.
[12] Lauritzen SL, Spiegelhalter DJ., “Local Computations with Probablities on Graophical Structures and Their
Application to Expert Systems”, J R Stat Soc B 1988;50(2):157-224.
[13] G. Celeux, F. Corset, A. Lannoy, B. Ricard, “Designing a Bayesian Network for Preventive Maintenance
From Expert Opinions in a Rapid and Reliable Way“, Reliability Engineering and System Safety 2006 91:849-
856.
[14] Haitao Guo, Simon Watson, Peter Tavner, Jiangping Xiang, “Reliability Analysis for Wind Turbines with
Incomplete Failure Data Collected form After the Date of Initial Installation”, Reliability Engineering and
System Safety 2009 94:1057-1063.
[15] H. Boudali, J. B. Dugan, “A Discrete-Time Bayesian Network Reliability Modelling and Analysis
Framework”, Reliability Engineering and System Safety 2005 87:337-349.
90
[16] Guus Schreiber, Hans Akkermans, Anjop Anjewierden, Robert de Hoog, Nigel Shadbolt, Walter Van de
Celde, Bob Wielinga, “Knowledge Engineering and Management, The CommonkADS Methodology”, Second
Print 2001, Published by The MIT Press, ISBN 0-262-19300-0.
[17] Jerzy Mikler, “Reliablity Centered Maintenance”, Course Seminar in Production Engineering and
Managemet Department in KTH, 2010.
[18] Z. D Zhou, Y. P. Chen, J. Y. H. Fuh, A. Y. C. Nee, “Integrated Condition Monitoring and Fault Diagnosis
for Modern Manufacturing Systems“, Annals of the CIRP 2000 49:387-390.
[19] S. Saravanan, G. S. Yadava, P. V. Rao, “Condition Monitoring Studies on Spindle Bearing of a Lathe”, Int.
J. Adv Manuf Technol 2006 28:993-1005.
[20] Howard W. Penrose, “Basic Overview of Reliability-Centered Maintenance Based on Approach for Motor
Management Programs” T-Solution Inc, 2004.