pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
pdf download - Software and Computer Technology - TU Delft
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
State-of-the-Practice<br />
Fault diagnosis at PMS<br />
2.4 Optimal Fault Diagnosis<br />
2.4.2 Evaluation Current Approach<br />
Throughout the years the diagnostic performance steadily became suboptimal. When the first<br />
Cardio-Vascular systems were placed in hospitals, the systems could easily be diagnosed <strong>and</strong> repaired<br />
manually. There was only one power supply, a couple of cables, <strong>and</strong> the more complex<br />
components could be manually measured quite easily. Almost all functionality was implemented<br />
by hardware. Therefore, analog measuring was the most efficient way for diagnosing these systems.<br />
The skills <strong>and</strong> knowledge of service engineers perfectly fitted the diagnostic tasks. However, ever<br />
since, various trends have changed the situation:<br />
1. Increased complexity, caused by evolved techniques <strong>and</strong> additional functionality.<br />
2. a shift from a hardware-centric to software-centric embedded system.<br />
3. An increased number of third party components.<br />
These trends have decreased the presence of the items that an ideal approach should have. These<br />
items are used as criteria to evaluate the current approach, as follows:<br />
• Accuracy. The current process <strong>and</strong> available tools do not allow the determination of how<br />
accurate the diagnosis is. For this, it should be known if a replacement of the diagnosed<br />
FRU recovered the failure, <strong>and</strong> this information is not available. The only way to estimate the<br />
accuracy, is to examine job sheets for reoccurrence of problems, or to interview troubleshooters<br />
for their experiences. Both sources make it plausible that today’s diagnostic process is<br />
not very accurate, unless failures are known <strong>and</strong> very well understood. Unfortunately, it is<br />
impossible to quantify this attribute with the current techniques.<br />
• Speed of diagnosis. The Speed of diagnosis can be measured by recording the time between<br />
the moment that a failure occurs <strong>and</strong> the moment that a troubleshooter isolates the root cause<br />
of that failure. In the current situation it can be recorded per failure, by interviewing operators<br />
<strong>and</strong> examining job sheets. The period is several days in case of a mainstream problem. Otherwise<br />
the problem has to be escalated through one or more of the help desks (recall Figure<br />
2.3) <strong>and</strong> could take weeks, if not months.<br />
• Low Uncertainty. The uncertainty of today’s diagnoses is, like the accuracy, hard to determine.<br />
Again, only job sheets <strong>and</strong> interviews can give some insights. These indicate that<br />
the certainty of service engineer is disputable in many cases. However, it is not possible to<br />
quantify this because the job sheets do not provide a list of possible diagnoses.<br />
• Context Independency. Section 2.3.1 described the actions that employees perform for solving<br />
a failure of the power supply. It shows that, nowadays, many diagnostic knowledge depends<br />
on current employees. Therefore, reliance on many people is seen as a drawback of<br />
the current approach. It indicates strong environmental influences on the diagnostic process;<br />
if people change jobs, the diagnostic capabilities within the organization degrades. Consequently,<br />
the current practice is not very independent of its environment.<br />
• Development Costs. The development costs of a diagnostic process that aims at maintaining<br />
complex systems, such as the Philips Cardio-Vascular X-Ray System, are expected to be very<br />
high, <strong>and</strong> so they are. So, any qualification is always relative to other approaches. The exact<br />
development costs are not examined, but it is known that the development costs typically<br />
outweigh the runtime costs.<br />
17