pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
5.7 Results of the Case Study<br />
Diagnosing the Beam Propeller Movement<br />
of the Frontal St<strong>and</strong><br />
• C3: 12 (POSITION_ERROR = true <strong>and</strong> e_pos = false)<br />
• C4: 1 (POSVAL_ERROR = true)<br />
• Unknown fault category: 1 (error is status).<br />
Table 5.12 shows the entropy gain after weighting for each fault category. For example, the<br />
entropy gain of the sensor set-up [I_mvr, I_to_motor, I_from_motor] is calculated by:<br />
H gain =<br />
16 ∗ 0.2945 + 7 ∗ 0.3729 + 12 ∗ 0.2711 + 1 ∗ 0.1883<br />
36<br />
= 0.2990 (5.6)<br />
The conclusion is that from the considered sensor set-ups, [I_mvr, I_to_motor, I_from_motor]<br />
has the highest entropy gain, thus leads to the highest increase in diagnostic accuracy. Note that the<br />
decision to choose a particular sensor set-up also depends on the costs of adding those specific sensors.<br />
An expert would be unable to order a list of sensor set-ups with respect to higher diagnostic<br />
performance. For example, it is very likely that an expert expects higher improve of accuracy from<br />
the sensor set-up [I_from_motor, Vact] than from sensor set-up [I_mvr, I_set], while this is the<br />
other way around. Ordering a list of sensor set-ups is especially complicating if one likes to consider<br />
all additional sensor set-ups that are possible.<br />
5.7 Results of the Case Study<br />
This section discusses why it is not possible to present the experimental results of the case study.<br />
The reason for this is as follows. The experimental methodology requires that for each fault scenario<br />
it is known what is broken. Unfortunately, for fault scenario’s S1 till S11 <strong>and</strong> S17 till S39 this is not<br />
possible 4 . These fault scenarios are extracted from the remote monitoring tools, <strong>and</strong> it is impossible<br />
to determine what components were really broken for those cases. Thus, it is impossible to calculate<br />
the accuracy of the MBD implementations, based on real-life fault scenarios.<br />
In order to still be able to calculate the accuracy of the MBD implementations, 5 faults are injected<br />
in the system in a test situation. This resulted in 5 error messages. Table 5.13 shows the<br />
observations, adjudged broken components, <strong>and</strong> the outcome of MBD-1 (or MBD-2), for these 5<br />
fault scenarios; S12 till S16. A value of 1 in column A of Table 5.13 means the fault scenario is accurately<br />
diagnosed. The vector that was used to denote the observations is (e_pos, control_speed,<br />
POSVAL_ERROR, POSITION_ERROR, SPEED_ERROR, CURRENT_ERROR).<br />
Using Formula 5.1, the accuracy of the MBD-1 <strong>and</strong> MBD-2 implementations over these 5 fault<br />
scenarios is calculated:<br />
A MBD−1 = A MBD−2 = 3 = 60% (5.7)<br />
5<br />
Of course, this result should be looked at with care. Only 5 fault scenarios could be used, <strong>and</strong><br />
these did not occur in a real case setting. If the set of fault scenarios would be representative for a<br />
large group of real-life fault scenarios, an accuracy of 60% could be interpreted as that the MBD<br />
engine produces the actual diagnosis as the first item in the list for 60% of the fault scenarios. For<br />
the other 40% of the fault scenarios, the actual broken component is in the list, but not as the first<br />
item. For example, the outcome of the LYDIA diagnostic engine for fault scenario S12 lists the<br />
actual broken component as the fourth item. And the outcome of the LYDIA diagnostic engine for<br />
fault scenario S16 lists the actual c<strong>and</strong>idate as the third item.<br />
4 Appendix B.4 lists all fault scenarios.<br />
66