pdf download - Software and Computer Technology - TU Delft

More documents

Recommendations

Info

5.5 MBD Implementation 2 Diagnosing the Beam Propeller Movement of the Frontal Stand 5.4.5 Results of the MBD-1 Implementation The goal of this step was to define a MBD implementation to fault diagnosis that achieves the same entropy as experts are able to achieve. The LUT, that specifies the outcome of the LYDIA diagnostic engine for all possible observations, is exactly equal to Table 5.5. Consequently, the entropy (H) of the MBD implementation (MBD-1) is the same: H MBD−1 = 0.9453 (5.4) 5.5 MBD Implementation 2 This sections presents a second iteration of steps 2, 3, and 4 of the case study approach. The intended result is that the uncertainty decreases without having to make additional measurements, but by improving the model. The idea is as follows. A good diagnostic approach takes advantage of every possible inference that could be drawn out of all available system data. Therefore, in this iteration, experts and modeler search for more symptoms within the examined system data. If one tries to ’discover’ more symptoms in the same system data, it is useful to discretize the system data. Most data of the fault scenarios shown in Table 5.4 is in the domain of integers. Humans experience difficulties to reason about faulty components using such a level of detail. As explained in the previous chapter, humans are better able to perform fault diagnosis using a domain with few members. The applied discretization is defined by source domain N and target domain M. The target domain M is defined as follows: ⎧ T L, ⎪⎨ M = ⎪⎩ : Too Low. The threshold has been violated. L, : Low. Negative polarity of the value. N, : Nominal. Close to zero. H, : High. Positive polarity of the value. T H : Too High. The threshold has been violated. The source domain is the domain of natural numbers N. The target domain values can be chosen in many ways. In this case these particular values (L denotes negative polarity, N denotes close to zero, etc.) are meaningful when reasoning from first principles about the target system. The mapping of values in the source domain N to the target domain M is shown in Appendix B.5. Table 5.6 shows the discretized values of the observations. Note that the table shows other variables than shown in Table 5.4. Discretizing the variables Pact and Pset is not useful, because the system does not show different behavior for different angles of the frontal stand. The variables Imin and Imax are used to calculate the polarity of Iset and Iact (see Appendix B.5), and do not have value on their own. The values of Table 5.6 are much easier to interpret than the raw system data of Table 5.4. Much of the discretized variables have values that experts expect (see Section 5.3). A current error implies that the Iact and Iset differ. A speed error implies that Vact and Vset differ. From system behavior, it is also expected that the value of Iset has the same polarity as the value of e_sp. This does not hold for fault scenario 3, as can be seen in Table 5.6. In this fault scenario, the inequality of Iset and e_sp is a symptom of a malfunctioning system. Figure 5.3 shows that CTR_speed must be at false. This unit is of lower than the chosen granularity, and therefore the symptom identifies that the LUC_Extension is malfunctioning. 62
Diagnosing the Beam Propeller Movement of the Frontal Stand 5.5 MBD Implementation 2 Signal Iact Iset e sp Vact Vset e pos C S P PV Fault Scenario S1 TL H H H H N T F F F A S2 TH L L L L N T F F F S3 H TL H H H N T F F F S4 TL H H L L N T F F F S5 L L L TH L L F T F F B S6 L L L TH L L F T F F S7 H H H TL H H F T F F S8 L L L TH L L F T F F S9 H H N L L N F F T F C S10 L H N H N N F F T F D S11 L L L L L N F F F T Table 5.6: Discretization of the system data of fault scenario 1 till 11 to domain M. The specification of the new model should specify additional behavior of the LUC_Extension, so that the diagnostic engine is able to derive the new symptom-on-diagnosis mapping. The causeto-effect relation that specifies the behavior is as follows: h_EXT => (Iset = e_sp); There are various ways to fulfil the addition to the model. One of the possibilities is to define Iset and e_sp as observables in domain M, and insert their value by an automated tool that performs the mapping of the system data to domain M values. This unnecessarily complicates the code of the model. A better solution is to add an observable variable ctr_speed, that is derived from the variables Iset and e_sp. In this implementation, the model must also define how the value of ctr_speed is derived from the system data: // definition derivative ctr_speed ctr_speed = (Iset != e_sp); The tool responsible for applying the discretization from domain N values to domain M values, and to calculate the value of the ctr_speed variable. When ctr_speed = 1, the MBD engine derives the diagnosis that the LUC_Extension is at false. 5.5.1 Results of the MBD-2 Implementation Table 5.7 shows the new LUT that the LYDIA diagnostic engine produces when all possible observations are inserted. It includes one extra observation, namely Y17. The entropy H MBD−2 of the model described in this section is: H MBD−2 = 0.9453 (5.5) Despite the fact that we expected to achieve an entropy gain, there is no entropy gain at all. The equation ’H MBD−2 = H MBD−1 ’ holds for 20 significant digits. This seems quite peculiar. MBD-2 is able to diagnose the fault scenario S3 with hundred percent certainty. After all, the list of diagnoses that the LYDIA engine produces contains only 1 item, namely the LUC_Extension. At first sight it seems strange that MBD-2 does not yield any entropy gain compared to MBD-1. However, the values of the observables for fault scenario S3 are very rare, and for both implementation the 63
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 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 75: 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 114 and 115: C.3 The Models Constructed for the
Page 126 and 127:
C.3 The Models Constructed for the
Page 128 and 129:
C.3 The Models Constructed for the
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?