pdf download - Software and Computer Technology - TU Delft

More documents

Recommendations

Info

2.3 Manual Fault Diagnosis State-of-the-Practice Fault diagnosis at PMS particular subsystem. However, the service engineer has to understand this information, in order to be able to use it for diagnosing a system. Performing Power-On-Self-Tests (POSTs) For some FRUs a so-called POST exists. A POST is a test of one FRU that is automatically performed at startup. It can either fail or succeed. A failure indicates that the FRU is broken or not correctly connected. Performing Build-In-Self-Tests (BISTs) For some FRUs a so-called BIST exists. A BIST is a test of one or more FRUs that can be performed in Field Service mode 2 . Just like a POST it can either fail or succeed. A failure indicates that something is wrong with the associated FRUs and their interconnections. Searching for Symptom-Cause-and-Solution sheets For well-known problems the Service Innovation department has made a bundle of quick lookup sheets, each containing symptoms, and their corresponding cause and solution. Searching the Error-on-Solution database If a service engineer finds a certain error message in the log file, he can search a database for the corresponding cause and solution. Again, only well-known problems are included. Using Technical Drawings To enable the checking of cable- and FRU-connections, Service Innovation has made a collection of technical drawings that define the structure of the system at various levels of detail. Using Fault Isolation Procedures (FIPs) These are tree-like graphs that define a sequence of steps and tests in order to repair a malfunctioning part of the system. It is an artifact made by Service Innovation. Reviewing job sheets All essential action that troubleshooters perform must be documented in a so-called job sheet. If a problem can not be eliminated, it is useful to examine this history of diagnosis and repair. Unfortunately, these job sheets are ambiguous in what components are diagnosed to be broken, and which repair actions are taken. Checking trace files Tracing contains, just like logging, information about the past system behavior. The difference is that tracing contains much more detail. Only (special) experts of the system can take advantage of it in their fault diagnosis (when this happens the problem will most likely be solved by changing the design of the system). Symptom-Cause-and-Solution sheets, Error-on-solution database, Technical Drawings and FIPs are all artifacts made by Service Innovation, and illustrated in Figure 2.3 by the books in the actor’s hands. 2.3 Manual Fault Diagnosis This section describes a concrete example of the current approach to fault diagnosis, when a failure occurs in the power supply example. The failure is the - earlier discussed - example fault scenario in which CableB is broken. As Section 2.2 described, a service engineer has to visit the hospital 2 Field service mode is a special use of the system, especially made for diagnosing it. Using the system in this mode enables the viewing of parameters and the performing of tests. 14
State-of-the-Practice Fault diagnosis at PMS 2.4 Optimal Fault Diagnosis where a system is located, and start the search for the malfunctioning FRU. Some service engineers are familiar with checking the log, and start their search there. If the service engineer recognizes the appropriate messages, the TBCB, CRCB and the Collimator are the starting point of the search. From experience the service engineer knows the fuses of these components are the first suspects. So, these are the first components that are checked. Then the TBCB, CRCB and Collimator themselves are examined. This can be done, because of various status LEDs, that give an indication of their health. If none of these seems to be the cause, all other components are sequentially checked (looking at the LEDs, cabling, etc.) for inconsistencies. Eventually, the service engineer will find out that CableB is not connected well or is broken. The latter can be detected by measurement. 2.3.1 Drawbacks The described process above shows that finding a simple broken cable takes much time. In the real case, there are even more cables, fuses and components. All of them must be checked, and this is time consuming. Interviews with experts and service engineers show that it takes approximately one hour to diagnose the system. If one of the more complex components (the components depicted on the right of Figure 2.2) are broken, and LEDs do not indicate malfunctioning, the identification of these as the wrongdoers takes much more time. In these situations, developers of the power supply example need to help, because they know more about the system. 2.4 Optimal Fault Diagnosis This section defines and clarifies the problem that this thesis addresses precisely. The former described the current approach to fault diagnosis at PMS. A better diagnostic approach can only be suggested if it is known which items make a fault diagnosis process good. If these items are known, it is possible to evaluate the current approach, and evaluate alternative approaches. Section 2.4.1 introduces the items that an ideal fault diagnosis would have. Section 2.4.2 presents the evaluation using the items of an ideal fault diagnosis process as criteria. The final subsection shows what items could possibly be introduced, or improved, in a new approach to fault diagnosis in order to achieve higher dependability. 2.4.1 Ideal Fault Diagnosis The ideal approach to fault diagnosis utilizes as much information as possible in the search for root causes of failures, in a way that optimizes dependable operation at minimum costs and risks. This applies to PMS as well as to all companies constructing embedded systems. In order to address this ideal approach as much as possible, items are identified that make a fault diagnosis approach ’perfect’. These items can be used to evaluate diagnostic approaches. Dash and Venkatasubramanian list some characteristics that a diagnostic system should ideally posses [9]. With this list as a starting point, and by interviews with PMS employees, it is derived that the following item are present in an ideal approach. 1. Accuracy. Accuracy is the extent to which a diagnosis produced by the diagnostic process agrees with reality. If a diagnosis is not accurate (inaccurate) there can be two situations: 15
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 27: 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 79 and 80:
Diagnosing the Beam Propeller Movem
Page 81 and 82:
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

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

Delete template?

Save as template?