Peeters 2016 by TKI Dinalog

August 10, 2016

Development of a Maintenance Program for a New Industrial Additive Manufacturing System

by J.F.W. Peeters

J.F.W. Peeters, B.Eng Student Identity Number: 0791342

PUBLIC VERSION

in partial fulfilment of the requirements for the degree of Master of Science in Operations Management and Logistics

Supervisors: Dr. Ir. R.J.I. Basten, TU/e, OPAC Dr. Ir. J.J. Arts, TU/e, OPAC Ir. M.H.E. Vaes, Additive Industries B.V.

TUE. School of Industrial Engineering. Series Master Theses Operations Management and Logistics.

Subject headings: maintenance, maintenance planning, technic maintenance, technical reliability.

Abstract Background In this thesis we describe the development of an initial maintenance program for a new industrial additive manufacturing system, the MetalFAB1. In order to do so, we propose (1) a novel method for the analysis of the failure behavior of a new complex capital good and (2) a maintenance concept to develop a maintenance program for such a system. Results First, we investigate the failure behavior of the MetalFAB1. Based on a comparison of FTA (Fault Tree Analysis) and FMEA (Failure Modes and Effects Analysis), we conclude that we need a more efficient method to map failure behavior that is both rigorous as well as efficient. We propose a novel method for this that we call recursive FTA-FMECA and we apply this to the MetalFAB1 in a case study. Second, we research the development of a maintenance program for such a system. Based on existing maintenance literature, we propose a customized maintenance concept to decide on maintenance policies in a maintenance program. A case study shows the application to MetalFAB1. Conclusions Based on the application of the proposed method for failure analysis and the proposed maintenance concept, we show that we are able to develop an initial maintenance program for the MetalFAB1. We recommend to the company to develop the maintenance concept further into a mature decision making tool. Furthermore, we recommend to explore the possibilities to integrate the recursive FTA-FMECA method and the maintenance concept in the regular business processes. For future research, we recommend to research the effects of the assumptions in our proposed method and model and to explore its applicability to other high tech OEMs.

Preface This report is the result of my master thesis project in completion of the master Operations Management and Logistics at Eindhoven University of Technology. This project was conducted at Additive Industries B.V. I would like to use this opportunity to thank several people for their help and support during this project. First, I would like to thank my company supervisor Mark Vaes, for giving me the opportunity to conduct my master thesis at Additive Industries and providing constructive feedback and critical thinking during the project. I would also like to thank my colleagues Daan Kersten, Rob van Haendel, Ron Hensen, Frank Ophelders, Remco Pennings and Erwin Wijn for their input for this project and all other colleagues for the great working atmosphere. Furthermore, I would like to thank Rob Basten for being my first supervisor from Eindhoven University of Technology for guiding me through this process with his new ideas and always constructive feedback. In addition, also special thanks to Tiedo Tinga from University of Twente for his input to this project and Joachim Arts from Eindhoven University of Technology for his thoughts and comments to improve this thesis. Also thanks to my family and friends for their support during my entire educational career and for making this an awesome period. Johnny Peeters Eindhoven, August 2016

Executive Summary This Master Thesis is the result of a project at Additive Industries B.V. Additive Industries is an Original Equipment Manufacturer (OEM) of industrial additive manufacturing equipment. In this project, we developed an initial maintenance program for the MetalFAB1 system. Problem Definition High tech capital goods, such as additive manufacturing systems, are pieces of equipment that are sold to firms to be used in their production processes for a long period of time. During its usage period, a customer typically demands a high availability of the system in order to utilize it optimally in its production process. Moreover, customers more often consider the Total Cost of Ownership (TCO) of an investment in such equipment rather than just the initial investment. Especially the cost incurred during the operational period are influenced by downtime and maintenance activities. Properly defined planned (preventive) maintenance actions can contribute to system availability improvement and realization of cost reduction (Rausand, 1998). For the MetalFAB1, Additive Industries has not yet determined how to maintain the installed systems. Effective (preventive) maintenance of the system is one of the instruments that can help to accomplish the demanded system availability and to reduce TCO. This is the motivation for the company to find an effective maintenance program for MetalFAB1. The latter includes a list of maintenance policies for effective maintenance of the system. This leads to our main research question for the project: Main Research Question: What is an effective maintenance program for MetalFAB1?

Approach Since the topic of maintenance of advanced capital goods is broad, we use the framework of Goossens (2015) to structure and position our work. Goossens (2015) considers maintenance of technical assets as a process of different tiers on strategic, tactical and operational level. In order to answer the main research question, we define four sub research questions in a research framework; see Figure 1. As indicated in the figure, we treat four building blocks of this framework to develop an initial maintenance program. The process starts with the definition of the maintenance objective to guide all future maintenance decisions. The objective is typically defined in terms of technical, financial or customer service targets (see, e.g., Kelly, 1997). The next step is the development of an appropriate maintenance concept to develop a maintenance plan. Subsequently, one applies this concept to decide on which maintenance policy to be used for each specific component that requires maintenance. A maintenance policy prescribes which parameter triggers a maintenance action, e.g. time, usage or component condition (see, e.g., Pintelon et al., 1997). In order to be able to select

iii

and define the best maintenance policy, information on failure behavior is a required input. The remaining building blocks are out of scope of the present project.

Research Question 2:

Maintenance process

What is the maintenance objective for MetalFAB1?

Maintenance objective RQ2

MetalFAB1

Research Question 3:

What is a suitable maintenance concept for MetalFAB1?

Research Question 1:

RQ1 Failure Behavior

Maintenance concept

Maintenance policy

RQ3

RQ4

What is the failure behavior of MetalFAB1? Research Question 4:

What are the most appropriate maintenance policies for the maintenance critical items of MetalFAB1?

Maintenance approach

Maintenance execution

Maintenance performance

Figure 1: Research framework, adapted from Goossens (2015). Hatched blocks are out of scope of this project. We summarize our results with respect to the building blocks as indicated in Figure 1. Failure Behavior First, we investigate the failure behavior of MetalFAB1 (see RQ1). The failure behavior of the system is defined by its functional failure modes, that each describe â&#x20AC;&#x153;. . . a state such that the intended function of the part or system can no longer be fulfilledâ&#x20AC;? (Tinga, 2013, p. 3). After a comparison of two frequently used methods from literature for failure analysis, FTA (Fault Tree Analysis) and FMEA (Failure, Modes and Effects Analysis), we conclude that it is not evident which method is suitable for our analysis. In our project, we have to analyze a completely new and large engineering system, the MetalFAB1, which failure behavior is unknown and may be comprehensive. We propose a novel approach for this that combines FTA and FMECA in a recursive way. The application of our new method to MetalFAB1 in a case study reveals in total 132 failure modes. We argue that our new method is an improvement with respect to either performing an FTA or FMEA for the whole system in a sense that it is both rigorous as well as efficient. We have achieved a significant time saving based on the fact that, in our opinion, we only have to analyze the most prevalent failure causes to the deepest level of analysis. For some failure modes it is sufficient to have information on which component fails (a component failure mode) while for more critical components we would like to know the underlying failure mechanisms. Maintenance Objective Once we know the failure behavior in terms of the functional failure modes, we can shift to the development of a maintenance program. As depicted in Figure 1, the first step is to define the maintenance objective (RQ2). Interviews with key stakeholders reveal that the maintenance objective for MetalFAB1 can be defined by three aspects: (1) achieve a predetermined level of system availability; (2) minimize customer visits of service engineers by offering remote service and support and (3) minimize service costs. Maintenance Concept Next, we propose a customized maintenance concept to develop an initial maintenance program in accordance with the maintenance objective for MetalFAB1. The conceptual design consists of three decoupled decision making modules: module 1: selection, module 2: customer maintenance and module 3: OEM maintenance. In module 1,

we decide on (a) the maintenance policy type and (b) the executor of the associated maintenance action (either customer or OEM). Module 2 is responsible for the specification of the maintenance interval for the maintenance policies/actions that are performed by the customer, which consists of two consecutive stages: (a) single-item policy specification and (b) clustering. Module 3 is responsible for the specification of the maintenance interval for the maintenance policies/actions that are performed by the OEM, in which we apply a multiitem policy model. Subsequently, we develop a detailed design for module 1 in which we show a step-by-step process to select the maintenance policy type; the detailed design for the remaining modules are out of scope due to a limited amount of time. Maintenance Policy Finally, we apply the proposed detailed design of module 1 to the MetalFAB1 in a case study. More specially, we determine the most appropriate maintenance policy type for each identified failure mode from the failure analysis. The final results can be graphically summarized in a maintenance policy mix (see Figure 2a) and a maintenance action mix (see Figure 2b). The maintenance policy mix shows an overview of which maintenance policy type is recommended for each of the identified 132 failure modes, sorted by the main system functions exposure and powder layer deposit. The maintenance action mix summarizes the maintenance actions per maintenance policy type and initial service level, which could be (1) customer self-support, (2) remote support or (3) on-site support.

Figure 2: Maintenance Policy and Maintenance Action Mix

Conclusions and Recommendations Referring to our Main Research Question, our results show that we are able to develop an initial maintenance program for the MetalFAB1. First, we propose a new method to efficiently map failure behavior of complex systems with recursive FTA-FMECA that saves time on the analysis while the most prevalent causes are still analyzed in detail an we show how it is applied to MetalFAB1. Second, we propose an academically founded maintenance concept to develop a maintenance program and we apply this to MetalFAB1 in a case study. We recommend to the company to develop the maintenance concept further into a mature decision making tool. In the present project, we only have developed one of the three modules of the maintenance concept into a detailed design and we recommend to develop the remaining two modules in detail. Furthermore, we recommend to explore the integration of the recursive FTA-FMECA method and the maintenance concept in the business processes. For future research, we recommend to research the effects of the assumptions in our proposed models: the simplifications in recursive FTA-FMECA and the effects of the proposed decision rules in the detailed design of module 1. Finally, we recommend to explore its applicability to other high tech OEMs.

Contents 1 Introduction 1.1 Company and Background 1.2 Problem Definition . . . . 1.3 Relevance of the Project . 1.4 Structure of the Thesis . .

. . . .

2 Research Design 2.1 Literature . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Maintenance of Advanced Capital Goods . . 2.1.2 Failure Behavior of Advanced Capital Goods 2.1.3 Maintenance Objective and Concepts . . . . 2.1.4 Maintenance Policies . . . . . . . . . . . . . . 2.2 Research Questions . . . . . . . . . . . . . . . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

1 2 2 3 4

. . . . . .

5 5 6 6 7 8 9

3 Failure Analysis 3.1 Failure Analysis . . . . . . . . . . . . . . . . . 3.1.1 Failure Modes and Effects Analysis . . 3.1.2 Fault Tree Analysis . . . . . . . . . . 3.1.3 Comparison . . . . . . . . . . . . . . . 3.2 A Novel Approach for New Complex Systems: 3.2.1 Recursive FTA-FMECA . . . . . . . . 3.2.2 Identification of Failure Modes . . . . 3.2.3 Assessment of Criticallity . . . . . . . 3.3 Case Study: Application to MetalFAB1 . . . 3.3.1 System Level Analysis . . . . . . . . . 3.3.2 Function Level Analysis . . . . . . . . 3.3.3 Component Level Analysis . . . . . . 3.4 Discussion and Conclusion . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . Recursive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FTA-FMECA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

12 12 13 14 15 16 16 18 19 19 20 21 21 22

4 Maintenance Objective 4.1 Maintenance Objective . . . . . . . . 4.2 Maintenance Concept Requirements 4.2.1 Inputs . . . . . . . . . . . . . 4.2.2 Functional Requirements . . 4.2.3 Constraints . . . . . . . . . . 4.2.4 Boundaries and Interfaces . .

. . . . . .

24 24 26 26 27 28 28

. . . . . .

4.3

4.2.5 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Discussion and Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 Maintenance Concept 5.1 Conceptual Model . . . . . . . . . . . . . 5.2 Stage 1: Maintenance Policy Selection . . 5.2.1 Module 1: Selection . . . . . . . . 5.3 Stage 2: Maintenance Policy Specification 5.3.1 Module 2: Customer Maintenance 5.3.2 Module 3: OEM Maintenance . . . 5.4 Discussion and Conclusion . . . . . . . . .

29 30

. . . . . . .

31 31 31 32 33 33 34 35

. . . . . . . . . .

36 36 37 38 43 44 44 44 45 46 48

7 Conclusion 7.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Recommendations for the Company . . . . . . . . . . . . . . . . . . . . . . . 7.3 Directions for Future Research . . . . . . . . . . . . . . . . . . . . . . . . . .

50 50 51 53

A Example of Recursive FTA-FMECA

B Results of Application of Recursive FTA-FMECA to MetalFAB1

C Interview Transcripts

D RCM Analysis

E Results of Application of Module 1 to MetalFAB1

6 Detailed Design Module 1 6.1 Design . . . . . . . . . . . . . . . . . . . 6.1.1 Inputs . . . . . . . . . . . . . . . 6.1.2 Internal process steps . . . . . . 6.1.3 Outputs . . . . . . . . . . . . . . 6.2 Implementation . . . . . . . . . . . . . . 6.3 Case Study: Application to MetalFAB1 6.3.1 Approach . . . . . . . . . . . . . 6.3.2 Intermediate Results . . . . . . . 6.3.3 End Results . . . . . . . . . . . . 6.4 Discussion and Conclusion . . . . . . . .

vii

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

. . . . . . .

. . . . . . . . . .

Chapter 1

Introduction High tech capital goods, such as medical systems, lithography systems or additive manufacturing systems are pieces of equipment that are sold to customers to be used for a long period of time. Such complex and expensive capital goods are acquired by firms to be used in their production processes to make other products or services. During its usage period, a customer typically demands a high availability of the system in order to utilize it optimally in its production process. Original Equipment Manufacturers (OEMs) of such equipment recognize the importance of machine availability for their customers. System availability can be defined as the fraction of time that the system is operational in a certain time interval. Firstly, OEMs encounter high pressure from their customers to ensure a high availability of their capital assets. Reason for this is that when a system is down, the customersâ&#x20AC;&#x2122; operations may be interrupted, causing significant extra costs (see, e.g., Smets et al., 2012). These extra costs may, for example, be due to production losses. Secondly, customers more often purchase a certain performance instead of purchasing the machine only (see, e.g., Hypko et al., 2012). Performance in this context is defined as purchasing a level of availability (Pay-on-Availability) or purchasing a production level (Pay-on-Production). The ownership or responsibility of the capital good during and after the usage period could be in the hands of the OEM, instead of the customer (see, e.g., Hypko et al., 2012). In particular, the OEM and its customer may have agreed upon a contract in which maintenance is the responsibility of the OEM to ensure that the system is kept up and running. Thirdly, customers more often consider the total lifecyle cost of a certain investment in equipment rather than just the initial investment. From a customerâ&#x20AC;&#x2122;s point of view, total lifecycle cost is best captured by the term Total Cost of Ownership (TCO). TCO can be defined as the sum of the costs incurred by acquisition, during operation and by disposal of a capital good (see, e.g., Zachariassen and Arlbjorn, 2011). Especially the cost incurred during the operational period are influenced by downtime and maintenance activities. Thus, if the OEM is able to reduce these costs, TCO will decrease, and, as a consequence the system will be more attractive to potential customers (Snelgrove, 2012). All together, OEMs may feel a strong incentive to reduce the Total Cost of Ownership (TCO) and optimize availability of their systems. Effective maintenance of the system is one of the instruments that can help to accomplish these objectives. In this project we specifically look at effective maintenance of a new industrial additive man-

ufacturing system. This system, the MetalFAB1, is developed by the firm Additive Industries and has just been introduced to the market in the end of 2015 (Additive Industries BV, 2015). At the time of writing, this project is the first project that concerns maintenance of the MetalFAB1. The subsequent part of this chapter is organized as follows. Section 1.1 gives a short introduction of the company involved. Subsequently, we introduce the research topic and problem statement in Section 1.2. Section 1.3 motivates the relevance of this project for the company and for the scientific state-of-art. Finally, this chapter ends with a reading guide of the rest of the thesis in Section 1.4.

1.1

Company and Background

Additive Industries BV (see Additive Industries BV, 2016) is a recently founded company (2012) that has the ambition to bring industrial additive manufacturing (AM or 3D Printing) of high end products from “lab” to “fab”. This is further motivated by the belief that direct fabrication of functional parts in metal from digital 3D information will transform the supply chain in the future. As Additive Industries is a young Original Equipment Manufacturer (OEM), it relies on a team of highly experienced engineers with a background in 3D printing complemented with high tech equipment developers for semiconductor, electron microscopy and medical scanning systems to develop next generation AM equipment. A core principle of Additive Industries is to work closely together with experienced (system) suppliers in an open innovation climate. These two together have led to two solutions for the industrial AM market: MetalFAB1, a modular AM system for printing metal products, and the Additive World Platform (AWP), a software platform for AM equipment where all manufacturing related data is presented and stored. Whereas MetalFAB1 is used to produce parts, AWP is a software environment to assist monitoring, planning and analysis of the production process.

1.2

Problem Definition

MetalFAB1 is a complex capital good that is intended to be used in an industrial production environment. Such capital goods are acquired by firms to be used in their production processes to make other products. During its usage period, typically 7 to 20 years, customers demand a high availability of the system in order to utilize it optimally in their production. The system availability can be defined as the fraction of time that the system is operational in a certain time interval and is determined by the uptime and downtime (see, e.g., Smets et al., 2012). The uptime can be quantified by average lifetime of system until a failure occurs (Mean Time To Failure, M T T F ). The downtime on the other hand covers the time from the failure report until the point in time when the system is back to its functioning state (Tinga, 2013). The downtime can be quantified by the sum of the time Mean Time To Support (M T T S, i.e. the time from the failure report until the start of the maintenance action) and the Mean Time To Repair (M T T R, i.e. the time required for performing the maintenance action) (Smets et al., 2012). For example, if a critical component of the system fails (e.g. a laser), the machine can no longer fulfill its function. As a result, a replacement or repair action has to be executed. The resulting downtime may not only include the time of maintenance action itself, but also additional delays (e.g. provision of spare parts and technicians). Furthermore, there may

also be a large financial impact due to production losses and emergency shipments of spare parts. Especially when the failure was unforeseen, the impact on downtime and associated cost can be large (Smets et al., 2012). The relationship between system availability (A), MTTF, MTTS and MTTR can be defined in the following way: A=

MTTF MTTF + MTTS + MTTR

In order to improve the system availability and to reduce costs, it might be beneficial to preventively replace components before they fail. Such a preventive maintenance policy, for example replacement after a fixed period of time (age based) or replacement based on the componentâ&#x20AC;&#x2122;s health or condition (condition based), can help to reduce the number of unexpected failures, maintenance delays and costs (Tinga, 2013). In literature many different models for maintenance policies are available, see the overview by Peeters (2016) for a detailed discussion. A maintenance policy prescribes which parameter triggers a maintenance action, e.g. time, usage or component condition (see, e.g., Pintelon et al., 1997). A careful consideration on component level should be made to determine which maintenance policy is the most appropriate. For the MetalFAB1 system, Additive Industries has not yet determined how to maintain the installed systems. Properly defined planned (preventive) maintenance actions can contribute to system availability improvement and realization of cost reduction (Rausand, 1998). This provides an opportunity for the company to achieve the high system availability demanded by the customers. This is the motivation for the company for having researched how an effective maintenance program for MetalFAB1 should look like. The latter includes a list of maintenance policies for effective maintenance of the system. This leads to the following problem statement for the project: Problem Statement: The absence of a good maintenance program for MetalFAB1 may restrict its availability performance and may cause unnecessary costs.

1.3

Relevance of the Project

Additive Industries recently introduced the MetalFAB1 into the industrial AM market. In the near future it is expected that sales will start to grow, and thus the number of systems installed at customer sites. These customers will require their systems to be available for production. In order to fulfill this customer need, maintenance and service actions will be required. Additive Industries will have to support customers with maintenance and service related activities (e.g. maintenance actions, service engineers, spare parts etc.). At the time of writing, these activities are being developed within Additive Industries. This project will contribute to this development by the development of a maintenance program for MetalFAB1. Since there is no extensive maintenance organization or program yet, this project can be considered as a â&#x20AC;&#x153;greenfield projectâ&#x20AC;?. This also offers the opportunity to integrate advanced maintenance models and strategies (e.g. condition based maintenance) directly from the start within the maintenance program of MetalFAB1. The project mainly focuses on designing a solution

for Additive Industries rather than contributing to the scientific state-of-art. However, this project also has relevance to this end, since we propose several contributions to the literature. First, we propose a novel approach for failure analysis of a complex capital good (see Chapter 3). Second, we propose a customized maintenance concept that can be used to develop a maintenance program for a capital good (see Chapter 5 and 6). This maintenance concept was developed specifically for the company, but also offers new insights for other companies and the scientific state-of-art.

1.4

Structure of the Thesis

The rest of this thesis is organized as follows. In the next chapter, Chapter 2, we describe the research design for this project. The chapter starts with an discussion of the relevant literature, on which we base our research questions. Subsequently, in Chapter 3 we treat the first research question: What is the failure behavior of MetalFAB1?. In this chapter, we start with a discussion of two frequently used methods for failure analysis from literature, FTA (Fault Tree Analysis) and FMECA (Failure Modes and Effects Analysis), whereafter we describe a novel method. The chapter ends with a case study of this novel method to MetalFAB1. The next chapter, Chapter 4, treats the second research question: What is the maintenance objective for MetalFAB1? In this chapter we discuss the derivation of the maintenance objective for MetalFAB1. Subsequently, we build a detailed specification for the maintenance concept that links to the third research question. The third research question is: What is a suitable maintenance concept for MetalFAB1? This research question is treated in Chapter 5 and 6. In Chapter 5 we discuss the conceptual model of the maintenance concept. In Chapter 6 we discuss the detailed design of the maintenance concept and the application to the MetalFAB1 in a case study. The latter is also related to our final research question: What are the most appropriate maintenance policies for maintenance critical items of MetalFAB1? In the final chapter (Chapter 7), we discuss the conclusions and recommendations based on our work.

Chapter 2

Research Design In this chapter we discuss the research design for this project. First, Section 2.1 summarizes a review of the related literature. Subsequently, we introduce our main and sub research questions in Section 2.2.

2.1

Literature

Techniques TPM

Maintenance process

LCC

BCM RCM

CIBOCOF ILS/LSA

Maintenance objective

Capital good

In this section we give a summary of the literature relevant to our problem. We base this summary on a literature review on maintenance of capital goods (see, Peeters, 2016) and we refer to this document for full details. The subsequent part of this section is organized as follows. Section 2.1.1 introduces maintenance of capital goods and describes a framework that we use to structure our discussion of the literature. Section 2.1.2 describes the literature relevant to failure analysis and machine reliability of capital goods. Next, Section 2.1.3 describes the literature on maintenance concepts. Finally, we discuss maintenance policies in Section 2.1.4. Figure 2.1 provides an overview of the scope of our discussion and also shows how the different topics interrelate. Moreover, the figure provides a summary of useful techniques from literature for the building blocks that are within the scope.

Maintenance concept

Section 2.1.3

Techniques Failure mechanisms

Section 2.1.2 FTA

Failure Behavior

Maintenance policy

RBD

FME(C)A

Reliability predictions

Maintenance approach

Maintenance execution

Techniques Opportunistic maintenance

Section 2.1.4

Group maintenance Maintenance performance

UBM

LBM

TBM

CBM

Section 2.1.1

Figure 2.1: Overview of Maintenance of Capital Goods, adapted from Goossens (2015). Hatched blocks are out of scope of this project.

2.1.1

Maintenance of Advanced Capital Goods

Since the topic of maintenance of advanced capital goods is broad, we use the framework of Goossens (2015) to structure and position our work. Goossens (2015) considers maintenance of technical assets as a process of different tiers on strategic, tactical and operational level. This process starts with the definition of the maintenance objective, which should be closely linked to the company’s strategy. In defining the objective, one has to ask him- or herself what has to be achieved by maintenance. The next step in the process is the selection of an appropriate maintenance concept to reach the previously defined maintenance objective. This concept is a structured approach to develop a maintenance plan that includes all required maintenance actions. Subsequently, one has to decide which maintenance policy should be used for each specific component or (sub)module that requires maintenance. A maintenance policy prescribes which parameter triggers a maintenance action, e.g. time, usage or component condition (see, e.g., Pintelon et al., 1997). In order to be able to select and define the best maintenance policy, information on failure behavior (or machine reliability) is a required input. The failure behavior of the capital good describes the functional failure modes of the system and when they are expected to occur. Next, the maintenance approach and action itself have to be designed. After that, the maintenance action can be executed in the field on the operational level. Finally, there is a feedback loop back to the maintenance objective for further optimization. This framework is shown in Figure 2.1. The following four parts of this framework will be discussed further: (1) Failure Behavior, (2) Maintenance Objective, (3) Maintenance Concept and (4) Maintenance Policy. The other building blocks are out of scope of this project due to a limited amount of time. For more details, see Peeters (2016).

2.1.2

Failure Behavior of Advanced Capital Goods

In this section, we discuss the failure behavior of advanced capital goods (refer to the building block “failure behavior” in Figure 2.1). To be able understand the failure behavior of a complex system, it is of utmost importance to have a clear definition of what a failure is. In this report, we define a failure as “. . . reaching a state such that the intended function of the part or system can no longer be fulfilled” (Tinga, 2013, p. 3). Such a functional failure can be defined in terms of: (1) its failure mode, (2) its cause, (3) consequence of the failure and (4) a failure mechanism. The concept of failure mode can be defined as the manner in which a component functionally fails. For example: a broken wheel of a bicycle (failure mode) leads to that the bicycle cannot be used for cycling (functional failure). The cause of a failure mode can be of different natures; the failure can be induced due to a human error or contamination (non-physical) or due to a certain failure mechanism (physical). A typical non-physical cause would be loading a wrong type of fuel in a car. A physical cause, on the other hand, could be for example wear of a bearing in an engine. The consequence of a failure is the extent to which the failure affects higher level functionality. For example, a failure of a small component in a certain module can disrupt the whole system (thus a critical failure) or, in contrast, the component has no influence at all on the functionality of the system (irrelevant). Failure mechanisms, finally, are processes (mechanical, physical, chemical) that lead to degradation of a component. This degradation of a certain property of a component then may lead to a functional failure. Examples of failure mechanisms are deformation (mechanical), ageing (electric), melting (thermal) or oxidation (chemical) (see, e.g., Tinga, 2013).

The next important concept related to the failure behavior of complex capital equipment is reliability. The reliability of such equipment can be defined as the probability that it will perform a specific function without failing in a certain time span (see, e.g., Pintelon et al., 1997). The reliability of a system is determined by its underlying functional failures. For a complete system, the failure behavior can be complex, since such a system is typically composed of thousands of components with inter-dependencies and interrelations. Each of those individual components may on their turn have multiple failure modes and underlying failure mechanisms. In order to grasp this complexity, several methods have been developed that help to identify, assess and quantify the critical functional failure modes of a system. For example: Failure Modes, Effects and Criticallity Analysis (FMECA), Reliability Block Diagrams (RBDs) and Fault Tree Analysis (FTA). FMECA and (qualitative) FTA are useful for the identification of failure modes, whereas RBDs and quantitative FTAs are useful for quantitative modeling of a system. In Chapter 3, we discuss two methods to our project relevant to our project (FTA and FMECA) in more detail. Finally, to determine the relevant reliability metrics (e.g. the Mean Time To Failure, M T T F ) standardized testing procedures are available in literature (see, e.g., Dhillon and Reiche, 1985).

2.1.3

Maintenance Objective and Concepts

In this section, we discuss the importance of a “Maintenance Objective” and a “Maintenance Concept” subsequently (refer to Figure 2.1). The importance of a clear definition of the goals and focus for maintenance is widely recognized in all maintenance literature. As stated before, Goossens (2015) considers this as the starting point of maintenance. The maintenance objective involves a vision, mission and long term goals for all maintenance activities and plans for a capital asset and is generally defined in terms of technical, financial or customer service targets which include: system availability, system reliability, safety, risk, customer service or maintenance cost. Kelly (1997) argues that the following factors should be taken into account in the formulation of an overall maintenance objective statement: (1) the corporate objective, (2) maintenance resources (people, spares, tools, information), (3) asset output factors (e.g. desired production output), (4) asset safety factors and (5) asset life factors. Next, we review the literature on maintenance concepts. In our context, we define a maintenance concept as a systematic approach to decide on maintenance policies for subsystems or components. As such, it provides decision support on tactical maintenance decisions to reach the strategic objective. In addition, we introduce the notion of a “maintenance program”. The latter is defined as the result of applying a maintenance concept to a specific situation (i.e. a certain capital asset or machine) and comprises a list of maintenance policies and actions for the components of a system. In our view, there are six maintenance concepts related to our definition and most frequently mentioned: (1) Total Productive Maintenance (TPM) (see, e.g., Jain et al., 2014), (2) Life Cycle Costing (LCC) (Woodhouse, 1993), (3) Reliability Centered Maintenance (RCM) (Nowlan and Heap, 1978), (4) Business Centered Maintenance (BCM) (Kelly, 1997), (5) Centrum voor Industrieel Beleid Onderhouds Concept Ontwikkelings Framework (CIBOCOF )(Waeyenbergh, 2005) and (6) Integrated Logistic Support (ILS) (Jones, 1987). We now briefly compare these concepts. We refer to Peeters (2016) for a detailed comparison of those concepts. We can identify the following similarities. Firstly, the importance

of a clear definition of the goals and focus for maintenance is recognized in all of the maintenance concepts; all the concepts start with the formulation of an objective statement and targets. Secondly, it appears that a technical/functional system analysis is a common step in all approaches to focus on the most critical (sub)systems. However, the character of this analysis varies between the concepts (e.g. cost break-down in LCC versus technical analysis in RCM). Besides similarities, we can also identify differences between the concepts. Firstly, the focus between the concepts varies; for example TPM focuses on maximizing availability and productivity and minimizing waste and defects; ILS/LSA and BCM focus on minimization of costs and other economic criteria; RCM focus on maximizing reliability and safety and CIBOCOF on minimizing cost and/or maximizing availability. Secondly, the concepts differ in the manner in which they provide decision support. Especially the RCM, BCM and CIBOCOF concepts provide explicit decision support tools by means of decision trees to decide on the best maintenance policy/action for a certain component or subsystem. TPM and ILS provide an overall view on maintenance, including all technical, human and organizational aspects. LCC is mainly focused on evaluation of cost and does not provide decision support for maintenance policy selection. Since we are especially interested in decision support on maintenance policy selection, RCM, BCM and CIBOCOF seem to be the most interesting concepts. If we specifically look into the latter concepts, we can identify differences in which maintenance policy types are considered. RCM considers five different types of maintenance policies that all can be linked to a single component maintenance policy model (see Section 2.1.4). BCM considers also five different types of maintenance policies (in BCM called approaches), but in addition also considers clustering and opportunistic maintenance ( multi component maintenance policy model). CIBOCOF considers many more maintenance policies, both single component as well as complex multi component models. Again, we refer to Peeters (2016) for more details.

2.1.4

Maintenance Policies

Finally, we review the literature on maintenance policy models. In the maintenance literature, many different models for maintenance policies have been developed that we classify according to (1) type of maintenance and (2) single versus multi component. With regards to the first classification, we distinguish between reactive, preventive and aggressive maintenance policies (Tinga, 2013). Reactive policies can seen as acting according to a â&#x20AC;&#x153;fire-fighting approachâ&#x20AC;? in which maintenance actions are based on actual failures. The second category comprises the policies that are developed to prevent system failures. Aggressive policies, finally, have the goal to improve the system to prevent failures (e.g. redesign actions). The second classification is the distinction between single and multi component maintenance models. Many of the published models and policies only consider a single component, while others consider a whole system with many different components (see, e.g., Wang and Pham, 2006). These models often have the objective to optimize and coordinate maintenance from a system perspective instead of component specific. In general, the latter type of models are more complicated and may be beneficial if structural, economic or stochastic interdependence exists between components (Dekker et al., 1997). Within single component maintenance policies, we recognize the following most frequently mentioned maintenance policies. In the category reactive maintenance, there is essentially of

one policy available, which is Failure Based Maintenance (FBM). In this policy, the maintenance action takes place upon a failure occurs. In the category preventive maintenance, we distinguish between three policies. First, in the Time Based Maintenance (TBM) policy, the maintenance action takes place after a fixed amount of time (trigger is time). Second, in the Usage Based Maintenance (UBM) policy, the maintenance action is triggered based on reaching a threshold level of a componentâ&#x20AC;&#x2122;s usage (trigger is usage). Third, in the Condition Based Maintenance (CBM) policy, the maintenance action is triggered based on the actual condition of a component (trigger is condition). Finally, in the category aggressive maintenance, we identify one type of â&#x20AC;&#x153;maintenance policyâ&#x20AC;? that can be defined as Design Out Maintenance (DOM). In this policy (essentially not really a policy), a redesign action is performed to improve the system in order to prevent/eliminate failures. Within multi component maintenance models we can further distinguish between group maintenance and opportunistic maintenance (see, e.g., Wang and Pham, 2006). Group maintenance policies consider the replacement or repair of a group of n components at the same time. Often, components are clustered into groups that have joint maintenance intervals (see, e.g., van Dijkhuizen and van Harten, 1997). Opportunistic maintenance models synchronize maintenance actions by taking advantage of the time that the system is not in use, see e.g. Kobbacy and Murthy (2008), Zhu (2015) or van Horenbeek (2013). The time that the system is not in use can be due to scheduled machine downs (e.g. preventive maintenance on other components) and unscheduled machine downs (e.g. component failures). Opportunistic maintenance recognize these machine downs as opportunities to perform preventive maintenance actions to optimize the system cost or availability.

2.2

Research Questions

In the present section, we introduce the main research question and sub research questions. Given the context and problem statement as discussed in Chapter 1, the following main research question has been defined: Main Research Question: What is an effective maintenance program for MetalFAB1? The motivation for defining this question is as follows. For Additive Industries it is important to ensure an availability performance level for its prospective installed base. This requirement follows from the expectation of customers to have a reliable machine. In order to accomplish a high availability level of installed machines, proper preventive maintenance can help to increase uptime and to prevent downtime (see, e.g., Rausand, 1998). Since Additive Industries has not yet determined how to maintain installed systems, this project tries to find an answer to this. More specifically, the project aims to find an (initial) effective maintenance program that consists of maintenance policies. The final deliverable of the Master thesis project is a maintenance program that includes these maintenance policies. The supply of spare parts, service engineers and organizational aspects are out of scope for this project. The remainder of this chapter introduces the sub research questions that have to be investigated in order to answer the main research question.

To answer the main research question four sub research questions have been defined. First, knowledge has to be gained about the system and its failure behavior. Since the MetalFAB1 is complex machine consisting of many components and functionality, its failure behavior may be complex. A detailed understanding of the failure behavior is important, since it provides input for maintenance decisions and maintenance policy selection. The failure behavior of a system describes how a system functionally fails such that its intended function no longer be can be fulfilled (Tinga, 2013). These functional failures can be described by its failure modes, failure causes, failure causes and underlying failure mechanisms. Functional failures can take place on system, subsystem or component level and may or may not have an impact on the overall system availability or performance. In short, the first sub research question aims to understand the system functions and failure behavior of the MetalFAB1. This leads to research question 1: Research Question 1: What is the failure behavior of MetalFAB1? In order to answer this question, we analyze the failure behavior of the MetalFAB1 with a failure analysis. As we will describe in Chapter 3, we use a novel approach that combines Fault Tree Analysis (FTA) and Failure, Modes, Effects and Criticallity Analysis (FMECA). We will use the knowledge obtained in Research Question 1 in the selection of maintenance policies (Research Question 4). However, if we follow the maintenance process as depicted in Figure 2.1, two requisites are needed prior to maintenance policy selection: (1) a well-defined maintenance objective and (2) a maintenance concept. The starting point should be the maintenance objective, which encompasses the overall goal for maintenance decision making. The maintenance objective follows from the business strategy and business objectives and is generally defined in terms of technical or financial targets. It is crucial to define a clear statement about the objective for maintenance, since it determines the effectiveness of subsequent maintenance implementations and schedules (see, e.g., Marquez, 2007). This leads to the second research question: Research Question 2: What is the maintenance objective for MetalFAB1? The research approach for Research Question 2 is to interview relevant stakeholders (e.g. board members and middle management). Moreover, to link Research Question 2 to Research Question 3, we extend the maintenance objective statement into a detailed requirements specification for the maintenance concept. In order to reach the maintenance objective defined in Research Question 2, a suitable maintenance concept can provide guidance. We define a maintenance concept is a systematic approach to decide on maintenance policies. Such maintenance concept provides guidelines and decision support with a certain focus (e.g. cost or reliability). A well known example of a widely used maintenance concept is Reliability-Centered Maintenance (RCM) which focuses on a reliability objective (Rausand, 1998). RCM provides a decision framework to select the most appropriate maintenance policies to improve reliability of the asset (Rausand, 1998). Other established maintenance concepts include (Section 2.1.3): Integrated Logistic Support

(ILS) (Jones, 1987), Business-Centered Maintenance (BCM) (Kelly, 1997), Life-Cycle Costing (LCC) (Woodhouse, 1993) or CIBOCOF (Waeyenbergh, 2005). Alternatively, one can also develop a company specific maintenance concept that combines parts of the previously stated concepts from literature. This leads to sub research question 3: Research Question 3: What is a suitable maintenance concept for MetalFAB1? To answer Research Question 3, we investigate the available maintenance concepts in the literature to develop a customized maintenance concept for MetalFAB1. The maintenance is customized for this application, since it has to comply to a set of company specific requirements (defined in Research Question 2). The subsequent step is to apply the maintenance concept developed in Research Question 3 to MetalFAB1. Applying the concept should reveal the best maintenance policy on component level. The knowledge about the failure behavior (Research Question 1) is required input information to select the right policy. This information is required, since it explains the failure modes, failure causes, failure causes and underlying failure mechanisms of the components. It is expected that not every component is critical from a maintenance perspective, thus only the maintenance critical items will be considered. This leads to the last research question: Research Question 4: What are the most appropriate maintenance policies for the maintenance critical items of MetalFAB1? The expected outcome of Research Question 4 is be a list of recommended policies for the maintenance critical items and comprises the maintenance program for the MetalFAB1. This provides an answer to our Main Research Question. In Figure 2.2 we show our research framework, which summarizes the research questions and interrelationships.

Research Question 2:

Maintenance process

What is the maintenance objective for MetalFAB1?

Maintenance objective RQ2

MetalFAB1

Research Question 3:

What is a suitable maintenance concept for MetalFAB1?

Research Question 1:

RQ1 Failure Behavior

Maintenance concept

Maintenance policy

RQ3

RQ4

What is the failure behavior of MetalFAB1? Research Question 4:

What are the most appropriate maintenance policies for the maintenance critical items of MetalFAB1?

Maintenance approach

Maintenance execution

Maintenance performance

Figure 2.2: Research framework. Hatched blocks are out of scope of this project.

Chapter 3

Failure Analysis In this chapter the first research question is answered. Research Question 1: What is the failure behavior of MetalFAB1? The failure behavior of a new complex capital good can be complex and comprehensive. In this chapter we develop a novel method to efficiently evaluate the failure behavior of the system under investigation, the MetalFAB1. The subsequent part of this chapter is organized as follows. Section 3.1 describes a comparison of two frequently used methods from literature (Fault Tree Analysis and Failure Mode and Effects Analysis) and the need for another method in our case. In Section 3.2 we describe our new approach, that we call a Recursive FTA-FMECA approach. Section 3.3 describes the results of applying our new method to MetalFAB1 in a case study. The chapter ends with a short conclusion on the aforementioned in Section 3.4.

3.1

Failure Analysis

From a literature review (see, Peeters, 2016), we have seen that there are different methods to investigate the failure behavior of a system. These methods include Failure Modes and Effects Analysis (FMEA), Fault Tree Analysis (FTA) or Reliability Block Diagrams (RBDs). In this project, in which we have to analyze a completely new and large system, (qualitative) FTA and/or FMEA are both applicable. RBD analysis is less applicable, since this method focuses more on quantitative modeling of failure behavior (i.e. determine a system reliability function, see e.g. Birolini (2010) or Peeters (2016)) when the underlying failure modes are known. The latter is not the case in this project. However, it is not evident which method, FMEA or FTA, is the best in the present project. We can use either FMEA, FTA, or a combination. First, we provide a short description of both FMEA and FTA in Section 3.1.1 and Section 3.1.2 respectively. Subsequently, we compare the applicability in detail in Section 3.1.3.

3.1.1

Failure Modes and Effects Analysis

FMEA (Failure Modes and Effects Analysis) is a systematic method to map failure modes, effects and causes of technical systems (see, e.g., Bertsche, 2010). It is an inductive and bottom-up method, since the analysis starts at the component level where the possible component failures are identified and examined what the consequences are on a higher level. An FMEA can be applied to a process (called a process FMEA) as well as to a product (called a product FMEA). Moreover, the analysis can be used in different stages of a productâ&#x20AC;&#x2122;s (or process) lifetime. For example, in the conceptual design phase it is a useful tool to identify a productâ&#x20AC;&#x2122;s weaknesses in an early stage or in the operational phase where it can be used to evaluate existing equipment (see, e.g. Blanchard and Fabrycky, 2006). Usually, the FMEA is carried out with a diverse team of people with various backgrounds (e.g. mechanical design, software, operations, maintenance) since this increases the probability that more possible failures are identified and the effects properly estimated (see, e.g. Tinga, 2013). The FMEA can be extended to an FMECA (Failure Modes, Effects and Criticality Analysis) by adding a criticallity analysis. In this way, the purely qualitative FMEA can be made more quantitative. In FMECA, the criticality of each failure mode is quantified by the risk priority number (RPN). The RPN is the product of three indexes: (1) a severity rate (S), (2) an occurrence rate (O) and (3) a detection rate (D) of a failure. These indexes are usually rated on a scale from 1 to 10 or from 1 to 5 (see, e.g. Tinga, 2013). There are standards available that provide guidelines for the assessment of each index, see e.g. DoD (1980) or Blanchard and Fabrycky (2006). The severity of a failure refers to the seriousness of the effect or impact of a certain failure. The severity rate is rates from low impact (e.g. 1 on a scale 1 to 10) to very high impact (e.g. 10 on a scale 1 to 10). The occurrence rate of a failure refers to relative frequency of occurrence of the failure. The occurrence rate should be rated from unlikely to occur (e.g. 1 on a scale 1 to 10) to almost inevitable (e.g. 10 on a scale of 1 to 10). Finally, the detectability index refers to the likelihood that the failure can be detected before it induces major subsequent effects (e.g. by means of process controls, procedures or operator detectability). The detectability rate should be rated from almost sure detection (e.g. 1 on a scale 1 to 10) to almost sure non-detection (e.g. 10 on a scale of 1 to 10). The results of an FMEA/FMECA are usually recorded on a spreadsheet (see, e.g., Tinga, 2013). Figure 3.1 shows an example of a spreadsheet template to record the results of an FMEA/FMECA and presents guidelines for the determination of the RPN.

Figure 3.1: FMECA sheet

3.1.2

Fault Tree Analysis

Alternatively, we can use Fault Tree Analysis (FTA) to investigate the failure behavior. A fault tree is a logic diagram that represents the relationships between an event (typically a system failure) and the causes of the event (typically component failures). It uses logic gates and events to model how the component states relate to the state of the system as a whole. The commonly used logic gates in FTA are: the (1) OR-gate, (2) AND-gate and (3) inhibit or conditional gate. The commonly used event-types in FTA are the (1) top or intermediate event, (2) basic event, (3) undeveloped event and (4) conditional event. In addition, the analyst may use a transfer symbol to refer to other parts of the fault tree where the same logic applies (“copy-paste”). We refer to Stamatelatos et al. (2002) and Figure 3.2 for a detailed description of each symbol. In FTA there are two types: (1) a purely qualitative FTA and (2) a quantitative FTA (see, e.g., Bertsche, 2010). In our situation only the first type, a purely qualitative FTA, is applicable since the method is used for the identification of failure modes of a system in a systematic way. The second type, a quantitative FTA, is less interesting in our situation because it is mainly used to determine a system reliability function (as an alternative for RBDs). In essence, a quantitative FTA is an extension of a qualitative FTA by adding quantitative information to each event to determine a reliability function for the system as whole using boolean theory (see, e.g., Hamada et al., 2008). Figure 3.2 shows an example of a (qualitative) fault tree and the commonly used symbols in FTA. In this example, which is a part of a larger FTA from Appendix B, the failure event “Top rotary valve does not dose” is evaluated. We will not go into the details of the content of the diagram. Legend Events

Definition Top or intermediate event

Top rotary valve does not dose

Basic event

No motor torque

Drive train not functioning

Top RV servo motor broken

Coupling fails

Rotary valve (RV) jam

Undeveloped event

Conditional event

Description based on Stamatelatos, et al. (2002) The retangle describes a top or intermediate fault event. A top event decribes a particular system failure mode with specific boundary conditions for the system as a whole. An intermediate event describes the sub-top events correspond that to the top event, until ultimately, the limit of resolution of the tree is reached. This limit consists of basic component failures (basic events) The circle describes a basic initiating fault event that requires no further development. In other words, the circle signifies that the appropriate limit of resolution has been reached.

The diamond describes a specific fault event that is not further developed, either because the event is of insufficient consequence or because information relevant to the event is unavailable.

The ellipse is used to record any conditions or restrictions that apply to any logic gate. It is used primarily with the INHIBIT gates

Wear coupling

Gates

Definition

Description based on Stamatelatos, et al. (2002)

OUT

Slit too tight

Powder stuck in RV

Wear of rotor in RV

Bearing stuck

OR-gate

Opens when one of the ingoing events occur

IN IN OUT

AND-gate Wear bearing

Adjustment of slit too tight

Opens when both ingoing events occur

OUT

Wear bearing

Sealing leaks Inhibit gate IN IN

Opens when a (single) input fault occurs in the presence of an enabling condition (the enabling condition is represented by a CONDTIONING EVENT drawn to the right or left of the gate). An example of such a conditioning event is a catalyst In a chemical reaction.

Transfer IN

Wear “simmerring en”

Transfer OUT

Wear Orings

Transfer symbol

Transfer to other part of diagram that uses the same logic

Figure 3.2: Example of FTA for the event “Top rotary valve does not dose”

3.1.3

Comparison

If we use either FMEA or FTA for the complete failure analysis of the system, we could face some difficulties. FMEA is an inductive and non-structured approach to identity failure modes and design weaknesses. The method has already been used within the involved company to identify design flaws during development of the system. The methodology of FMEA is thus already known within the development team. Furthermore, it can be extended to a FMECA by incorporating a quantitative measure of risk (the risk priority number, see also Section 3.1.1). However, FMEA is most effective when it is used in sessions with a diverse team and when the team members have experience with the operation of the machine (see, e.g., Bertsche, 2010). In our situation this might be an obstacle, since it is a completely new machine and the failure behavior is not known from practice. Secondly, the system under investigation is large and complex. This means that in a non-structured approach, it may be difficult to define a starting point and maintain a focus on the most prevalent failures. In addition, FMEA is a bottom-up, inductive approach that may make it even more difficult to determine â&#x20AC;&#x153;where to search for failure modesâ&#x20AC;? when there is a lack of practical experience. Lastly, when FMEA is applied to a complete system it may be hard to achieve enough depth of analysis to get a full understanding of the failure behavior. Alternatively, we can use the deductive and structured FTA method to identify failure modes. FTA is less known within the company, but is nevertheless a good alternative approach. FTA is more structured compared to FMEA. This can be an advantage when a completely new system is analyzed and there is little practical experience with system failures from the field. Due to the structure and deductive reasoning in FTA, it does not rely so much on practical experience of the expert as FMEA does (Tinga, 2016). In addition, FTA can also be considered as a more rigorous approach. Secondly, the complexity of the system under analysis implies that it would be difficult to perform a FMEA over the complete system with enough depth of analysis (see, e.g., Yu et al., 2011). This is also the case for FTA, but the analyst may choose to only go deeper into specific parts or branches of the fault tree. Thirdly, FTA is a graphical method that is easier to interpret and to identify interrelations compared to FMEA. In addition, the structure of FTA forces the analyst to decompose the system. FMEA and FTA can also be used complementary to each other (Peeters, 2016). Some authors, e.g. Bertsche (2010), argue that this may expand the number of failure modes found due to the different starting points of both methods; bottom-up in FMEA versus top-down in FTA. However, performing both analyses would be rather time consuming and may lead to a loss of focus on the most critical parts of the system. Alternatively, Yu et al. (2011) propose a mixed approach of FTA and FMEA. They propose to perform an FTA first to identify the main causes, and subsequently perform an FMEA on these causes (bottom events) to connect each cause to component or part failure (s). Yu et al. (2011) argue that in their method the FTA works as a kind of guide for the FMEA. In our view, this is an interesting idea. To select which bottom event should be analyzed with an FMEA, they determine the minimum cut set(s) in the FTA. A minimum cut set is the smallest set of basic events, which if they all occur will result in the top event occurring. In conclusion, it is not evident to use either FTA, FMEA or both when analyzing a new complex engineering system. We propose a novel, mixed approach in the next section.

3.2

A Novel Approach for New Complex Systems: Recursive FTA-FMECA

To make use of the strengths of both FTA as well as FMECA, we developed a new approach with Professor in Maintenance from University of Twente, Prof. Dr. Ir. Tiedo Tinga. This method was inspirered by the approach of Yu et al. (2011) and we define it as Recursive FTAFMECA. The motivation for the development of a novel approach is that neither FMECA nor FTA is an evident best choice to analyze the failure behavior of a completely new complex system effectively (see former section). Also, performing both an FMECA and an FTA is not the best solution because that would be too time consuming. We argue that an integration of both, like proposed by Yu et al. (2011), is better. However, we argue that the approach of Yu et al. (2011) is still not optimal for large complex systems, since they only provide an example of a small system and we are not convinced of their method of prioritizing of failures (only by the minimal cut set in the FTA). Moreover, we argue that it may be useful to have more than one separation or prioritizing step and allow for more depth of analysis. For example, in some cases in may be useful to have a deeper detail in the analysis than up to component level failure (i.e. up to the level of failure mechanisms). Next, we present and motivate our proposed new approach in Section 3.2.1. In the subsequent sections (Section 3.2.2 and Section 3.2.3) we discuss and reflect on the alternative considerations we made. To show how the approach is applied, we show a simple example in Appendix A. In this example, we consider a simple boat to investigate its failure behavior. We remark that the approach is especially suitable for complex systems, but this example shows how the approach works.

3.2.1

Recursive FTA-FMECA

We propose a new approach that uses FTA and FMECA multiple times in a recursive way. The scope and depth of analysis of each FTA and FMECA differs through the analysis. To explain our approach, we first argue that we have to perform two steps in a failure analysis: (1) identification of failure modes and (2) assessment of the criticallity. These two steps follow from a review of the literature (Peeters, 2016). Second, we recognize a need for decomposition in the level of analysis (i.e the level on which an analysis is performed). In a complex engineering system we can distinguish between three levels: (1) system level, (2) function level and (3) component level. In each level, we can identify functional failure modes. We need this decomposition, because each analysis needs a clear scope to be effective (Bertsche, 2010) and a delimited depth of analysis. Moreover, it allows us to integrate prioritizing that can be used to focus the overall analysis in such a way that the prevalent failures of the system have more depth of analysis. This will be more clear in the subsequent part. The recursive FTA-FMECA starts with an analysis on the system level. The analysis consists of two stages: (1) identification of failure modes and (2) assessment of criticallity. First, we perform an FTA on the system level to identify the principal functional failure modes of the system functions. We define these as system functional failure modes (S-FM). The initial starting point of the analysis is a top event for a failure of the system as a whole. This top event has to be defined clearly, because it determines the effectiveness of the whole analysis. The scope of the analysis is the whole system. The depth of analysis (i.e. when the analysis is deep enough and the analysis should stop) is up to the level of system functional failure modes (S-FM). More specifically, we define a system functional failure mode as

a failure mode describing a failure of a major system function for which we can determine its effects and causes and estimate its risk (a risk assessment). In other words; it should not be too broad because otherwise we can not perform a risk assessment and not too narrow because otherwise it is not describing a major system function. Second, we perform an assessment of criticallity by means of an FMECA on the identified system functional failure modes. This teaches us how prevalent each system functional failure mode is and it should be quantified with the Risk Priority Number (refer to Section 3.1.1). Next, we can rank these failure modes on this RPN number to select the system functional failure mode(s) that are the most critical and should be analyzed further. How many failure modes are selected for further analysis depends on the time available for the complete analysis and the available information. The goal of this first part, the analysis on system level, is to determine the most critical system functions of the system as a whole. An analysis on this level is required to focus the overall analysis only to those functions that have a major effect on a system failure (the top event in the FTA). Moreover, especially when a complete and new system has to be analyzed, one can choose to select only a few (e.g. the top 3) system function failure modes for further analysis. This ensures that the focus remains on the most prevalent failures. Next, we shift one level down to the function level. Again, we perform an FTA for identification of failure modes and an FMECA for assessment of the criticallity. In the first stage, the FTA, the top event is a failure of a system function (a system functional failure mode). The scope of the analysis is the system function and the depth of analysis is up to component failures. Thus, the FTA stops when component functional failure modes (C-FM) are identified. Subsequently, we perform an FMECA to assess the criticallity of each component functional failure mode. This teaches us how prevalent each component functional failure mode is. Moreover, as in the analysis on system level, we can rank the component functional failure modes on RPN to identify the most critical ones. A component failure mode may be considered critical if it has a high RPN. The main goal of the second part is to link a critical system function failure to component failures and assess its impact through a criticallity assessment. As such, this analysis provides tangible information on which component failures affect a major system function failure that may result in a system failure. The output on this level could be used as an input for maintenance decisions. In addition, depending on the context, we may want to extend the analysis one step deeper to understand the underlying failure mechanisms of such a component failure. Then we move to the final part of the analysis. In this last part, we shift the analysis to the deepest level in a complex engineering system: the component level. As in the previous analyses, we perform both an FTA and FMECA. In the first part, the FTA, the top event is a component failure (a component functional failure mode). The scope in this FTA is narrowed to the component itself and the depth of analysis is to the level of failure mechanisms (M). Failure mechanisms are the deepest level of failures that we consider and describe the physical mechanisms underlying the failures of parts, components or structures (Tinga, 2013). To second part compromises an FMECA on the identified failure mechanisms. As stated previously, the goal of this final part is to understand the underlying failure mechanisms a component failure. This knowledge may be valuable when one wants to have detailed information on failure behavior. For instance, when one wants to design a maintenance policy based on a componentâ&#x20AC;&#x2122;s condition (i.e. condition based maintenance), it is required to understand the determinants of this condition (e.g. a certain failure mechanism).

Figure 3.3 shows a schematic overview of our approach. We indicate the three parts of analysis with colors: (1) system level (blue), (2) function level (green) and (3) component level (orange). In each part we perform two analyses: (1) FTA and (2) FMECA. In the following two sections, 3.2.2 and 3.2.3, we motivate and reflect on our choice to use respectively FTA for identification of failure modes and FMECA for the assessment of criticallity.

Identification of System Function Failures

System Level FTA SF_FM 1

SF_FM 2

SF_FM 3

SF_FM 4

SF_FM n

SF_FM 5

Ranking of Most Critical System Function Failures

System Level FMECA

C_FM 1

SF_FM 1

SF_FM n

Function Level FTA

C_FM 2

C_FM n

Function Level FMECA C_FM 1

C_FM n

Component Level FTA

Ranking of Most Critical Component Failures

Identification of Failure Mechanisms

Legend

Component Level FMECA M1

Identification of Component Failures

Ranking of Failure Mechanisms

SF_FM

System Function Failure Mode

C_FM

Component Failure Mode

Failure Mechanism

Figure 3.3: Recursive FTA-FMECA

3.2.2

Identification of Failure Modes

For the identification of failure modes, we argue that, in our approach, FTA is preferred over FMEA. Refer to Section 3.1.2 for a description of FTA. FMEA and FTA both applicable, but we prefer FTA because of its (1) structure, (2) reduced dependency on user experience and (3) rigor. First, we argue that for a new system for which the failure behavior is not yet understood or known, a structured analysis is more effective compared to a non-structured approach (see Section 3.1.3). Moreover, we can use the structure in FTA also to decompose the system easily. Especially when the system is large and complex, which is the case in our situation, this is an advantage. Second, FTA does not rely so much on practical or user experience of experts as FMEA does (see Section 3.1.3). Third, we consider the rigor of FTA as an advantage. Due to its deductive nature, we expect to be able to identify more failure causes than in FMEA. In addition, the rigorousness of FTA can be advantageous when a high level of depth of analysis (e.g. up to failure mechanism level) is required. A plausible negative consequence of rigor is that it can be time consuming. However, we tackle this issue in our recursive FTA-FMECA method by our division into three parts with each a limited scope; we only perform a (detailed) FTA for those functions (in the function level ) and those

components (in the component level ) that have a high criticallity. Another counterargument for FTA can be that it lacks of a method for the ranking of criticallity; an FMEA can be easily extended to an FMECA whereas the FTA does not possess such a feature. We tackle this issue in our approach by performing a separate assessment of criticallity after each FTA (see Section 3.2.3).

3.2.3

Assessment of Criticallity

The second analysis that we perform on each level is an assessment of criticallity. For the assessment of criticallity of the failure modes in each of the different levels, we use the FMECA approach. As stated in the previous section (Section 3.2.2), FTA lacks a method to assess the criticallity of failure modes. In FMECA we find a detailed approach by means of the RPN. The starting point for the FMECA is the resulting Fault Tree of the FTA. With this information, the first 3 columns of the FMECA-sheet (refer to Figure 3.1) can be filled-in. Subsequently, for each failure mode, the possible local effects, end effects, causes and methods of detection are evaluated. Next, we can determine a severity index (S), occurrence index (O) and detectability index (D) for each failure mode to calculate a RPN (where RP N = S∗O∗D). Refer to Section 3.1.1 for a description of FMECA. This results in a detailed risk assessment with a quantitative judgment. A drawback of the method of criticallity assessment in FMECA may be the conservative way of calculating the Risk Priority Number. In standard FMECA, the RPN number is calculated by simply multiplying the three indices for severity, occurrence and detectability. An improvement can be to use weighted RPN numbers (see, e.g., Xiao et al., 2011) or a fuzzy method (see, e.g., Wang et al., 2009). In this thesis, we will use the simple RPN for convenience. As an alternative to FMECA, we can also use a more advanced method of prioritizing among failure modes by means of a multiple-criteria decision-making method. The Analytical Hierarchy Process (AHP) is such a method that has already been used in the context of maintenance and is especially suitable for complex decisions that involve the comparison of decision elements (see e.g. Waeyenbergh (2005) or Brunelli (2015)). In AHP, the decision maker starts with an overall goal, the general objective. That objective can be reached if one tries to maximize a set of different criteria as much as possible. Moreover, for reaching the objective, there are different alternatives considered. This can be captured schematically in a decision hierarchy. Subsequently, based on pairwise comparisons, one can determine weights of each criterium and finally an overall score for each alternative. Refer to Brunelli (2015) for a detailed discussion on AHP. If we apply AHP to our situation, we can define, as an example, a decision hierarchy as depicted in Figure 3.4. As such, the AHP seems to be a (academically) good alternative, but we found out that the pairwise comparisons in AHP will be very time consuming. Moreover, we remark that the definition of the different criteria may be debatable and difficult. In conclusion, we argue that a relatively simple and proven approach by means of FMECA with the simple RPN (in which RP N = S ∗ O ∗ D) is an effective approach for in our method.

3.3

Case Study: Application to MetalFAB1

In this section we describe the application of the recursive FTA-FMECA approach to MetalFAB1. We describe the three analyses of the three levels consecutively: (1) system level (Section 3.3.1), (2) function level (Section 3.3.2) and (3) component level (Section 3.3.3).

Safety

Most Critical System Function

Availability of primary function (printing)

System Function 1

Material loss

System Function 2

Failure rate

System Function 3 . . .

Powder contact

Maintainability

System Function n

Repair cost

Criteria

Goal

Alternatives

Figure 3.4: Analytical Hierarchy Process

3.3.1

System Level Analysis

As described in Section 3.2, the analysis starts with an FTA analysis on the system level. The goal of this first analysis is to identify the main system function failure modes, starting from a top failure event for the whole system that describes under which circumstances it is not functional anymore. In the case of the MetalFAB1, the top event is that the system is not functioning properly (see Appendix B for a more detailed description). The analysis should stop when it is reasonable to estimate the risk and consequences of the each failure mode. In case of the MetalFAB1, we started with the system architecture (hardware and software) to draw the qualitative fault tree. The fault tree was drawn with the help and input of the designers of the MetalFAB1 from system, mechanical and software engineering. After 7 revisions, we end up with the final version of the system FTA as presented in Appendix B. The fault tree was reviewed with four internal specialists: the (1) system architect, (2) lead mechanical engineer, (3) lead software engineer and (4) senior system integrator. In addition, the FTA was reviewed with an external specialist on failure analysis Tiedo Tinga. Subsequently, we perform an FMECA on the identified system function failure modes. The so-called undeveloped events are excluded. The goal of this analysis is to determine the most critical system functional failure for further analysis. More specifically, we complete the FMECA-sheet as depicted in Figure 3.1. The result of the FMECA is included in Appendix B. The FMECA was performed and reviewed with the lead mechanical engineer. Next, we identify the most critical system function failure modes based on the RPN number of each failure mode (where a higher RPN means more critical). For the system under investigation, the top-6 consists of failure of the following system functions: (1) exposure (RPN = 120), (2) powder layer deposit (RPN = 120), (3) powder extraction (RPN = 50), (4) CTM process conditioning (RPN = 40), (4) AMC process conditioning (RPN = 40) and (4) heat treatment operations (RPN = 40). Since the time for this project is limited, we select the two most critical functions for the further analysis (exposure and powder layer deposit).

3.3.2

Function Level Analysis

Next, we perform a Fault Tree Analysis on the selected two functions. The final versions of the function FTAs are included in Appendix B. As described in Section 3.2, the analysis should stop when component failures are identified (i.e. the depth of analysis). Both FTAs where reviewed with the design engineer who is responsible for the design (Rob van Haendel for powder layer deposit and Erwin Wijn for exposure). We remark that the FTAs also include the results of the next analysis (i.e. the component FTAs of the component level analysis in the orange indicated areas). Subsequently, we perform an FMECA on the identified component failure modes. The socalled undeveloped events are excluded. The results of the FMECA are included in Appendix B. We remark that the tables also include the results of the next analysis (i.e. the failure mechanisms of component level analysis also included, see Section 3.3.3). We select the component failure modes for subsequent analysis (i.e. the component level analysis) based on a RPN cut-off value. We choose to select component failure modes with an RPN > 16 for further analysis. The cut-off value of 16 was chosen in such a way that the no more than 50 % of the component failure modes are selected for further analysis (see Table 3.1). We argue that this leads to a feasible number of component analyses (9 for powder layer deposit and 9 for exposure). Moreover, we argue that for the aim of our current analysis (to get an overall view of the failure behavior) this would an appropriate number. Obviously, a lower cut-off value would increase the number of selected component failure modes for subsequent analysis (and vice versa), but we argue that the overall analysis should focus on the most prevalent failures. We recognize that this parameter may vary in other case studies and influences the efficiency of the overall analysis (see also Section 3.4). Table 3.1: Comparison of cut-off value RPN Function FTA Unique Component Failure Modes Component Failure Modes RPN >16 Component Failure Modes RPN >10

3.3.3

Powder Layer Deposit 29 1 9 21

Exposure 22 2

(31%)

(72%)

(47%) (68%)

Component Level Analysis

In the final phase of the recursive FTA-FMECA, we perform an analysis on component level. As described in Section 3.2, the first step in this phase is to perform an FTA of the most prevalent component failure modes to identify its failure mechanisms. The final result of this 1 The number of unique component failure modes is equal to the sum of the unique component failure modes not chosen for further analysis (green annotated basic events) + the sum of the component failure modes chosen for further analysis in a component level FTA (orange indicated). The latter must also be included, since these were component failures in at this stage. See Appendix B 2 The same as for 1 . See Appendix B 3 Resulting component failure modes for which the function level FMECA revealed an RPN that is in accordance with the associated RPN cut-off value (>16 or >10). Results are not included, since we combined the results of the function level FMECA and component level FMECA for convenience (see Section 3.3.3)

analysis is added to the function FTA in the orange areas. Refer to Appendix B for the results. Again, the results were reviewed with the responsible design engineer. Finally, we complete the analysis by performing an FMECA on the identified failure mechanisms. The so-called undeveloped events are excluded. In this step, we extend the FMECA of the analysis on function level. The results of the FMECA are included in Appendix B: for the function powder layer deposit and for the function exposure. For convenience, we combined the final results of the analyses on function level and component level. We replaced the component failure modes that are analyzed in the component level analysis by its failure mechanisms (i.e. we deleted the row that described the component failure mode and added the rows that describe the failure mechanisms of that component). In the end, we end up with the final FMECA that compromises in total 55 failure mode/mechanisms for the function powder layer deposit and 77 for the function exposure.

3.4

Discussion and Conclusion

In this chapter we investigate the first research question: “What is the failure behavior of MetalFAB1?”. To answer this question, we first review two commonly used methods from practice: Fault Tree Analysis (FTA) and Failure, Modes and Effects Analysis (FMEA). We conclude that nor FTA nor FMEA is an evidently best method for our case. In our case, we have to analyze a completely new and large engineering system, the MetalFAB1, which failure behavior is unknown and may be comprehensive. In addition, at time of writing, there is a lack of practical experience and information on failure behavior of the system. If we only perform either an FTA or an FMEA, we face some difficulties (refer to Section 3.1.3). We recognize that both FTA and FMEA each have its strengths and weaknesses (refer to Section 3.1.3 for more details) and we develop a novel approach that combines FTA and FMEA in a recursive way. In our approach we distinguish between three levels of a system with each a clear scope and depth of analysis: (1) system level, (2) function level and (3) component level. On each level we perform two analyses: (1) an FTA for identification of failure modes and (2) an FMECA for assessment of criticallity. We argue that our new method is an improvement with respect only performing an FTA or FMEA for the whole system in the sense that it is both rigorous as well as efficient. Especially in our case, we want to have a detailed analysis but at the same time a focus on the most prevalent failures in the system. In our approach we effectuate this by recursively performing both FTA and FMECA, but only selectively for critical failures. Refer to Section 3.2 for a detailed discussion of our model. Next, we applied our new approach to the MetalFAB1 in a case study (Section 3.3). We have achieved a significant time saving based on the fact that we argue that we can exclude component failure modes from the component level analysis. In our opinion, component failures with RPN ≤ 16 may be considered as less critical and do not need to be analyzed further in a component level analysis up to failure mechanisms. In this way, we only 9+9 analyzed 29+22 · 100% ≈ 35% of the total number of component failure modes (resulting from the function level analysis) further and, as a result, saved time by not considering them all (see Table 3.1). In addition, we still have a detailed analysis up to the failure mechanisms of the most prevalent component failure modes.

We develop this method for failure analysis specifically for our situation, but our new approach could also be interesting for companies that face the same problem. In addition, to the best of our knowledge, a method that uses FTA and FMECA recursively has not yet been reported in literature. Although some authors (see, e.g., Yu et al., 2011) did consider the integration of FTA and FMECA into one analysis, we argue that our model is a new approach. As such we may consider our method as a new contribution to the literature on failure analysis for maintenance decisions.

Chapter 4

Maintenance Objective In this chapter, the second research question is answered. Research Question 2: What is the maintenance objective for MetalFAB1? This research question concerns deriving the maintenance objective of the company. The outcome of this research question provides input for the third research question (maintenance concept). In this chapter, we build towards a detailed specification for the maintenance concept. This chapter is organized as follows. Section 4.1 discusses the maintenance objective of Additive Industries for MetalFAB1 based on interview sessions with key stakeholders. Section 4.2 discusses the translation of the maintenance objective into a detailed specification for the maintenance concept. Finally, in Section 4.3 we discuss a conclusion on this chapter.

4.1

Maintenance Objective

The maintenance objective provides guidance for all future maintenance decisions within the company. The maintenance objective is closely related to the companyâ&#x20AC;&#x2122;s business/maintenance strategy and is typically defined in terms of technical, financial or customer service targets (see, e.g., Kelly, 1997). At the time of writing, Additive Industries just started setting up its service and support organization that will be responsible for maintenance of MetalFAB1 systems. This also implies that they are still working on defining a well founded strategy and objective for their service and support activities. Since it is not the focus of this Master Thesis Project to define a strategy in much detail, we keep this at a general level. Interviews with the CEO, Technology Manager, Process and Application Manager and Service and Support Manager provide input for defining the maintenance objective. Appendix C includes the transcripts of the interviews. From each of the interviews, the following general conclusions can be drawn. â&#x20AC;˘ Chief Executive Officer - Daan Kersten We want to offer the highest level of service and support to our customers. Besides our high quality products, we want to deliver a high quality standard of service and support. Preventive maintenance, system monitoring, remote service and fast support are important elements of hereof.

• Technology Manager - Mark Vaes The availability of the printing function of the MetalFAB1 system is key. For our customers it is important to have a machine that can be utilized for printing almost all the time. We already have taken this into account as a system requirement in our development process. • Process and Application Manager - Harry Kleijnen For our customers, the uptime of the system is high priority, but also when a system down occurs, we have to make sure that we react fast and communicate well with our customers. In that case, we have to make sure that we have spare parts available and offer appropriate support from specialists within Additive Industries. • Service and Support Manager - Remco Pennings For our the Service and Support organization to be profitable, we have to deliver high level support to our customers in a cost effective way. We want to beat our competitors by providing the best service perceived by our customer. Moreover, we believe that preventive maintenance and remote support will lead to lower cost. From the interview sessions, we conclude that the following aspects are important for the maintenance/service activities of the company. We define the maintenance objective by these three aspects: • Achieve a predetermined level of system availability. • Minimize customer visits of service engineers by offering remote service and support. • Minimize service costs. The first aspect, system availability, is considered as a key performance characteristic by all stakeholders. It is defined as the fraction of time that the system is able to print on a yearly basis. Moreover, it is considered as more important than cost. This is an important point for our project (maintenance policy selection), since there are maintenance policies that focus on cost minimization or on availability maximization. So, we should focus on availability maximization first. The second aspect, remote support, is based on the fact that Additive Industries strives to minimize service visits to the customer by offering remote support. At the time of writing, this is limited to a vision and people within the company are working on how this can be achieved. We consider this as a strategic aspect of the maintenance objective and we may want to take this into account in our maintenance concept. The final aspect, service costs, encompasses the objective to run the service organization activities at the lowest cost. However, as stated before, in a trade-off on availability versus costs, costs is less important. In the following section, the maintenance objective is extended into a set of requirements for the maintenance concept. The previously defined maintenance objective is the focal point in this. Furthermore, we use the User Requirement Specification (URS) for the development of the MetalFAB1 as a detailed input. The user requirement specification is an internal Additive Industries document that describes a detailed specification for the MetalFAB1 system based on the needs of the target customers.

4.2

Maintenance Concept Requirements

Before we go into the details of the requirements for the maintenance concept, we first describe our approach to develop such a maintenance concept. The maintenance concept can be considered as a design problem of a system or tool that should convert an input to an output, given a number of functional requirements and constraints. Using methodology from systems engineering, the maintenance concept can be seen as a black box. This black box has inputs that go into the box, outputs that come out and has functions have to be performed on the inputs to get the outputs (Muller, 2016). The functions specify what the black box should do, but without prescribing how to realize this. In this context the input is a list of maintenance critical items that require maintenance and the output is a maintenance program (i.e. a list of maintenance policies). The functions of the black box are (1) to select and (2) to specify the best maintenance policy. The black box is bounded by external boundaries and interfaces, functional requirements and constraints. The design problem is depicted as a black box in Figure 4.1.

Boundaries and interfaces

Inputs Âˇ Âˇ

Maintenance Concept Select maintenance policy Specify maintenance policy

Outputs

Functional requirements Constraints

Figure 4.1: Black box of the development of a maintenance concept, adapted from Muller (2016) If we look at the black box itself, we can subdivide the maintenance concept into a conceptual design and a detailed design. This subdivision is inspired by the approach for the design of operations planning systems by Fransoo (2015). This approach forces the engineer to split the problem into decoupled decision making modules that can be optimized separately. In the first stage, the conceptual design, a conceptual model is developed that defines each of these decision making modules and how they interrelate. Moreover, it specifies what decision is made in each module. Subsequently, in the detailed design, each module is designed in detail. This may include the integration/application of (optimization) models and precise decision making rules. The split into decoupled decision making units also leads to a reduced complexity, since each module is designed separately. In Section 4.2.1 - 4.2.5, the specifications of each incoming/outgoing arrow to the black box (inputs, functional requirements, constraints, boundaries and outputs) will be discussed.

4.2.1

Inputs

This section discusses the required inputs for the maintenance concept. The requirements for the inputs specify what should be provided to the concept. First, we assume that we know the

failure behavior of the system for which the maintenance program has to be designed. More specifically, the failure behavior should be described in terms of Maintenance Critical Items (MCIs) that describe the critical functional failure modes (FMs). This leads to requirement I.1 and I.2. This information should follow from a failure/system analysis, like the method described in Chapter 3. Second, we assume that we can have detailed quantitative information on the failure behavior. We should be able to define or assume (1) the characteristic of the failure rate (see Chapter 6 for a detailed discussion), (2) a probability density function f (t) of the time to failure (T ) and a degradation model for the Remaining Useful Life (RU L) for each functional failure mode. We need this detailed information to be able to select and specify a maintenance policy in an appropriate manner. Table 4.1 summarizes the set of requirements for the inputs. Table 4.1: Inputs ID I.1 I.2

I.3

4.2.2

Input / Rationale Maintenance Critical Items (MCI) have been defined The Functional Failure Mode(s) (FM) is/are known for each MCI For each MCI-FM, the following lifetime characteristics are know or can be assumed: (A) Characteristic failure behavior (constant/increasing/decreasing failure rate) (B) A probability density function f (t) of the time to failure (T ) (C) A degradation model for the Remaining Useful Life (RU L)

Value

Must (M)/ Wish (W)

Source / Reference

TRUE

Peeters (2016)

TRUE

Peeters (2016)

TRUE

Peeters (2016)

Functional Requirements

Table 4.2 presents the set of functional requirements for the maintenance concept. The set of functional requirements represents the boundaries for the design problem to achieve an acceptable solution. The functional requirements are to a large extent based on the URS-document and the maintenance objective. First, requirement FR.1 specifies a target for system availability (the percentage of the time the system can print on a yearly basis). Second, FR.2 and FR.3 specify a requirement for respectively the maintenance interval and duration for maintenance actions that can be performed by the operator of the customer. Third, FR.4 and FR.5 are comparable specifications to FR.2 and FR.3, but are only valid for a special maintenance action (replacement of the filter). For this specific component/action, a separate requirement was developed in the URS because this action is a common (bottleneck) maintenance action in metal AM systems. Fourth, FR.6 and FR.7 specify respectively a requirement for the maintenance interval and duration for maintenance actions that must be performed by a service engineer of the company. The last two functional requirements, FR.8 and FR.9, specify two minimization criteria for respectively the total costs and customer visits. These follow from the maintenance objective (see Section 4.1).

Table 4.2: Functional Requirements

>95 [%]

Must (M)/ Wist (W) M

Source / Reference URS-0041

>2 [weeks]

URS-0043

<4 [hours] <2 [hours] >13 [weeks] >26 [weeks] <1 [hours] <0.5 [hours] >52 [weeks] None <2 [days] <1 [days] Minimize Minimize

M W M W M W M W M W M M

Requirement / Rationale

Value

FR.1

System availability (printing) target Regular manual preventive maintenance interval (operator) Regular manual preventive maintenance duration (operator)

FR.2 FR.3 FR.4

Regular filter exchange interval (operator)

FR.5

Regular filter exchange duration (operator)

FR.6

Maintenance interval (service engineer)

FR.7

Maintenance duration (service engineer)

FR.8 FR.9

Total cost Visits of service engineer to customer

4.2.3

URS-0043 URS-0043 URS-0044 URS-0046 URS-0046 Section 4.1 Section 4.1

Constraints

This section discusses the constraints for the maintenance concept. Similar to functional requirements, constraints define the bounds on an acceptable solution for the design problem. Constraints differ from function requirements (Section 4.2.2) in that constraints are not specified in terms of numbers, but more qualitative. The first constraint, C.1, defines that regular service parts should be replaced by an operator. This includes that for a certain service action, we should first evaluate if an operator can perform the task, and only if this is not the case, a service engineer should perform the task. This constraint is closely linked to FR.9 in Table 4.2. The next constraint (C.2) adds to this that we assume that the operator has a vocational technical expertise or education. Table 4.3 summarizes these constraints. Table 4.3: Constraints ID C.1 C.2

4.2.4

Constraint / Rationale Regular spare part replacement by operator (Regular spare parts are e.g. sensors, drives, filters, wear parts, etc.) Operator expertise (operation and maintenance)

Value

Must (M)/ Wist (W)

Source / Reference

TRUE

URS-0045

Mechanic (MTS)

URS-0061

Boundaries and Interfaces

Table 4.4 shows the most important boundaries and interfaces of/to the maintenance concept. We remark that this list is not exhaustive; there may be more interfaces that are not listed

in Table 4.4 but we identify these as the most relevant based on literature (Blanchard and Fabrycky, 2006; Jones, 1987; Peeters, 2016). First, spare parts management is not included in the maintenance concept but is an important external interface (B.1). Next, we do not include resource management in our design of the maintenance concept, but is also a related aspect of maintenance (B.2). Third, we also do not consider logistic management issues in our model (B.3). Finally, we also do not analyze organizational aspects in our model (B.4). Table 4.4: Boundaries and Interfaces ID

Interface / Rationale

B.1

B.2

B.3

B.4

Decoupled from Spare Parts Mgmt. For example: spare part definition, spare part provisioning, etc Decoupled from Resource Mgmt. For example: planning of service engineers, maintenance task analysis, etc, Decoupled from Logistic Mgmt. For example: packaging, transportation, etc. Decoupled from Organization Mgmt. For example: maintenance facilities, level of repair, etc.

4.2.5

Value

Source / Reference

TRUE

Blanchard and Fabrycky (2006) Jones (1987)

TRUE

Blanchard and Fabrycky (2006) Jones (1987)

TRUE

Blanchard and Fabrycky (2006) Jones (1987)

TRUE

Blanchard and Fabrycky (2006) Jones (1987)

Outputs

The desired output of the maintenance concept is a maintenance program or plan. This maintenance program comprises a list of maintenance policies for the components that require maintenance. These components should be supplied to the maintenance concept in accordance with the requirements as specified in Section 4.2.1. Next, the maintenance concept should be able to specify the maintenance policy in terms of a (1) maintenance action, (2) executor and (3) a maintenance interval (if applicable). This requirement follows from the main research question (see Chapter 2). Table 4.5 summarizes this output specification. Table 4.5: Outputs ID

Output / Rationale

Value

Must (M)/ Wish (W)

Source / Reference

O.1

Maintenance program that consists of maintenance policies for each MCI-FM. A maintenance policy consists of: (A) Type (B) Action (C) (Optimal) interval

TRUE

Chapter 2

4.3

Discussion and Conclusion

In this chapter we have investigated the second research question: â&#x20AC;&#x153;What is the maintenance objective for MetalFAB1?â&#x20AC;? To answer this question, we have held interview sessions with key stakeholders within the company. At the time of writing, the company has just started to set up its service and support organization that will be responsible for maintenance of MetalFAB1. Although no detailed maintenance strategy has been defined yet, we have identified three key aspects that the company wants to achieve with its future maintenance activities. These are: (1) achieve a predetermined level of system availability; (2) minimize customer visits of service engineers by offering remote service and support and (3) minimize service costs. For this project, we define the maintenance objective by these three aspects. Subsequently, we translated the maintenance objective into a detailed requirement specification for the maintenance concept. Together with the User Requirement Specification for the MetalFAB1 system (internal document that specifies the system requirements for MetalFAB1) we defined a set of requirements for the (1) inputs, (2) functions, (3) constraints, (4) boundaries and interfaces and (5) outputs of the maintenance concept. This specification will be used as an input for the third research question (see Chapters 5 and 6).

Chapter 5

Maintenance Concept In this chapter the third research question is answered: Research Question 3: What is a suitable maintenance concept for MetalFAB1? The main goal of a maintenance concept is to provide decision support on maintenance policy selection and specification. As described in Section 4.2, we split the development of a maintenance concept into (1) a conceptual design and (2) a detailed design. The present chapter discusses the first part, the conceptual design. The detailed design will be discussed in Chapter 6. The rest of this chapter is organized as follows. In Section 5.1 we present and motivate our conceptual model for a maintenance concept to select maintenance policies for MetalFAB1. Subsequently, we discuss in Sections 5.2 and 5.3 the two stages of the conceptual design. The chapter ends with a conclusion in Section 5.4.

5.1

Conceptual Model

The requirements specification for the inputs, outputs, functional requirements, constraints and boundaries and interfaces (see Chapter 4) provide the starting point for the development of a maintenance concept. In addition, we use the relevant literature on maintenance concepts and ideas to build a conceptual model for the maintenance concept. Our resulting model is depicted in Figure 5.1. We decided to build a new customized model, because none of the maintenance concepts from literature fits perfectly to our set of requirements. The conceptual model was reviewed and tuned with the relevant stakeholders for verification (e.g. the CEO, middle management of Additive Industries and supervisor from Eindhoven University of Technology). The conceptual model consists of two stages, maintenance policy selection and maintenance policy specification, and three modules, module 1: selection, module 2: customer maintenance and module 3: OEM maintenance. Each module consists of one or more decision entities in which specific decisions are made.

5.2

Stage 1: Maintenance Policy Selection

We decouple the two main functions of the concept, which result in two consecutive stages: (1) maintenance policy selection and (2) maintenance policy specification. We decouple because

Maintenance Critical Items

Stage 1: Maintenance Policy Selection

Stage 2: Maintenance Policy Specification

Maintenance Program

Module 2: Customer Maintenance Customer Capabilities

Operator/Specialist (Customer)

Module 1: Selection Maintenance Critical Items (MCI)

Item Policy Selection

Clustering

Item Maintenance Interval

Executor Selection

Maintenance Program Customer

Cluster Cluster Interval

Module 3: OEM Maintenance Service Engineer (OEM)

Maintenance Type Maintenance Action

Single-Item Policy Specification

Multi-Item Policy Specification

Maintenance Program OEM

Executor Maintenance Interval

Figure 5.1: Conceptual Model the nature of the decisions differs. In maintenance policy selection, we may use a more qualitative method to decide on the right maintenance policy type, while in maintenance policy specification we use mathematical models to decide on the optimal maintenance interval. In this first stage, we define one module: module 1: selection.

5.2.1

Module 1: Selection

In we define two decision entities in which a specific decision is made: (1) decision entity item policy selection and (2) decision entity executor selection. In item policy selection, we select the most appropriate maintenance policy type for each MCI (Maintenance Critical Item) and determine the associated maintenance action. In executor selection, we assign the executor to the maintenance action. Concerning the first decision entity, we have seen from literature (see Section 2.1.3) that a selection step is a common first step to develop a good maintenance plan/program. Several maintenance concepts exist that provide structured approaches in this selection process (see, e.g., Peeters, 2016). Another reason to include a separate selection step in the beginning of the process, is that it has a consequence to which (mathematical) maintenance policy models are applicable later on. For instance, for an item that can best be maintained under a CBM policy we use a different model than for an item that is maintained under a TBM policy. Decision entity item policy selection For the first decision entity, we can use the information of the critical components as specified in Table 4.1. The categories of maintenance policy types that should be considered are: (1) corrective maintenance policies, (2) preventive maintenance policies and (3) aggressive maintenance policies. These maintenance policy categories follow from a detailed literature review (see Peeters, 2016). In order to select the best maintenance policy, a maintenance policy selection concept from the literature can be used (e.g. Reliability Centered Maintenance or CIBOCOF, see, Peeters, 2016). In the detailed design of the module, we specify which specific maintenance policy types (e.g. time-based maintenance, condition-based maintenance) are considered. Next, we define the associated maintenance action for the maintenance policy. We define the maintenance action at this

point, since we require this information in the next decision entity. In defining these maintenance actions, we have to take into account constraints C.1 and C.2 from Table 4.3. Decision entity executor selection In the second decision entity, we compare the required capabilities of the maintenance action with the capabilities of the customer to select the executor. We recognize that the decision on the executor should take into account the customer capabilities (e.g. knowledge and skill level of the customer). In our model, we specifically put this decision early in the process because we use this information in the next stage (maintenance policy specification).

5.3

Stage 2: Maintenance Policy Specification

The second stage in our model is maintenance policy specification, in which we determine the optimal maintenance interval for each policy. We define two decoupled modules that both are related to maintenance policy specification: (1) module 2: customer maintenance and (2) module 3: OEM maintenance. We define customer maintenance as maintenance activities that can be executed by the customer (operator or specialist trained by the OEM) and OEM maintenance as maintenance activities that must be executed by the OEM or a third party. We explicitly state a third party, because the OEM may decide to outsource maintenance but then the OEM remains responsible. We decouple between module 2 and 3 because of three reasons: (1) remote support/maintenance, (2) difference in maintenance interval and (3) difference in applicable models. Firstly, from the interviews with the stakeholders (refer to Section 4.1) we identify that the company wants to minimize the service visits to the customer by offering remote service and support. This implies that the customer should execute (some) maintenance tasks him/herself (with or without remote assistance of the company). In our model, we integrate this by making a distinction between customer maintenance and OEM maintenance. Secondly, the functional requirements (see Table 4.2) for both types of maintenance are quite different. For maintenance actions executed by the customer the maintenance interval should be larger than 2 weeks and for maintenance actions executed by the OEM the interval should be larger than 1 year. Thirdly, we recognize that we should use different mathematical models for both types. For OEM maintenance, a multi-component optimization model is beneficial because there is a potential to save money on (high) setup cost/time. For this type of maintenance, it makes sense to synchronize maintenance actions of multiple components into a single preventive maintenance interval. In contrast, for customer maintenance it is more beneficial to focus on the individual component and develop an optimized policy on component level. This is because we expect that the setup cost/time are less important than for OEM maintenance-items.

5.3.1

Module 2: Customer Maintenance

In module 2, we specify the maintenance interval for items maintained by the customer. We distinguish between two decoupled decision entities: (1) single-item policy specification and (2) clustering. We recognize that, besides specifying an optimal maintenance interval, grouping of maintenance can have additional benefits in terms of cost savings and improved coordination (Dekker et al., 1997). In the first decision entity, we determine the item maintenance interval (if applicable) of each item within this category. In the second decision entity, we consider

clustering of components into groups that have the same interval (cluster interval). We decouple these two decision entities, because they may use different models, i.e. single item maintenance policy models versus clustering algorithms. Moreover, to be able to consider clustering of different item-level maintenance policies into a group, we have to have determined the required item maintenance interval. So both tasks have to be performed consecutively. The output of this module is a detailed maintenance policy that includes a (A) maintenance policy type, (B) maintenance action and (C) maintenance policy interval. In addition, those maintenance policies may be clustered into groups. The whole set of maintenance policies and actions compromises the maintenance program customer. Decision entity single-item policy specification Concerning the first decision entity, we need to use a single-item maintenance policy model to determine an optimal maintenance interval for each item. Obviously, only for items that have a preventive maintenance policy the maintenance interval can be determined. Which specific maintenance policy model is applicable, depends on the maintenance policy type. However, there are models that focus on availability maximization or on cost minimization. As defined in the maintenance objective (see Section 4.1), system availability is more important for the company than cost. So, we should use models that focus on availability maximization. An overview of maintenance policy models is discussed in Peeters (2016). In the detailed design of module 2, we specify which specific maintenance policy models to use to determine the optimized interval. Decision entity clustering In the second decision entity in module 2, we consider clustering of maintenance actions into clusters with each a common cluster interval. Grouping of maintenance actions can have additional benefits in terms of cost savings and improved coordination (Dekker et al., 1997). There are several clustering algorithms available in literature that seek for an optimal grouping strategy for maintenance policies, for example the dynamic programming algorithm of van Dijkhuizen and van Harten (1997). While determining the optimal groups, we also have to take into account functional requirements FR.2 - 5 (see Table 4.2). These requirements constrain the cluster interval and total duration of the clustered actions of a certain cluster.

5.3.2

Module 3: OEM Maintenance

The last module in our conceptual model is the module OEM maintenance. Within this module, we have only one decision entity (multi-item policy specification) in which we specify a multi-component maintenance policy for the items that have to be maintained by the OEM. As stated before, we differentiate from the approach in module 2. In this decision entity, we feed the items that should be maintained by the OEM to a multi-component optimization model to determine a single (optimal) maintenance interval (e.g. the model of Zhu (2015) or van Horenbeek (2013)). Further decoupling is not applicable here. The final outcome of the step is a maintenance program for the OEM that comprises a list of maintenance actions with an interval. Decision entity multi-item policy specification In this decision entity, we have to take into account a several requirements similar as for module 2. First, we need to select (or develop) a multi-component maintenance policy model that focuses on availability maximization (refer to the maintenance objective in Section 4.1). Second, the multi-component model

should be able to handle a combination of different types of maintenance policy types (e.g. some components may be maintained under a failure based policy, while others follow a condition based maintenance policy). From the detailed design of module 1 follows which specific maintenance policy types should be taken into account. Third, the additional functional requirements (FR.6 and FR.7 in Table 4.2) should be taken into account in the determination of the optimized maintenance interval. An interesting multi-component maintenance policy model is the model developed by Zhu (2015). He developed an opportunistic maintenance model for multi-component systems with a mixture of different maintenance policies that can be applicable for our situation. In the detailed design of module 3, the multi-component maintenance model is specified to determine the optimized maintenance interval.

5.4

Discussion and Conclusion

In the present chapter we investigate the second research question: â&#x20AC;&#x153;What is a suitable maintenance concept for MetalFAB1?â&#x20AC;? To answer this question, we develop a conceptual design of the maintenance concept for the selection and specification of maintenance policies and shows how a maintenance program/plan can be developed based on a set of maintenance critical items/ failure modes. Our design is based on the specification of the inputs, output, functional requirements, constraints and external interfaces and maintenance objective of the company as discussed in Chapter 4. In our view, the developed solution is a good solution, since it satisfies to the aforementioned requirements. To the best of our knowledge, an explicit decoupling between customer maintained components and OEM maintained components in maintenance policy selection and specification has not yet been reported in literature. The decoupling is related to the Level of Repair Analysis (LORA) in Logistic Support Analysis (see e.g. Blanchard and Fabrycky, 2006), in which the location or level of a repair action is considered. In LORA, there are three levels on which maintenance can take place: (1) organization level, e.g. a repair action in the field at the customer site, (2) intermediate level, e.g. a repair or diagnostic action at a specialized repair shop or (3) depot level, e.g. a repair action at a highly specialized shop or OEM facility. Our model is related to LORA in the sense that it recognizes that there are different locations where maintenance can take place, but it specifically links this to the maintenance policy and associated interval determination. Our conceptual model offers new insights in the following way. First, it shows that multicomponent maintenance optimization models may specifically be applicable for components that are maintained under direct responsibility of the OEM itself (either performed by the OEM or a third party). Second, it shows a way how an OEM can opt for remote service and support by explicitly taking into account the option to devote certain maintenance actions to the customer (with or without support of the OEM). This contributes to the minimization of expensive and time consuming customer visits of service engineers to customer sites. This will also contribute to a shorter reaction time to customer issues. The conceptual model may also be relevant for other OEM companies of high tech capital goods.

Chapter 6

Detailed Design Module 1 This chapter extends the conceptual model from Chapter 6 into a detailed design. We develop a detailed design for the first module, module 1: selection. The detailed design of modules 2 and 3 is out of scope of this paper. Besides the required time to develop the detailed design, we would also have to collect additional life time information which may be time consuming. Subsequently, apply the detailed design of module 1: selection to MetalFAB1. This will provide an answer the fourth research question: Research Question 4: What are the most appropriate maintenance policies for the maintenance critical items of MetalFAB1? This chapter is organized as follows. Section 6.1 presents the proposed detailed design for module 1. Section 6.2 and 6.3 discuss respectively the implementation of the detailed design in Microsoft Excel and the results of the application to the MetalFAB1 in a case study. This chapter ends with a conclusion in Section 6.4.

6.1

Design

In module 1, we decide on two aspects of the maintenance policy: (1) select the maintenance policy type and (2) determine the executor of the maintenance action. In our conceptual model (Figure 5.1), we defined two sequential decision entities in module 1: item policy selection and executor selection. Taking the global description of the module (see Section 5.2.1) as the starting point, we develop a detailed design of this module. Our final model for each of these decision entities is depicted in Figure 6.1 (item policy selection) and Figure 6.2 (executor selection). In several review sessions with the Service and Support Manager, the Technology Manager and first supervisor of Eindhoven University of Technology, we checked and improved the quality of our model. Again, we conceptualize the detailed design of the module as a black box that should convert an input to an output, given a number of functional requirements, constraints and external interfaces. In the next sections, Section 6.1.1 - 6.1.3, we describe our model in detail in terms of: the (1) inputs, (2) internal process steps and (3) outputs, respectively. The relation to external interfaces is discussed when appropriate. Since item policy selection and executor selection are sequential decision entities, the outputs of item policy selection are the inputs of executor selection.

External interfaces

FTA-FMECA FMECA Field issue reporting

MCI [Component] [Failure mode] [Failure effect] [Failure cause] [Failure detection] [RPN]

Reliability Predictions

STEP 1 Retrieve MCI

Start

Test and Support Equipment Analysis

Personnel Training

Maintenance Task Analysis

Spare Parts Management

STEP 2 Determine failure rate characteristic

STEP 3 Conduct RCM analysis

STEP 4 Define maintenance action

STEP 5 Assign maintenance action to MCI

MCI [Component] [Failure mode] [Failure effect] [Failure cause] [Failure detection] [RPN] MAINTENANCE POLICY [Policy type] End

MAINTENANCE ACTION [Task(s)] [Initial Service Level] [Spare part(s)] [Tool(s)]

Module 1: Selection (Item Policy Selection)

Inputs

Outputs Legend Process Process

Subprocess

Data / information attribute

Subprocess

DATA ATTRIBUTE NAME [Element(s)] :

Figure 6.1: Detailed design module 1 - decision entity item policy selection

External interfaces Outsourcing

MCI [Component] [Failure mode] [Failure effect] [Failure cause] [Failure detection] [RPN] MAINTENANCE POLICY [Policy type] MAINTENANCE ACTION [Task(s)] [Initial Service Level] [Spare part(s)] [Tool(s)]

Start

Test and Support Equipment Analysis

Personnel Training

Maintenance Task Analysis

Spare Parts Management

STEP 1 Retrieve output from Item Policy Selection

STEP 2 Determine customer capabilities

STEP 3 Select executor

MCI [Component] [Failure mode] [Failure effect] [Failure cause] [Failure detection] [RPN] STEP 4 Assign executor to maintenance action

End

Module 1: Selection (Executor Selection)

MAINTENANCE POLICY [Policy type] MAINTENANCE ACTION [Task(s)] [Initial Service Level] [Spare part(s)] [Tool(s)] [Executor]

Outputs

Inputs

Legend Process Process

Subprocess

Data / information attribute

Subprocess

DATA ATTRIBUTE NAME [Element(s)] :

Figure 6.2: Detailed design module 1 - decision entity executor selection

6.1.1

Inputs

First, we describe the required inputs to module 1. As discussed in Section 5.2.1, we may use the inputs as specified in Table 4.1. For module 1, we require each MCI (Maintenance Critical Item) to be defined in terms of: the (1) component, (2) failure mode, (3) failure effect, (4) failure cause, (5) failure detection method and (6) Risk Priority Number (RPN) with a (a) severity index, (b) occurrence index and (c) detectability index. We remark that a certain component can have multiple failure modes, which implies that a component can be present in multiple MCIs. In fact, an MCI is in essence the same as a failure mode. The notion of

MCIs allows us to distinguish between failure modes that are considered for development of a maintenance program and those that are not considered. With respect to the inputs, we argue that we require input (1) to (5) because those provide a detailed description of the failure mode. Requirement (6) adds a qualitative risk measure to each failure mode that provides an idea of its criticallity. Furthermore, we use the three components of the RPN, i.e. the severity index, occurrence index and detectability index, later on in the decision entity item policy selection explicitly (see Section 6.1.2). These inputs should follow from a failure analysis (e.g. FTA-FMECA, FMECA or field issue reporting). In this project, we only consider the case that these inputs follow from an FTA-FMECA (see Chapter 3). We recognize that these failure modes may also follow from other sources in the future.

6.1.2

Internal process steps

In this section, we describe the main process steps of the module to convert the inputs (Section 6.1.1) to the outputs (Section 6.1.3). We discuss the internal process steps of the two decision entities in module 1 consecutively; first item policy selection, and then executor selection. Item Policy Selection In the first decision entity, item policy selection, we distinguish between five main steps to select the maintenance policy type (see also Figure 6.1): 1. Retrieve MCI 2. Determine the failure rate characteristic 3. Conduct a Reliability Centered Maintenance (RCM) analysis 4. Define maintenance action 5. Assign maintenance action to MCI Step 1 (Retrieve MCI) The first step in the process is to retrieve the MCI as described in the former section. These items should follow from a failure analysis (see Section 6.1.1) Step 2 (Determine failure rate characteristic) The second step is to gather additional information on the reliability aspect of a failure mode. Ideally, we would have detailed quantitative information on each item, for example statistical information on the time to a failure, a mean time to failure, failure rate, etc. However, since the system in our project is completely new, such information is not yet available. Furthermore, to gather such information can be quite expensive and time consuming and, at this stage (maintenance policy selection, see Figure 5.1), we do not yet know if we really need this detailed information. The latter is due to that such information is only really needed in case a preventive maintenance policy has to be specified in stage 2 (maintenance policy specification, see Figure 5.1). Recall from Section 5.2.1, that we consider three major categories of maintenance policy types: (1) corrective, (2) preventive and (3) aggressive. To save time and money, we aim to make a decision on the maintenance policy type with as little information as possible. The failure rate can help us here. The failure rate, or hazard rate, Îť(t) is defined as the conditional probability at time t that a component will fail within

the next small time interval t + , assuming that is has survived until t. Mathematically it can be defined as follows, in which T denotes the time to a failure (see, e.g., Pintelon et al., 1997): P (T â&#x2030;¤ t + | T â&#x2030;Ľ t) Îť(t) = lim Îľâ&#x2020;&#x2019;0 If dÎť(t) dt < 0, Îť(t) is a decreasing function and the component thus has a decreasing failure rate (DFR). This means that it becomes more reliable over time and does not need maintenance. Other possibilities are: an increasing failure rate (IFR) dÎť(t) dt > 0 (component degrades over time and may be interesting for preventive maintenance) or constant failure rate (CFR) dÎť(t) = 0 (random failures and not interesting for preventive maintenance). As such, the dt failure rate is a quantitative measure of a failure that follows from lifetime tests or field data. However, the failure rate characteristic provides information of typical failure rate behavior and can be guessed with the help of technical experts (e.g. design engineers). From literature (see, e.g., Bertsche, 2010), we know several typical failure rate behavior patterns (see Figure 6.3). For each failure mode from step 1, we assess which pattern is expected with the help of technical experts. We recognize the external interface with reliability testing/reliability prediction in this step for the determination of the failure rate from testing/field data. We use the failure rate characteristic in the third step.

Figure 6.3: Failure rate characteristic behavior (Bertsche, 2010)

Step 3 (Conduct RCM analysis) The third step is to conduct a Reliability Centered Maintenance (RCM) analysis. RCM is a commonly used method to decide on maintenance policies in development of a preventive maintenance plan (see also 2.1.3). We prefer RCM over other methods from literature (e.g. BCM of CIBOCOF) because it is (1) a proven method, (2) a structured and relatively simple approach and (3) considers all maintenance policy types that we require (i.e. corrective, preventive and aggressive). First, literature reveals several successful stories of RCM, see e.g. Fore and Mudavanhu (2011) or Deshpande and Modak (2001). Second, RCM provides well structured and (relatively) easy to understand decision trees to select the type of maintenance for a failure mode. This in contrast with the very extensive diagrams in CIBOCOF (see Waeyenbergh, 2005) and vague decision diagrams in BCM (see Kelly, 1997). Third, in Section 5.2.1 we stated that corrective, preventive and aggressive maintenance policies should be considered for each item. Especially RCM seems a suitable method for this, since each item is considered explicitly and only single item maintenance policies are considered. In CIBOCOF and BCM, also multi component maintenance policies are considered (e.g. group maintenance). In our model, this may cause difficulties since we propose to explicitly decouple this from module 1 (see Figure 5.1). On the baseline, we use the standard RCM method because of substantial evidence that it works. We only propose one addition to RCM, which will be discussed later on. We use RCM in a qualitative way, i.e. we rely on expert knowledge rather than lifetime data analysis

since this data is not available in many cases. Ideally, one underpins decisions with data, but unfortunately this is not possible in our project. Figure 6.4 shows the main RCM decision flowchart (refer to Appendix D for more details). Start

1. Is the occurence of the failure mode evident for an operator under normal circumstance? HIDDEN FUNCTIONS

EVIDENT FUNCTIONS

YES 2. Does the failure mode cause a loss of function or secondary damage that could direct affect safety? YES

3. Does the failure have a direct adverse effect on operation capability?

OPERATIONAL CONSEQUENCES (ECONOMIC)

DECISION RULE 4

YES

4. Is an on-condition task to detect the potential failure both applicable and effective? CBM

YES

CBM

YES

TBM/UBM (repair)

DECISION RULE 3 DECISION RULE 4

CBM

YES

TBM/UBM (replacement)

YES

TBM/UBM (repair)

1a. Consider preventive maintenance? DECISION RULE 4

YES

CBM

TBM/UBM (replacement)

YES

TBM/UBM (repair)

15. Is a scheduled repair task to reduce the failure rate both applicable and effective?

13. Is a scheduled replacement task to avoid or reduce the failure rate both applicable and effective?

FBM

14. Is an on-condition task to detect the potential failure both applicable and effective?

12. Is a scheduled repair task to reduce the failure rate both applicable and effective?

10. Is a scheduled replacement task to avoid or reduce the failure rate both applicable and effective? DOM

HIDDEN CONSEQUENCES

3a. Consider preventive maintenance?

11. Is an on-condition task to detect the potential failure both applicable and effective?

9. Is a scheduled repair task to reduce the failure rate both applicable and effective?

6. Is a scheduled replacement task to avoid or reduce the failure rate both applicable and effective? TBM/UBM (replacement)

YES

NONOPERATIONAL CONSEQUENCES (NONECONOMIC)

8. Is an on-condition task to detect the potential failure both applicable and effective?

5. Is a scheduled repair task to reduce the failure rate both applicable and effective? TBM/UBM (repair)

YES

3a. Consider preventive maintenance?

2a. Consider preventive maintenance? DECISION RULE 4

DECISION RULE 1

DECISION RULE 2

SAFETY CONSEQUENCES

FBM

YES

16. Is a scheduled replacement task to avoid or reduce the failure rate both applicable and effective? TBM/UBM (replacement)

YES

Failure finding task

Legend A

Automated decision rule based on RPN of FMECA result.

Manual decision based on additional decision flowchart. See Appendix D.

DOM Failure finding task

Design-out maintenance (DOM) or design change recommended Failure finding task or scheduled test recommended

CBM TBM/UBM (repair) TBM/UBM (replacement) FBM

Condition based maintenance (CBM) policy recommended Time- or Usage based maintenance (TBM/UBM) with repair policy recommended Time- or Usage based maintenance (TBM/UBM) with replacement policy recommended Failure based maintenance policy recommended

Figure 6.4: Main RCM decision flowchart, adapted from Nowlan and Heap (1978) In order to speed up the RCM procedure, we propose several decision rules based on the RPN (determined in step 1 (Retrieve MCI)) and the failure rate characteristic (determined in step 2 (Determine failure rate characteristic)). Furthermore, we propose to add one additional question â&#x20AC;&#x153;Consider preventive maintenance?â&#x20AC;? to be able to skip the the consideration of preventive maintenance policies if the failure mode has a DF R or CF R. The latter is proposed, since for those items preventive maintenance will never be optimal (see, e.g., Arts, 2014). Obviously, we recognize these rules imply a simplification, but we argue that the time saved by not considering these questions one-by-one manually is substantial. Decision rule 1 proposes to answer RCM question 1 based on the score on detectablility. Referring to Figure 3.1, we argue that a D score of 1 to 7 indicates that the failure mode is evident to detect by an operator. Decision rule 2 proposes to answer RCM question 2 based on the score on severity. Referring to Figure 3.1, we argue that a S score of 10 indicates that the failure mode affects safety. Decision rule 3 proposes to answer RCM question 3 based on the score on severity. Referring to Figure 3.1, we argue that a S score of 5 to 9 indicate that the failure mode has a direct effect on operational capability. Decision rule 4 proposes to answer (the additional) RCM question 1a/2a/3a based on the classification of the failure

rate characteristic (refer to step 2). We argue that only for failure modes that are classified as IFR, the answer should be “YES”. The remaining questions should be answered manually (if applicable) with the help of the additional RCM decision trees (see Figure D.2 to D.4 in Appendix D). Decision rule 1 RCM question 1: Is the occurrence of the failure mode evident for an operator under normal circumstances? if Detectability index (D) < 8 then YES else NO end if

Decision rule 2 RCM question 2: Does the failure mode cause a loss of function or secondary damage that could affect safety? if Severity index (S) = 10 then YES else NO end if

Decision rule 3 RCM question 3: Does the failure have a direct adverse effect on operational capability? if 5 ≤ Severity index (S) < 10 then YES else NO end if

Decision rule 4 RCM question 1a/2a/3a: Consider preventive maintenance? if Failure Rate Characteristic = IFR then YES else NO end if Step 4 (Define maintenance action) The fourth step is to define the maintenance action associated with the maintenance policy (e.g. what action should be performed in case a maintenance policy is triggered?). We expect that we may have the same maintenance action for multiple MCIs/failure modes. For instance, consider the example of the component laser that may have several failure modes. In step 3, we determine for each failure mode, what maintenance policy type should be used. For example, we may have determined that some failure modes should follow an FBM policy and some follow a CBM policy. One can imagine

that the associated maintenance action may be the same for several failure modes, e.g. replace the laser on failure. In this project, we define the maintenance action pragmatically based on expert knowledge. We could make a detailed study on each maintenance action with multiple analyses, for example with maintenance task analysis or personnel training as proposed in the LSA(Logistic Support Analysis) framework (see, e.g., Blanchard and Fabrycky, 2006). However, incorporating these analyses in our model would be too extensive for this project. So we recognize these analyses as external interfaces to our model (e.g. maintenance task analysis, test and support equipment analysis, personnel training and spare parts management) and we will make a simplified decision on the maintenance action. The simplified maintenance action is defined in the data attribute maintenance action (see Figure 6.1) and includes the following elements: (1) maintenance task(s), (2) initial service level, (3) required spare part(s) and (4) required tool(s). The elements maintenance task, required spare part(s) and required tool(s) are inspired by the external interfaces and we consider these as the most important aspects of a maintenance action in the current context. Element initial service level follows from the company to determine what type of service is required (see Table 6.1). These service levels where proposed in another student project (see, van Laarhoven, 2016). We will not go into the details of each level here. For each maintenance action we determine the minimum or initial service level. Table 6.1: Service level of maintenance actions Service level Description Appliciable to

1 Customer self-support Actions that can be performed by customer independently

2 Remote support Actions that can be performed by customer with remote assistance of OEM

3 On-site support Actions that require a visit of an OEM service engineer

Step 5 (Assign maintenance action to MCI) In the fifth and final step, we assign the maintenance action to the failure mode. The final output of decision entity item policy selection is the maintenance policy type and an associated maintenance action. This is also depicted is Figure 6.1. As previously stated, these outputs are the inputs for the next decision entity executor selection. Executor Selection In the second decision entity, executor selection, we distinguish between the following main process steps to select the executor of the maintenance action (see also Figure 6.2): 1. Retrieve output from item policy selection 2. Determine customer capabilities 3. Select executor 4. Assign executor to maintenance action

Step 1 (Retrieve output from decision entity item policy selection) First, the outputs of the first decision entity (item policy selection) are retrieved as input for this decision entity. These outputs include the attributes: (1) MCI, (2) maintenance policy and (3) maintenance action. Refer to Section 6.1.2 for the details of each attribute. Step 2 (Determine customer capabilities) Second, we determine whether the capabilities of the customer meet the requirements to perform a maintenance action. We take into account: the (1) service level to restore the failure, (2) availability of spare parts and (3) availability of tooling and (4) whether we want outsourcing or not. The requirements for these elements were determined in step 4 of decision entity item policy selection, exept for element outsourcing. Again, we simplify the decision making, but we recognize maintenance task analysis, test and support equipment analysis, personnel training and spare parts management as external interfaces. In addition, we identify outsourcing as an external interface. Smit (2010) argues that the decision of a company whether to outsource maintenance activities to external parties is more often seen as a strategic decision. In this context, this consideration of whether we prefer outsourcing or doing it in-house, one should take into account the following aspects: (a) intellectual property of a maintenance action, (b) the availability of specialist knowledge within or outside the company, (c) trade-off of resulting reaction speed and (d) trade-off of capacity flexibility achieved by outsourcing maintenance. In our model, we take these aspects into account pragmatically based on expert knowledge (i.e. input from the supply chain manager and senior management), leading to a simple answer as “Yes” or “No” on whether we want outsourcing or not. Step 3 (Select executor) Third, we make the final decision on the executor. This decision is based on a trade-off between the requirements of a certain maintenance action (step 4 of decision entity item policy selection) and the customer capabilities (step 2 of decision entity executor selection). This leads to a decision on the executor: either the OEM or the customer. Step 4 (Assign executor to maintenance action) Fourth, we assign the executor to the maintenance action. In this step, we add the executor to the data attribute maintenance action (see Figure 6.2).

6.1.3

Outputs

After executor selection, we have the final outputs of module 1: Selection. These outputs can be summarized as follows. For each MCI supplied to the module, we have determined the Maintenance Policy, that consists of a: • Maintenance Policy Type • Maintenance Action, that consists of a: – Maintenance Task(s) – Initial Service Level – Spare Part(s) – Tool(s) – Executor

These outputs are in line with the output requirement specification O.1(A) and O.1(B) as described in Table 4.5. Output requirement O.1(C) is not yet met, since the maintenance policy interval will be determined in stage 2: maintenance policy specification of the conceptual model (see Figure 5.1) and is therefore not considered in the detailed design of module 1. These outputs are also in line with the requirements that follow from our conceptual model (refer to Section 5.1 and 5.3. This includes that the maintenance policy type and the executor of maintenance policy should be decided in module 1.

6.2

Implementation

In the present section we discuss the implementation of the detailed design as described in Section 6.1. The implementation includes the design of a Microsoft Excel sheet that helps to perform the analyses. As one can imagine, the application of the detailed design results in the creation of a lot of information. This information should be stored in an organized way to be effective. In a future application, this can also be a more sophisticated database environment. We restrict the implementation to the decision entity item policy selection; we do not implement the decision entity executor selection. The latter is based on the fact that we cannot determine the exact capabilities of the customer for our case study (see Section 6.3) due to a lack of information. In the current situation, it is hard to determine the exact capabilities of the customer since the first MetalFAB1 system has just been installed at a customer site. So, as a result, we could not test an implemented model and the implementation phase is therefore skipped. A screenshot of the Excel implementation is included in Appendix E and discussed in the case study in Section 6.3.

6.3

Case Study: Application to MetalFAB1

After having implemented the detailed design in a Microsoft Excel environment, we can apply it to a test case. In this case study we apply the implemented detailed design of the decision entity item policy selection (Figure 6.1). The subsequent part of this section is organized as follows. Section 6.3.1 describes the experimental set-up and sample for this case study. Section 6.3.2 discusses the intermediary results after the application of step 1-3 of the detailed design. Subsequently, Section 6.3.3 discusses the end results after the application of step 4-5.

6.3.1

Approach

We use the results of the former case study (application of the recursive FTA-FMECA method to MetalFAB1, see Section 3.3) as the input for the case study. We distinguish between two lists of failure modes: List A Failure modes up to failure mechanism level of function powder layer deposit. See Appendix B. This list compromises 55 failure modes in total, related to the function powder layer deposit. List B Failure modes up to failure mechanism level of function exposure. See Appendix B. This list compromises 77 failure modes in total, related to the function exposure.

We distinguish between these two lists, because each list is related to a specific function of the MetalFAB1. In addition, we involved two different engineers during the failure analysis of each function (Rob van Haendel for list A and Erwin Wijn for list B). This allows us to analyze the influence of personal opinions on decisions in the maintenance concept and the difference between functions of MetalFAB1. We use the procedure as summarized in Table 6.2 to test the design of decision entity item policy selection. Table 6.2: Procedure Case Study

III IV

6.3.2

Description Application of process step 1-3 of Figure 6.1 to List A and List B by researcher. Application of process step 1-3 of Figure 6.1 to List A and List B by responsible design engineer. Compare intermediate results of I and II to investigate the influence of assessor. Application of step 4-5 of Figure 6.1. Evaluate end results to validate the decision entity item policy selection.

Assessor

Outputs

Johnny Peeters

Maint. Policy Types List A Maint. Policy Types List B

Rob van Haendel (List A) Erwin Wijn (List B)

Maint. Policy Types List A Maint. Policy Types List B

Johnny Peeters

Selection to use either the results of I or II in step IV.

Johnny Peeters

Maint. Actions List A+B

Johnny Peeters

Intermediate Results

In this section, we discuss the results after the two independent applications of step 1-3 of list A and B to investigate whether both judgments match. A match is defined as the event that the result of I is exactly the same as II (see 6.3.1). The comparison for each function is depicted in Table 6.3 (exposure) and 6.4 (powder layer deposit). We compare the outcomes of step 2 (Determine failure rate characteristic) and step 3 (Conduct RCM analysis). First, we observe that both judgments after step 3 match well; respectively 72% (55+17) and 80% (67+13) of the failure modes yield the same result after step 3 (matching maintenance policy types). Moreover, there are no large differences between the two functions. Obviously, we only have two different people in our sample, so we cannot underpin our preliminary conclusion that the influence of the analyst is low with statistical evidence. Second, if we look at the results of step 2 (classification of failure rate), we observe that respectively 74% (55+19) and 82% (67+15) of the judgments match. Although, the numbers of the first and second observation are quite similar, we can see that there are also a lot of match/no match (19% and 15%) and no match/match (17% and 13%) cases. This means that a match at step 2, does not necessarily mean a match at step 3, and vice versa. To conclude this

discussion, we argue that the result of II (the results of a session with the design engineer) are more valuable, since the engineers can rely on more solid technical knowledge that may lead to better conclusions. Therefore, these results will be used in the next stage (see IV and V in Section 6.3.1). However, we remark that these results are only based on the opinion of the design engineer. The quality of the assessment is therefore relatively low and can be improved with involving more people in the assessment (out of scope of this project). Table 6.3: Intermediate results function exposure

Step 3 RCM analysis

Matching Not matching

Step 2 Failure rate characteristic Matching Not matching 42 (55%) 13 (17%) 15 (19%) 7 (9%) 57 (74%) 20 (26%)

55 (71%) 22 (29%) 77 (100%)

Table 6.4: Intermediate results function powder layer deposit

Step 3 RCM analysis

6.3.3

Matching Not matching

Step 2 Failure rate characteristic Matching Not matching 37 (67%) 7 (13%) 8 (15%) 3 (5%) 45 (82%) 10 (26%)

44 (80%) 11 (20%) 55 (100%)

End Results

In this section, we discuss the final results after the application of step 4 and 5 of the detailed design of item policy selection. As input, we use the results of step 1-3 from the session with the design engineer (see II in Section 6.3.1). This results in two final results: â&#x20AC;˘ An overview of the maintenance policy and action for each MCI/failure mode â&#x20AC;˘ An overview of all maintenance actions The complete list of maintenance policies with associated maintenance action for each MCI in this case study is included in Appendix E. The list of maintenance actions for the MCIs in this case study included in Appendix E. We can summarize the results graphically in a maintenance policy mix (see Figure 6.5) and a maintenance action mix (see Figure 6.6). If we evaluate the maintenance policy mix, we observe the following. First, from the considered maintenance policy types in Figure 6.4, DOM (Design Out Maintenance) is not present in the final maintenance policy mix. From this we can conclude that, in this sample, no severe failure modes related to human hazards are present for which no preventive maintenance can be defined. We remark that this classification is only possible if the failure mode is rated with a severity index of 10 (see Figure 6.4 and Decision rule 2). Thus if a certain failure mode is not rated with a 10, it can never fall in this category. Second, we observe that there

are in general many FBM (Failure Based Maintenance) policies selected for both functions, 52 for exposure and 36 for powder layer deposit. This observation is in line with what we would expect, since we have seen examples of other high tech systems in which a relatively large number of items are maintained under FBM (see, e.g., Zhu, 2015). Third, we observe that only a few UBM/TBM policies are selected (for both repair as well as replacement, and yields for both functions). We cannot explain this observation at first glance, but it is related to our third observation. Our third observation is that there are relatively many CBM (Condition Based Maintenance) policies selected; approximately 20% over the two functions 18+8 ( 77+55 · 100% ≈ 20%). From this observation, we may conclude that there are plenty of possibilities for predictive maintenance (CBM) available in the MetalFAB1. This may also explain the little presence of TBM/UBM policies. Finally, for the function exposure, we observe that 13 FF (Failure Finding) policies have been selected. In the FF policy, a scheduled test of a hidden function is performed to find any failure. Eventually, there are quite many failure modes that have hidden functions and that are difficult to prevent. A Failure Finding task is only recommended for items for which it is not evident for an operator that it has failed (may have hidden function(s)) and no preventive maintenance task can be defined (see RCM diagram in Figure 6.4). In our model, we classify a failure mode as “not evident for an operator” if it has a detectability index of 8 or higher (see Decision rule 1). Next, we check the failure rate characteristic whether we should consider preventive maintenance (Decision rule 4). A detailed analysis of the results (see Appendix E) reveals that 8 of the 13 cases are classified as FF due to Decision rule 4 (i.e. no IF R) and the remaining 5 based on the fact that no preventive maintenance policy could be defined (i.e. after consideration of each type). The fact that there is a spread in how the classification of the FF policy is effected, may give us confidence that our proposed model is good. We may have doubted if, for instance, all 13 FF policies where classified due to Decision rule 4.

Figure 6.5: Maintenance Policy Mix Next, we summarize the maintenance action list visually in a maintenance action mix (Figure 6.6). This diagram shows the distribution of the maintenance actions according to type and initial service level. We refer to Table 6.1 for a description of each service level. If we look at the maintenance action mix, we observe the following. First, we observe a difference in the total number of maintenance policies (77 + 55 = 132) versus the total number of maintenance actions (25 + 25 + 9 = 59). The reason is that we were able to re-use maintenance actions over the maintenance policies to reduce the actions by 59−132 132 · 100% ≈ −55% in this sample. This validates the benefit of a separate “define maintenance action step” (step 4), decoupled from the maintenance policy (step 3) in our model. If we would have combined this, we had to no opportunity for re-use (i.e. determine 132 actions). Second, if we look at the differences

across the initial service levels, we observe that CBM policies are frequently associated with a (initial) service level 3 maintenance action. Furthermore, in this sample, we have much more service level 2 and 3 actions than level 1 actions. This can be explained by the fact that the MetalFAB1 is a high tech system and maintenance actions may be difficult for an operator to solve independently. However, we also observe that there are also a lot of level 2 actions (actually the same amount as level 3). This means that there are a plenty of opportunities to effectuate the company’s vision to opt for remote service and support. We can underpin the latter by the fraction of level 1 and 2 maintenance actions compared to the 25+11 total: 25+25+11 · 100% ≈ 59%.

Figure 6.6: Maintenance Action Mix

6.4

Discussion and Conclusion

In the present chapter we have extended the conceptual model of Chapter 5 into a detailed design of module 1: selection. In this module, we define two decision entities: (1) item policy selection, which is responsible for the selection of the maintenance policy type and determination of the maintenance action and (2) executor selection, in which the executor of the maintenance action is selected. Next, we apply the proposed detailed design of decision entity item policy selection to the MetalFAB1 in a case study to answer to the fourth research question: “What are the most appropriate maintenance policies for the maintenance critical items of MetalFAB1?” With respect to the model, we can make several critical remarks. First, in our model we take into account the reliability aspect of a failure mode by determining an expected failure rate characteristic (step 2 in item policy selection). We propose that this is an effective and efficient way to gather information on the reliability without performing expensive and time consuming lifetime tests. However, we recognize that this is a simplification and contains uncertainty. Especially in our case study, a lot of uncertainty is included since we based the classification of the failure rate characteristic only on the expert opinion of the design engineer. This could be improved by involving more people. However, we argue that the time and money saved by not performing lifetime tests while considering all failure modes in the analysis is advantageous. Alternatively, we could take into account only a few failure modes and do perform the lifetime tests. However, we argue that our proposal leads to a more complete initial maintenance program. The uncertainty of guessing the characteristic (instead of testing) may be solved by adapting the initial maintenance program if new information comes in. The second critical remark that we make relates to our proposed decision rules for the RCM analysis (see Decision rule 1 to 4). These decision rules are based on the RPN of an FMECA and

also introduce uncertainty and noise. We propose these decision rules to speed up the RCM analysis by not considering the first questions one-by-one manually and we argue that they are representative for answering the RCM questions. Obviously, some noise/uncertainty will be introduced due to the simplification. The third and final remark that we make is related to the way that we performed the RCM analysis (especially the manual questions). In case a manual question was required (e.g. whether CBM would be an applicable and feasible maintenance policy, see D.2 in Appendix D), we answered this question based on expert knowledge (qualitatively) and not based on numbers (quantitatively). In RCM literature, e.g., Moubray (1997), authors typically recommend to answer the question based on an actual failure data but such information is not available in our project. Obviously, answering the question based on expert knowledge implies uncertainty. Besides the critical remarks above, we argue that our model (including our assumptions and simplifications) proposes a feasible and academically founded method to select maintenance policy types and associated maintenance actions within the constraints of our project. Based on the results of the case study, we argue that we were able to develop a good initial maintenance program. Moreover, the implementation of the model in Microsoft Excel enables the company to easily re-use the proposed maintenance concept in other applications. It also provides a view on how well-established maintenance ideas, such as RCM, can be adopted within relatively new companies (recall that Additive Industriesâ&#x20AC;&#x2122; first was system was introduced last year, Additive Industries BV, 2015).

Chapter 7

Conclusion In this chapter we present our conclusions and recommendations based on the work we did. We recall our main research question for our project: Main Research Question: What is an effective maintenance program for MetalFAB1? In order to answer this question, we have created insights in (1) the failure behavior of MetalFAB1 (Chapter 3) and (2) have developed a feasible maintenance concept to develop a maintenance program (Chapters 4, 5 and 6). Based on these insights, we were able to develop an initial maintenance program that includes the selection of maintenance policy types and actions for selected maintenance critical items (included in Appendix E). In the following sections, we motivate our main conclusions (Section 7.1), present recommendations for the company (Section 7.2) and recommendations for future research (Section 7.3).

7.1

Conclusions

In this section, we motivate our main conclusions based on our work. With regard to the analysis of the failure behavior, we have achieved the following main results: â&#x20AC;˘ We have proposed a new method to efficiently map failure behavior with recursive FTA-FMECA. In Chapter 3 we presented and motivated a new approach for the analysis of failure behavior of new complex capital goods, which we call recursive FTA-FMECA. Our motivation to develop a new approach is that we argue that nor FMECA nor FTA is an evidently best choice for our case. A case study to MetalFAB1 shows that this new approach is promising to save time on the analysis while the most prevalent causes are still analyzed in detail. To the best of our knowledge, a method that combines FTA and FMECA in the way we did, has not yet been reported. Our proposed method can thus be considered to be a new contribution to the literature. â&#x20AC;˘ We have gained insights in the failure behavior of MetalFAB1. The results of the case study of the failure analysis gives Additive Industries more insights in the failure behavior of MetalFAB1. Such a detailed analysis was not yet

performed for MetalFAB1 and is valuable for maintenance decisions and system improvement. With regard to the development of the maintenance program, we have achieved the following main results: • We have proposed an academically founded maintenance concept to develop a maintenance program. In Chapter 5 we presented and motivated a conceptual model to develop a maintenance program for the MetalFAB1. In Chapter 6 we extended the first part (module 1) of the conceptual model into a detailed model to select the maintenance policy type and associated maintenance action. We argue that this is a suitable maintenance concept for MetalFAB1/Additive Industries, since we have shown that it meets the requirements of the company. Moreover, a case study of the application of the detailed design of module 1 shows that our model works. The proposed maintenance concept also shows some new insights for scientific state-of-art. First, the conceptual model shows the applicability of specific maintenance policy models based on the type of executor (OEM vs customer). Second, the conceptual model shows how a company can opt for remote service and support by explicitly devoting certain maintenance actions to the customer. Third, the detailed design of module 1 shows how a starting company can adopt well-established maintenance ideas (e.g. RCM) in a feasible way (without immediately having to invest in time consuming and expensive lifetime testing). In sum, our proposed maintenance concept provides insights in how the company can to achieve its long run goals including high system availability and remote service and support. • We have created an initial maintenance program for a limited number of components/failure modes. As captured in our main research question, our project aimed to develop a maintenance program for MetalFAB1. With the help of our proposed method for failure analysis and the maintenance concept, we were able to select the most appropriate maintenance policies type and associated maintenance actions for selected maintenance critical items. So, we argue that we were able to provide an answer to our main research question. Finally, we add one more general accomplishment: • We have created awareness for maintenance within the company to design engineers and middle management. During the project, we have held many review sessions with involved people within the company (e.g. design engineers, managers, senior management). These sessions were informative and helpful in creating awareness for the importance of maintenance within the (growing) company at different levels. This may contribute to achieve the company’s long run goals as captured in the maintenance objective (see Chapter 4).

7.2

Recommendations for the Company

In this section, we motivate our recommendations for the company for the next steps of our work. With regard to the analysis of the failure behavior, we propose the following to the company:

• Explore the possibilities to adopt the recursive FTA-FMECA method for future failure analyses. The proposed method for failure analysis could be integrated in the regular business processes of Additive Industries as a standard method to map failure behavior of (future) complex systems. We have shown that our proposed method is able to efficiently map failure behavior of new and large systems. Especially for newly developed systems, for which the failure behavior is unknown, our method may lead to better results compared to the standard FMEA/FMECA (right know the standard method for failure analyses within Additive Industries). We argue that better results can be achieved, since in recursive FTA-FMECA the whole system is being analyzed, while the most critical failures receive more depth of analysis. • Extend the failure analysis. In the present project we only selected the top-2 functions of the system FTA for further analysis (see Chapter 3) due to a limited time. However, it is beneficial to select more functions for further analysis to identify more failures. This extends the knowledge on the failure behavior of the MetalFAB1. With regard to the development of the maintenance program, we propose the following to the company. These recommendations are listed in order of time. • Develop the maintenance concept further into a mature decision making tool. Due to a limited amount of time for this project, we only developed a detailed design for module 1 of the conceptual design. We propose to extend the detailed design of the maintenance concept by developing a detailed detailed design for module 2 and 3. This would increase the practical applicability of the model significant, because in the current state we cannot determine a maintenance interval with the model (only type). In the discussion of the conceptual model (see Chapter 5), we describe what these modules should do and provide some ideas for the detailed design. • Explore the possibilities to integrate the model in the business processes. The proposed maintenance concept could be integrated in the regular business process of Additive Industries. We recommend to explore these opportunities to adopt the proposed maintenance concept in practice. For example, it would be interesting to integrate the maintenance policy selection tool (the Microsoft Excel implementation, see Chapter 6) in the issue reporting processes. This enables the Service and Support organization to link an issue/failure mode reported in the field to a maintenance policy and associated maintenance action. • Extend the application of the maintenance concept to more failure modes. If more failure modes of the MetalFAB can be identified, the list of maintenance policies can be extended. These failure modes may follow from an extension of the failure analysis from our project as well as from alternative sources (e.g. regular FMECA or field issue reporting). In addition, if maintenance concept further into a mature decision making tool (i.e. development of detailed design of module 2 and 3), one can complete the maintenance policies with specifying an appropriate maintenance interval.

7.3

Directions for Future Research

In this section, we motivate the recommended future research. With regard to the system analysis of the failure behavior, we recommend the following directions for future research: • Relax the simplifications of the recursive FTA-FMECA approach. In Chapter 3, we describe proposed method for failure analysis. However, for convenience, we made some assumptions and simplifications and we recommend to relax these simplifications to further improve the method. First, we used the simple RPN (RP N = S · O · D) scoring method. An improvement could be to use weighted RPN numbers instead of simple RPN numbers (see e.g. Xiao et al. (2011) or Wang et al. (2009)). This improves the conservative simple RPN in a more realistic RPN that also takes into account the relative importance of each index. Second, in the selection of the most prevalent component failure modes, we propose a selection based on a RPN cut-off value and the resulting percentage of component failure modes that are selected for further analysis. However, we recognize that there may be alternative ways to determine the component failure modes for further analysis. For instance, to plot the results of the FMECA in a histogram chart to determine the right cut-off value. • Research the applicability of the recursive FTA-FMECA method in other settings. In our project, we only tested the recursive FTA-FMECA method in one case study within a specific company. We recommend to test the method also within other high tech companies. We remark to this that the method was specifically developed for analyzing complex engineering systems and we expect that it is most valuable for those kind of systems. For example, it may be interesting to test the method in other high tech OEMs in the Eindhoven region. With regard to the development of the maintenance program, we recommend the following directions for future research: • Research the effects of the proposed decision rules in RCM In Chapter 6, within the detailed design of module 1, we proposed several decision rules in the RCM (Reliability Centered Maintenance) analysis. More specifically, we propose decision rules based on the expected failure rate characteristic and the Risk Priority Number (RPN). However, we recognize that these decision rules imply a simplification and introduce uncertainty. Due to a limited amount of time, we did not research the exact consequences of these decision rules on the quality of the output. For future research, we recommend to investigate the effects of these decision rules in detail. • Research the applicability of the conceptual model in other settings. Similar to our application of the recursive FTA-FMECA method, our conceptual model is also only tested in one case study in a specific company. It may be interesting to test the model, specifically the detailed design, in other high OEMs in the Eindhoven region.

Bibliography Additive Industries BV (2015). Press release: Metalfab1 delivers 10x better reproducibility, productivity and flexibility. Additive Industries BV (2016). Additive Industries Corporate Website. Arts, J. (2014). Elementary maintenance models. Eindhoven University of Technology. Bertsche, B. (2010). Reliability in Automotive and Mechanical Engineering: Determination of Component and System Reliability. Springer. Birolini, A. (2010). Reliability Engineering: Theory and Practice. Springer. Blanchard, B. and Fabrycky, W. (2006). Systems Engineering and Analysis. Springer. Brunelli, M. (2015). Introduction to the Analytic Hierarchy Process. Springer. Dekker, R., Wildeman, R., and van der Duin, F. (1997). A review of multi-component maintenance models with economic dependence. Mathematical Methods of Operations Research, 45:411–435. Deshpande, V. and Modak, J. (2001). Application of rcm to a medium scale industry. Reliability Engineering and System Safety, 77:31–43. Dhillon, B. and Reiche, H. (1985). Reliability and Maintainability Management. van Nostrand Reinhold Company. DoD, U. (1980). MIL-STD 1629A Failure Modes, Effects, and Criticality Analysis. Fore, S. and Mudavanhu, T. (2011). Application of rcm for a chipping and sawing mill. Journal of Engineering, Design and Technology, 9:204–226. Fransoo, J. (2015). Lecture notes in design of operations planning and control systems. Goossens, A. (2015). Maintenance Policy Selection for Ships: an investigation using analytic hierarchy process. PhD thesis, University of Twente. Hamada, M., Reese, S., Wilson, A., and Martz, H. (2008). Bayesian Reliability. Springer. Hypko, P., Tilebein, M., and Gleich, R. (2012). Clarifying the concept of performancebased contracting in manufacturing industries: A research synthesis. Journal of Service Management, 21(5):625–655.

Jain, A., Bhatti, R., and Singh, H. (2014). Total productive maintenance (tpm) implementation practice: A literature review and directions. International Journal of Lean Six Sigma, 5:293–323. Jones, J. (1987). Integrated Logistics Support Handbook. TAB Professional and Reference Books. Kelly, A. (1997). Maintenance strategy. Oxford : Butterworth-Heinemann. Kobbacy, K. and Murthy, D. P. (2008). Complex Maintenance Handbook. Springer. Marquez, A. C. (2007). The Maintenance Management Framework. Springer. Moubray, J. (1997). Reliability-Centered Maintenance. Oxford : Butterworth-Heinemann. Muller, G. (2016). System Architecting. Gaudi project: www.gaudisite.nl. Nowlan, F. and Heap, H. (1978). Reliability-centered maintenance. United Airlines. Reproduced by US Departement of Commerce, Springfied. Peeters, J. (2016). Literature review: Maintenance of complex capital goods. Pintelon, L., Gelders, L., and van Puylvelde, F. (1997). Maintenance Management. Acco Leuven. Rausand, M. (1998). Reliability centered maintenance. Reliability Engineering and System Safety, 60:121–132. Smets, L., van Houtum, G., and Langerak, F. (2012). Design for availability: a holistic approach to create value for manufactureres and customers of capital goods. Journal of Systems Engineering China, 21(4):403–421. Smit, K. (2010). Onderhoudskunde. VSSD. Snelgrove, T. (2012). Value pricing when you understand your customers: Total cost of ownership - past, present and future. Journal of Revenue and Pricing Management, 11(1):76–80. Stamatelatos, M., Vesely, W., Dugan, J., Fragola, J., Minarick, J., and Railsback, J. (2002). Fault Tree Handbook with Aerospace Applications. NASA. Tinga, T. (2013). Principles of Loads and Failure Mechanisms: Applications in Maintenance, Reliability and Design. Springer. Tinga, T. (2016). Personal meeting with prof. dr. ir. t. tinga on 08-04-2016. Unpublished personal meeting. van Dijkhuizen, G. and van Harten, A. (1997). Optimal clustering of frequency-constrained maintenance jobs with shared set-ups. European Journal of Operational Research, 1997:552– 564. van Horenbeek, A. (2013). Information-based maintenance optimization with focus on predictive maintenance. PhD thesis, KU Leuven.

van Laarhoven, D. (2016). World-class service and support. Bachelor thesis, Avans University of Applied Sciences. Waeyenbergh, G. (2005). CIBOCOF. A Framework for Industrial Maintenance Concept Development,. PhD thesis, KU Leuven. Wang, H. and Pham, H. (2006). Reliability and Optimal Maintenance. Springer. Wang, Y.-M., Chin, K.-S., Poon, G., and Yang, J.-B. (2009). Risk evaluation in failure mode and effects analysis using fuzzy weighted geometric mean. Engineering Failure Analysis, 36:1195–1207. Woodhouse, J. (1993). Managing industrial risk. London: chapman hill. Xiao, N., Huang, H.-Z., Li, Y., He, L., and Jin, T. (2011). Multiple failure modes analysis and weighted risk priority number evaluation in fmea. Engineering Failure Analysis, 18:1162– 1170. Yu, S., Liu, J., Yang, Q., and Pan, M. (2011). A comparison of fmea, afmea and fta. Reliability, Maintainability and Safety (ICRMS), pages 954 – 960. Zachariassen, F. and Arlbjorn, J. S. (2011). Exploring a differentiated approach to total cost of ownership. Industrial Management and Data Systems, 111(3):448–469. Zhu, Q. (2015). Maintenance Optimization for Multi-component Systems under Condition Monitoring. PhD thesis, Eindhoven University of Technology.

Appendix A

Example of Recursive FTA-FMECA

Example: Recursive FTA-FMECA of a simple boat System

1. System Level FTA

2. System Level FMECA

Boat is not functioning properly

Float function failure

Propulsion function failure

Control function failure

Secondary failures

3. Function Level FTA

4. Function Level FMECA

Float function failure

Too heavy loaded

Hull leaks

Holes in hull

Weather influences

Hull failure

5. Component Level FTA

6. Component Level FMECA

Hull failure

Paint degradation

Corrosion

Legend Colors

Top failure event

System function failure mode

Intermediate event

Component failure mode

Failure mechanism

For details of FTA symbols see Figure 3.2 and for details of FMECA see Figure 3.1.

Figure A.1: Example of application of recursive FTA-FMECA to a simple boat

Appendix B

Results of Application of Recursive FTA-FMECA to MetalFAB1 This appendix describes the results of the application of the recursive FTA-FMECA approach as described in Chapter 3. Due to confidentiality of the results, this appendix is not included in the public version of this report.

Appendix C

Interview Transcripts This appendix presents the interview transcripts of the interviews with key stakeholders within the company. The goal of these interview sessions was to identify the important points for the maintenance objective. Due to confidentiality of the interviews, this appendix is not included in the public version of this report.

Appendix D

RCM Analysis This appendix presents decision diagrams for performing a Reliability Centered Maintenance analysis within the context of module 1 of our conceptual model. The expected outcome of this analysis is a list of policy types. The diagrams are based on Moubray (1997) and Nowlan and Heap (1978), but we slightly adjusted it for our model (e.g., integration of automated decisions based on the results of an FMECA). The following decision diagrams are included: 1. Overall RCM diagram. The diagram in Figure D.1 presents the high level decision diagram of the analysis that guides the analysis to which detailed diagram should be followed. The diagram can be used to evaluate qualitatively which maintenance policy type is applicable and effective for a certain failure mode. The overall RCM diagram refers to the subdiagrams in Figure D.2 ot D.4. Moreover, in order to automate / re-use the information of previous failure analysis (e.g. FTA-FMECA or FMECA), we developed a several decision rules based on the indexes RPN number (i.e. the severity-index, occurrence-index and detectablility-index). These are the annotated in the Figure. 2. Consideration of CBM. The diagram in Figure D.2 presents a guideline to answer the question “Is an on-condition (CBM) task to detect the potential failure both applicable and effective?” (Question 4, 8, 11, 14). The output is either “YES, CBM effective/applicable” or “NO, CBM is not effective/applicable”. If the answer is YES, there is a subsequent choice between “CBM (continuous)” and “CBM (periodic)”. 3. Consideration of TBM/UBM (repair). The diagram in Figure D.3 presents a guideline to answer the question “Is a scheduled repair task to reduce the failure rate both applicable and effective” (Question 5, 9, 12, 15). The output is either “YES, TBM/UBM (repair) effective/applicable” or “NO, TBM/UBM (repair) is not effective/applicable”. 4. Consideration of TBM/UBM (replacement). The diagram in Figure D.4 presents a guideline to answer the question “Is a scheduled replacement task to avoid failures or reduce the failure rate both applicable and effective” (Question 6, 10, 13, 16). The output is either “YES, TBM/UBM (replacement) effective/applicable” or “NO, TBM/UBM (replacement) is not effective/applicable”.

Figure D.1: Overall RCM diagram

Legend

Time- or Usage based maintenance (TBM/UBM) with repair policy recommended

Failure finding task or scheduled test recommended

Failure finding task

DECISION RULE 7 Decision flowchart ``Consideration of TBM/UBM(replacement)”

TBM/UBM (replacement)

DECISION RULE 6 Decision flowchart ``Consideration of TBM/UBM(repair)”

TBM/UBM (repair)

DECISION RULE 5 Decision flowchart ``Consideration of CBM”

CBM

YES

CBM

TBM/UBM (repair)

DECISION RULE 5 Decision flowchart ``Consideration of CBM”

TBM/UBM (replacement)

DECISION RULE 7 Decision flowchart ``Consideration of TBM/UBM(replacement)”

DOM required

DECISION RULE 6 6. Is an scheduled replacement Decision flowchart ``Consideration of TBM/UBM(repair)” task to avoid or reduce the failure rate both applicable and effective?

5. Is an scheduled repair task to reduce the failure rate both applicable and effective?

YES M NO

YES

10. Is an scheduled replacement task to avoid or reduce the failure rate both applicable and effective?

9. Is an scheduled repair task to reduce the failure rate both applicable and effective?

YES

8. Is an on-condition task to detect the potential failure both applicable and effective?

3a. Consider preventive maintenance?

YES

TBM/UBM (replacement) DECISION RULE 7 Decision flowchart ``Consideration of TBM/UBM(replacement)”

FBM

DECISION RULE 6 Decision flowchart ``Consideration of TBM/UBM(repair)”

TBM/UBM (repair)

DECISION RULE 5 Decision flowchart ``Consideration of CBM”

CBM

YES

M NO

YES

13. Is an scheduled replacement task to avoid or reduce the failure rate both applicable and effective?

12. Is an scheduled repair task to reduce the failure rate both applicable and effective?

YES

TBM/UBM (replacement) DECISION RULE 7 Decision flowchart ``Consideration of TBM/UBM(replacement)”

FBM

DECISION RULE 6 Decision flowchart ``Consideration of TBM/UBM(repair)”

TBM/UBM (repair)

DECISION RULE 5 Decision flowchart ``Consideration of CBM”

CBM

M NO

YES

Failure finding task

16. Is an scheduled replacement task to avoid or reduce the failure rate both applicable and effective?

15. Is an scheduled repair task to reduce the failure rate both applicable and effective?

YES

14. Is an on-condition task to detect the potential failure both applicable and effective?

YES

1a. Consider preventive maintenance?

HIDDEN CONSEQUENCES Scheduled maintenace is ensure the level of availability necessary to avoid exposure to a multiple failure

HIDDEN FUNCTIONS

DECISION RULE 4 IF FAILURE CHARACTERISTIC == ``IFR’’ THEN YES OTHERWISE NO

NONOPERATIONAL CONSEQUENCES (ECONOMIC) Scheduled maintenance is desirable if its cost is less than the cost of a failure 3a. Consider preventive maintenance?

11. Is an on-condition task to detect the potential failure both applicable and effective?

DECISION RULE 4 IF FAILURE CHARACTERISTIC == ``IFR’’ THEN YES OTHERWISE NO

DECISION RULE 3 IF RPN(SEVERITY INDEX) => 5 AND < 10 THEN YES OTHERWISE NO

DECISION RULE 1 IF RPN(DETECTABILITY INDEX) < 8 THEN YES OTHERWISE NO

1. Is the occurence of the failure mode evident for an operator under normal circumstance?

Start

3. Does the failure have a direct adverse effect on operation capability?

OPERATIONAL CONSEQUENCES YES (ECONOMIC) Scheduled maintenance is desirable if its cost is less than the cost of a failure

DECISION RULE 2 IF RPN(SEVERITY INDEX) == 10 THEN YES OTHERWISE NO

2. Does the failure mode cause a loss of function or secondary damage that could direct affect on safety?

YES

EVIDENT FUNCTIONS

DECISION RULE 4 IF FAILURE CHARACTERISTIC == ``IFR’’ THEN YES OTHERWISE NO NO

2a. Consider preventive maintenance?

4. Is an on-condition task to detect the potential failure both applicable and effective?

DECISION RULE 4 IF FAILURE CHARACTERISTIC == ``IFR’’ THEN YES OTHERWISE NO

SAFETY CONSEQUENCES Scheduled maintenace is required to reduce the risk of failure to an acceptable level.

Design-out maintenance (DOM) or design change recommended

DOM required

YES

Failure based maintenance policy recommended

FBM

Time- or Usage based maintenance (TBM/UBM) without repair policy recommended

Condition based maintenance (CBM) policy recommended

TBM/UBM (repair)

TBM/UBM (replacement)

Manual decision based on additional decision flowchart

Automated decision based on decision rule that uses information from previous FMECA analysis

CBM

Source: Nowlan, F. and Heap, H. (1978). Reliability-centered maintenance. United Airlines. Reproduced by US Department of Commerce, Spring ed.

Reliability Centered Maintenance - main decision flowchart

Reliability Centered Maintenance â&#x20AC;&#x201C; consideration of CBM

Source: Nowlan, F. and Heap, H. (1978). Reliability-centered maintenance. United Airlines. Reproduced by US Department of Commerce, Spring ed.

Legend M CBM

Manual decision based on additional decision flowchart Condition based maintenance (CBM) policy recommended

Start 4/8/11/14. Is an on-condition (CBM) task to detect the potential failure both applicable and effective?

AND GATE Assess applicablility (technical feasibility)

Assess effectiveness (economical feasibility)

Technical feasibility

Economical feasibility

Start

Failure rate characteristic (expected to be) increasing?

Does the failure cause (unsually) high repair costs?

YES

Is the condition measureable? Is the failure rate high? M

Technical infeasible

Economical infeasible

YES Can a Potential failure be identified?

YES

M YES

Does an economic tradeoff study justify the task? NO. CBM not effective/ applicable

Is the P-F (potential failure (P) to failure (F) ) interval large enough?

OR GATE

M YES Economical feasible

YES Technical feasible

AND GATE

YES. CBM effective/applicable

Figure D.2: Consideration of CBM

Reliability Centered Maintenance â&#x20AC;&#x201C; consideration of TBM/UBM(repair) Source: Nowlan, F. and Heap, H. (1978). Reliability-centered maintenance. United Airlines. Reproduced by US Department of Commerce, Spring ed.

Legend M TBM/UBM (repair)

Manual decision based on additional decision flowchart Time- or Usage based maintenance (TBM/UBM) with repair policy recommended

Start 5/9/12/15. Is an scheduled repair task to reduce the failure rate both applicable and effective? AND GATE Assess effectiveness (economical feasibility)

Assess applicablility (technical feasibility) Technical feasibility

Economical feasibility

Start Start Failure rate characteristic (expected to be) increasing?

SAFETY or HIDDEN consequences? Is the scheduled repair task likely to take less time than a FBM task?

YES

M YES

Is there an identifiable age or usage indicator value at which the item shows a rapid increase in conditional probability of failure?

YES Does an economic tradeoff study vs FBM justify the task?

YES

Is there an identifiable age or usage indicator value at which the item cannot function properly anymore?

Economical infeasible

YES

YES M

OR GATE

Technical infeasible

YES

Economical feasible

Do most of the items survive at that age/usage indicator vla (all of the items in case fo safety consequences)?

OR GATE

NO NO. TBM/UBM (repair) not effective / applicable.

Can a repair action restore the failed item back to its original state?

YES Technical feasible

AND GATE

YES. TBM/UBM (repair) effective and applicable.

Figure D.3: Consideration of TBM/UBM (repair)

Reliability Centered Maintenance â&#x20AC;&#x201C; consideration of TBM/UBM(replacement) Source: Nowlan, F. and Heap, H. (1978). Reliability-centered maintenance. United Airlines. Reproduced by US Department of Commerce, Spring ed.

Legend M

Manual decision based on additional decision flowchart

TBM/UBM (replacement)

Time- or Usage based maintenance (TBM/UBM) without repair policy recommended

Start

6/10/13/16. Is an scheduled replacement task to avoid or reduce the failure rate both applicable and effective?

AND GATE Assess applicablility (technical feasibility)

Assess effectiveness (economical feasibility)

Technical feasibility

Economical feasibility

Start Start Failure rate characteristic (expected to be) increasing?

SAFETY or HIDDEN consequences?

Is the scheduled repair task likely to take less time than a FBM task?

YES Is there an identifiable age or usage indicator value at which the item shows a rapid increase in conditional probability of failure?

M YES YES

Does an economic tradeoff study vs FBM justify the task?

YES

Is there an identifiable age or usage indicator value at which the item cannot function properly anymore?

Economical infeasible

NO YES

YES M

OR GATE

Technical infeasible

YES

Economical feasible

Do most of the items survive at that age/usage indicator vla (all of the items in case fo safety consequences)?

M YES Technical feasible

OR GATE

NO NO. TBM/UBM(replacement) not effective/ applicable

AND GATE

YES. TBM/UBM(replacement) effective and applicable

Figure D.4: Consideration of TBM/UBM (replacement)

Appendix E

Results of Application of Module 1 to MetalFAB1 This appendix presents the results of the application of decision entity item policy selection of module 1: selection of our maintenance concept. Due to confidentiality of the results, this appendix is not included in the public version of this report.