pdf download - Software and Computer Technology - TU Delft

More documents

Recommendations

Info

2.2 Overview Today’s Practice State-of-the-Practice Fault diagnosis at PMS faulty components. The situation in which one component is adjudged or hypothesized to be broken is called a single fault. If more components are adjudged or hypothesized to be broken, there are multiple faults. These concepts are important, because taking into account multiple faults greatly affects the number of possible causes for a particular error; it is exponential. A fault scenario is a specific occurrence of a fault. In this thesis, fault scenario is defined as a tuple that consists of a fault and an error. An example of a fault scenario is the malfunctioning of CableB and its manifestation in the error; TBCB, CRCB and Collimator are off, while they should be on. Further decomposing the ”CableB subsystem” could uncover faults on a lower level of detail. For example, CableB is not connected to the Power Distribution Unit. Or Cable does not conduct current. However, the fault diagnosis techniques described in this thesis aim to identify broken components that could be replaced, the so-called FRUs. So, the statement ”CableB is broken” suffices. A multiple fault diagnosis of the error is that the FRUs LV_PS2 and FuseD are broken. An important issue to realize is that not all faults cause an error, and not all errors cause a failure. Faults can be active (cause an error) or dormant (not causing an error). Also, internal errors could be dealt with by other subsystems. Fault diagnosis could aim at the identification of all kinds of faults. However, the work in this thesis aims at the identification of active faults that result in a failure. In the example fault scenario described above, the diagnostic process should identify CableB as a suspicious component. Section 2.3 shows how the current diagnostic process at PMS identifies CableB. The next chapter shows how automated approaches diagnose CableB as a broken component. The next chapter also extends the fault diagnosis related concepts and terminology that is introduced in this section. The remainder of this chapter uses the terms that are explained above for describing and evaluating the current approach to fault diagnosis at PMS. 2.2 Overview Today’s Practice The need for fault diagnosis starts when the operator experiences a failure of the system. This section has been divided into two parts. First, the procedure that starts when a failure occurs is discussed. Then, the second part introduces the available means that service engineers and other troubleshooters have. 2.2.1 Current Procedure to Fault Diagnosis The fault diagnosis process of today has a procedure that is quite complex. Consider Figure 2.3. This figure clarifies all actors that play a role, and all actions that are performed when a failure occurs. Normally, the operator uses the system without a problem. When difficulties are encountered then he/she calls the local help desk for help. If the problems in using the system can not be solved by giving instructions for use, a service engineer is sent to the hospital in order to diagnose and possibly repair the system. In customary fault scenarios this is sufficient. However, the service engineer has not been educated to solve all problems. In many cases, he is puzzled and has to call the local help desk for help. This way, it is possible that a problem has to be propagated to the more expertized regional and global help desks. Eventually, people that developed the system are called to help the service engineer or solve the problem themselves. Figure 2.3 shows which activities must be done for diagnosing a system, when an operator faces a failure. Service Innovation is a department at PMS Cardio-Vascular that is responsible to provide service engineers with information that is necessary for diagnosing Philips Cardio-Vascular X-Ray Systems. Developers of the system know much of this information. Therefore, employees at the Service Innovation department interview developers in order to write down knowledge that can be used for diagnosing. The legend of Figure 12
State-of-the-Practice Fault diagnosis at PMS 2.2 Overview Today’s Practice Figure 2.3: The current procedure for doing fault diagnosis (and repair). 2.3 refers to these efforts of Service Innovation as preparatory activities. The goal of the Service Innovation department is trying to prevent as many problems as possible from propagating to the C/V development department. If a diagnosis is adjudged, it is used to recover the system. At PMS this means that the malfunctioning components are replaced with healthy components. This requires that substitutable FRUs are provided as soon as possible. 2.2.2 Current Means to Fault Diagnosis The list below is an overview of all means that a troubleshooter 1 has in order to diagnose and/or repair a malfunctioning system. The order gives an indication of the importance of the specific means for the service engineer. Especially the last two items are rarely used in practice. Interviewing the operator about the problem Best case, the interview already pinpoints the search for the malfunctioning FRU to a certain subsystem or collection of FRUs. It is also possible that he finds out that the failure might be caused by an incident or abnormal use of the system. Visual checking the system The service engineer has access to the system, so he is able to look for unexpectedly flashing LEDs (that indicate the status of some FRUs), loose cables or any mechanical damage. Checking the log A log is a digital file that consists of data that a system produces during real-time operation. This data contains information about past system behavior (e.g.,: the occurrence of events, error messages, warnings, values of parameters). They all could pinpoint to a 1 In this section we use the term troubleshooter, instead of service engineer, to emphasize the fact that these means are available to all troubleshooters. 13
Page 1: Automated Fault Diagnosis at Philip
Page 4 and 5: © 2006 W.M. Lindhoud. Document gen
Page 7: Preface The work presented in this
Page 10 and 11: CONTENTS 4.4 Modeling . . . . . . .
Page 13: List of Tables 3.1 Evaluation appro
Page 16 and 17: 1.1 Fault Diagnosis Introduction Fi
Page 18 and 19: 1.2 Automated Fault Diagnosis Intro
Page 20 and 21: 1.5 Outline of the Thesis Introduct
Page 23 and 24: Chapter 2 State-of-the-Practice Fau
Page 25: State-of-the-Practice Fault diagnos
Page 29 and 30: State-of-the-Practice Fault diagnos
Page 31 and 32: State-of-the-Practice Fault diagnos
Page 33 and 34: Chapter 3 Automated Fault Diagnosis
Page 35 and 36: Automated Fault Diagnosis 3.1 Overv
Page 41 and 42: Automated Fault Diagnosis 3.3 Off-l
Page 43 and 44: Automated Fault Diagnosis 3.5 Model
Page 45: Automated Fault Diagnosis 3.6 Evalu
Page 48 and 49: 4.1 Fundamentals Model-Based Fault
Page 50 and 51: 4.2 Model-Based Diagnosis with LYDI
Page 52 and 53: 4.3 Basic Assumptions Model-Based F
Page 54 and 55: 4.4 Modeling Model-Based Fault Diag
Page 56 and 57: 4.4 Modeling Model-Based Fault Diag
Page 58 and 59: 4.5 Entropy Gain Model-Based Fault
Page 60 and 61: 4.6 MBD on the Power Supply Model-B
Page 63 and 64: Chapter 5 Diagnosing the Beam Prope
Page 65 and 66: Diagnosing the Beam Propeller Movem
Page 77 and 78:
Diagnosing the Beam Propeller Movem
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Chapter 6 Conclusions and Recommend
Page 85:
Conclusions and Recommendations 6.2
Page 88 and 89:
BIBLIOGRAPHY [12] Johan de Kleer an
Page 91 and 92:
Appendix A Glossary of terms In thi
Page 93 and 94:
Glossary of terms • Diagnostic Pe
Page 95 and 96:
Glossary of terms • Model: an abs
Page 97:
Glossary of terms • System: an en
Page 100 and 101:
B.2 System Data Case Study Details
Page 102 and 103:
B.4 Full List of Examined Fault Sce
Page 104 and 105:
B.5 Discretization of Implementatio
Page 106 and 107:
C.1 The Synthetic Models that are U
Page 108 and 109:
C.2 Model of the Power Supply Examp
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
C.3 The Models Constructed for the
Page 116 and 117:
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 131 and 132:
Appendix D State-of-the-Future Faul
show all

pdf download - Software and Computer Technology - TU Delft

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?