pdf download - Software and Computer Technology - TU Delft

More documents

Recommendations

Info

3.4 Automated Induction using White Box Information Automated Fault Diagnosis contrary, the expert’s knowledge about the system enables him to distinguish much more symptoms. This way he/she is able to define a mapping of symptoms on more useful diagnoses. The results of this process is shown in Table 3.2. It can easily be verified by considering the block diagram of Figure 3.3. This table can then be used each time a failure occurs and serves as a LUT. Suppose CableB has been broken again. The observation, that could be extracted from the log, would be as follows: status_Chiller = true status_FD = true status_TBCB = false status_CRCB = false status_Collimator = false A lookup in the table shows that this valuation of the observables corresponds to the entry identified by fault scenario 7 of Table 3.2. The corresponding diagnosis is that either the PDU or CableB is broken. Y Observations Diagnosis CHIL. FD TBCB CRCB COL. Possible single faults 0 1 1 1 1 1 None: entire system healthy 1 1 1 1 1 0 FuseD, LV_PS3, Collimator 2 1 1 1 0 1 FuseC, CRCB 3 1 1 1 0 0 None: only multiple faults 4 1 1 0 1 1 FuseB, TBCB 5 1 1 0 1 0 None, only multiple faults 6 1 1 0 0 1 LV_PS2 7 1 1 0 0 0 PDU, CableB 8 1 0 1 1 1 FuseA, CableA, LV_PS1, PDU, Flat Detector 9 1 0 1 1 0 None, only multiple faults 10 1 0 1 0 1 None: only multiple faults 11 1 0 1 0 0 None: only multiple faults 12 1 0 0 1 1 None: only multiple faults 13 1 0 0 1 0 None: only multiple faults 14 1 0 0 0 1 None: only multiple faults 15 1 0 0 0 0 PDU, Chameleon 16 0 0 0 0 0 PDU Table 3.2: Partial diagnosis look-up table of the Power Supply system for single faults (startup = true) 3.4 Automated Induction using White Box Information This section discusses a technique that automatically induces white box information. This technique requires a structural model of the system and a fault detection mechanism. The power supply example is very suitable to explain how such an approach would work. The outputs can be considered as error detection mechanisms. This supplies us with passed/failed results of particular paths through the system. In our example, if CableB is broken the path to the Flat Detector will pass, but the path to the Collimator is likely to fail. For hardware, these paths (called traces) can be extracted from the system structure. Table 3.3 shows the traces that a broken CableB yields. This 28
Automated Fault Diagnosis 3.5 Model-Based Approach to Fault Diagnosis Nr. Trace Passed/Failed 1 PDU-CableA-LV_PS1-FuseA-Flat Detector passed 2 PDU-CableB-LV_PS2-FuseB-TBCB failed 3 PDU-CableB-LV_PS2-FuseC-CRCB failed 4 PDU-CableB-LV_PS3-FuseD-Collimator failed 5 PDU-CableC-Chiller passed Table 3.3: Input matrix for data analysis of the example fault scenario information is then subject to statistical analysis to find possibly malfunctioning components. This statistical technique is called data clustering, and finds the components which are mostly correlated with failures [7]. In the example, LC_PS2 is two times member of a failed trace. However, the PDU and CableB are both three time members of failed traces, and therefore one of them is most likely to be at fault. This brings us the same result as suggested by an expert (see fault scenario 7 of Table 3.2). 3.5 Model-Based Approach to Fault Diagnosis Model-Based fault Diagnosis is a white box technique that defines behavior of the system rather in terms of cause-to-effect than to effect-to-cause. Although all approaches described above can be implemented by means of a MBD technique. The next chapter gives a proper introduction to the subject, this section only offers a first idea. An illustrative way to look at the solution that consistency-based approach provides, is to view it as the removal of assumptions to resolve inconsistencies between predicted and observed behavior. Using the assumption that all components function correctly, the behavioral model enables the calculation of the effects, given the cause (startup = true). In the example, if the system is switched on all components should be on too. During system behavior this prediction is compared to the effects that are actually observed. If CableB is broken the prediction and observations do not coincide. The prediction is that all variables are true, while it is observed that the TBCB, CRCB and Collimator are false. Therefore, the assumption that all components are healthy is wrong. Any assumption that a component (or group of components) is functioning correctly could be false. A diagnostic engine is responsible to search for the false assumptions. If the assumption that CableB is functioning correctly is dropped, the prediction falls together with the observations. Therefore, CableB is a single fault diagnosis. Obviously, it is much more likely that just this cable is broken than all components. Determining what assumptions do not hold can be seen as a search problem and is time/space complex. Continuing the search would state that dropping the assumption that the PDU is healthy yields another single fault diagnosis. The search process would also find many groups of components that can not all be healthy at the same time (for example the set of all components). These are the multiple fault diagnoses. Usually, a MBD engine produces a list of possible diagnoses. A calculation of probabilities is used to order the list. This way, a service engineer can use the output of the MBD approach to prioritize his/her diagnostic activities. 3.6 Evaluation of Approaches to Fault Diagnosis In this section the approaches that are described in this chapter and the current approach (as described in Chap. 2) are evaluated using the items of section 2.4.1 as criteria. Table 3.4 shows 29
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 and 26: 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: Automated Fault Diagnosis 3.3 Off-l
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 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

Create successful ePaper yourself

Delete template?

Save as template?