Design and Development of a Maintenance Knowledge- Base System Based on Commonkads Methodology

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

Chapter 1 Introduction

1 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.

2 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

3 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.

4 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

5 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:

υk = ∑wkj x j yk = φ(υk ) j=0 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.

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

7 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,

8 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 = (X 1, . . . ,X n) denotes the vertices of the graph and E = (e 1, . . . , e m) denotes a part of Cartesian product V × V , where ei is called the edges of the graph.

If (X i,X j) lies in E, then this element is called an edge. It is denoted Xi → X j , X i 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 X j, then Xi is called the parent of X j and Xj is called the son or child of Xi. The set of the parents of Xj is denoted pa(X j) and the set of children of Xi is denoted ch(X i).

In a directed graph, the oriented paths are defined as follows:

Definition 3 : An oriented path is a set of distinct vertices Xi, . . . , X j such that (X k−1 ,X k) is an edge for all k = i + 1, . . . , j. This path is denoted Xi → X j. 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, . . . ,X n, is associated a conditional probability P(Y | X 1, . . . ,X n). 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 P()()X1,...,X n = ∏P()X i pa X i i=1

Where pa(X i) 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

9 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.

10 - 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.

Chapter 2 Methodology and Tools

12 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]

case studies application projects use feedback

CASE tools tools implementation environments

life-cycle model, process model, methods guidelines, elicitation techniques graphical/textual notations worksheets, document structure theory

model-based knowledge engineering world view reuse 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:

13 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

14 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.

15 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

16 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.

Organization Model

OM-1 OM-2

Problems Organization & Focus Area Opportunities Description: OM-3 OM-4

General Structure Context (Mission, Process Process Strategy, Breakdown Environment, People CSF's,...) Culture & Power

Resources Potential Solutions Knowledge 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

17 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 Task Performed Where? Knowledge Knowledge Significance (identifier ) (Task name ) by (agent) (location) asset Intensive?

Table 2.3 – Process Breakdown Worksheet OM-3

Table 2.4 – Knowledge Assets Worksheet OM-4

18 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.

19 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 .

20 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 Input tasks: tasks delivering inputs to this task FLOW 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 Describe frequency and duration of the task. CONTROL 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 Competencies needed for successful task performance. For the knowledge COMPETENCE 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 List the quality and performance measures that are used by the organization to PERFORMACE 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.

21 Task Model Knowledge Item Worksheet TM-2 NAME Knowledge Item POSSESSED BY Agent USED IN Task Identifier and name DOMAIN 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 List of agent names WITH 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 List of responsibilities the agent has in task execution, and of restrictions in this AMD CONSTRAINTS 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

22 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.

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.

24 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 .

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.

task

I/O roles method task method

execute intermediate roles control specification

execute

inference

I/O roles static roles method inference method

give-solution algorithm spec more-solutions? local vars has-solution? execute transfer function

I/O roles

static role

domain-mapping

access functions dynamic role domain model datatype domain-model name domain-mapping uses current binding domain construct access functions access/update inferencing functions functions

Figure 2.7 – Architecture of the knowledge model subsystems. The dotted lines indicate method invocation paths, the solid lines are information access path.

26 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?

27 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.

28 • 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-

29 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.

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.

31 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 Object Vibration V C Pw Temp Pr X Y Z Spindle U Is Ps axs ays azs Ts Pr Z axis U Iz Pz axz ayz azz Tz 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.

32 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.

33 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]:

SH i = max [0,SH i* + SH i-1] SL i = max [0,SL i* + SL i-1] Where

SH i* = High side cumulation term = (x i – target) – k SL i* = Low side cumulation term = – (x i – target) – k = (target – x i) – k SH i-1 and SL i-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

Chapter 3 Design and Develop the Knowledge Base for Maintenance System

35 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

36 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

37 Organization Model Process Breakdown Worksheet OM-3 No Task Performed Where? Knowledge Knowledge Significance (identifier ) (Task name ) by (agent) (location) asset Intensive? 1 Identify all the Maintenance Maintenance Production Yes correct asset machineries in Employees Process Database should be production line Consultants selected to be improved 2 Analyze the Maintenance Maintenance Catalogue, Yes The output of machinery and Employees Process Standards, this analysis determine the Experts is basis of failure modes predictive maintenance strategies 3 Realizing the Maintenance Maintenance Failure Yes This activity maintenance Employees Process modes, specifies the Task cost/Benefit different tasks analysis which must be done for maintenance 4 Identify the Maintenance Maintenance Resources Yes Resources resources to Employees Process must be implement the available to maintenance implement the identified strategies 5 Implementation Maintenance Maintenance Resources, Yes --- Of preventive Employees Process Task 3 maintenance Task 6 Audit Maintenance Maintenance All above Yes The output of Employees, Process tasks this activity is QA a basis for continuous improvement

Table 3.3 – Process Breakdown Worksheet OM-3

Organization Model Knowledge Assets Worksheet OM-4 Knowledge Possessed Used in Right Right Right Time? Right Asset by Agent Task Form? Place? Yes/no Quality? (see OM-3) (see OM-3) (see OM-3) Yes/no Yes/no Yes/no Catalogue, OM-3 Task 2 Standards, Experts Failure OM-3 Task 3 modes, cost/Benefit analysis Resources OM-3 Task 4, 5

Table 3.4 – Knowledge Assets Worksheet OM-4

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.

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

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

41 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;

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;

43 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;

44 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 = “convey coolant to the spindle head”; HAS-Assignment

45 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

46 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 = “workpiece deformation”;

Sub-System-Functional Failure.Name = “inappropriate transferring torque”; HAS-Assignment Sub-system-Functional-Failure-Consequences.Name = “loose cutting tool”;

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”;

48 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”;

49 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 = “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;

50 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;

51 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;

52 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);

53 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

54 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

55 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;

56 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;

57 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

58 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;

59 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;

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

61 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

Figure 3.14 – Prognosis Domain Schema

Figure 3.15 – Domain Schema of determining the behaviour of components

Figure 3.16 – Domain Schema of Casual Relationship

Figure 3.17 – Sample casual relationship - 1

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;

65 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;

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;

67 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;

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;

69 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;

70 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

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 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;

72 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;

73 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;

74 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”

75 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;

76 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

77 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

78 /* 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;

79 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;

80 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;

81 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;

82 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

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;

Chapter 4 Conclusion and Future Works

85 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.

86 Appendix A – FMEA Table of Spindle System

can be can be Parameters Parameters power, vibrationtheat spindleinx,y,z direction,motor temperature vibrationtheat spindleinx,y,z direction power power, vibrationtheat spindleinx,y,z direction,motor temperature power monitored for for monitored fault fault diagnosis Interface Interface Hydraulic System, Central Control System Central Control System Hydraulic System, Central Control System Hydraulic System, Central Control System Hydraulic System, Central Control System Failure Mode Failure 1. corrosion1. innuts. corrosion2. in screws.corrosion3. ingears. 4. corrosioninflange joints.crack5. ingears. crack6. inflange joints.7. misalignmentof shaft inconnection tomotor. unstiff8. connection of shafttomotor. wear9. out of steep·angletaper 10. wear out of griptongs. 11. misalignment of Frontal1. head not is properly mountedtothe guide slide of the column Signal1. error from control system duetocable disconnection 2. Disconnectionfrom hydraulic system 1.Bearingunsteadiness. 2.Bearing wear.untightened3. nuts. 4. inappropriateexcess power. 5 Probleminhydraulic system. 6. wearout of steep·angle taper. 7. wearout of grip tongs. 8. misalignmentof towbar withsteel angletaper and grip 8.tongs. Signalerror from control system duetocable disconnection Signal1. error from control system duetocable disconnection 2. Disconnectionfrom hydraulic system Type Type operational operational operational operational operational Inaccurateworkpiece surface finishand roughness. Tool Wear.Inefficient energy consumption.workpeice deformation. Inaccurateworkpiece surface finishand roughness. Tool Wear.Inefficient energy consuption.workpeice deformation. Operationcan not be done Inaccurateworkpiece surface finishand roughness. Tool Wear.Inefficient energy consumption.workpeice deformation Operationcan not be done of Functional Failures Failures of Functional Description of influence influence of Description Functional Failure Failure Functional 1.1Speed Variation 1.2spindle not is rotatingaround local its axis 1.3No Rotation 2.1Axial Speed Variationdirection inZ morethan adjusted level 2.2No axial motion Function Function Providerotary motion tothe workpeiceholding device. (50

87 positioning?power,- vibrationtheat spindle inx,y,z direction vibrationtheat spindle inx,y,z direction power pressure pressure pressure,power Central Control System Toolholding Toolholding Cooling process Cooling process Cooling process 1. wear1. out of angle measuringinset.2. improperconnection ofangle measuring inset.3.Signal error fromCentral control system Wear1. out of radial thrustbearings. 2. Crackof radial thrust bearings. unregulated1. coolant valve unregulated1. coolant valve.pipe2. blockage.pipe3. wall crack.pipe4. deformation. unregulated1. coolant valve.pipe2. blockage.pipe3. wall crack.pipe4. deformation. operational operational Safety operational/ Environmenta l operational operational Dimensionalinaccuracy in workpeicegeometry. Tool collisionand collapse. Missing0degree orientation fortool exchange. Inaccurateworkpiece surface finishand roughness. Tool Wear.Inefficient energy consumption.workpeice deformation. CollapseDisconnection of cuttingtool from tool holdingdevice during operation. Inaccurateworkpiece surface finishand roughness. Inefficientenergy consumption.Crack inpipe walls Increasethe temperature in workpeice/toolinterface. Inaccurateworkpiece surface finishand roughness and hardness.Tool Wear. Inefficientenergy consumption.workpeice deformation. Increasethe temperature in workpeice/toolinterface. Inaccurateworkpiece surface finishand roughness and hardness.Tool Wear. Inefficientenergy consumption.workpeice deformation. 3.1Positioning Z error 4.1Holding the tool holdingdevice with inappropriatestiffness 4.2Inappropriate transferringtorque 5.1Convey coolant with pressuremore than desired 5.2Convey coolant with pressurelessthan desired 5.3No coolant convey andspray Movementtothe desired Z position Holdingthe tool holding device bymeans of suitable radial thrust bearings conveycoolant through the spindlehead. Spindle internal coolantproceeded is with80 bar whereasexternal coolant supply needs3bar. 3 4 5

88 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.

89 [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.