Y8.04.3Maintenance history for fault diagnosisdesignresearch

Records are the basis for later fault diagnosis

Aliases: service history · maintenance history · fault diagnosis record

What it is

Maintenance history for fault diagnosis preserves symptoms, the conditions under which they appeared, measurements taken, actions performed, parts replaced, and outcomes, so a later technician can reconstruct how a fault emerged and which hypotheses were already tested and how they turned out. A work order marked "completed" cannot supply this chain of evidence — it records that an action happened, not why it was chosen or whether it actually resolved the problem.

Why it happens

Intermittent faults often stop showing symptoms by the time a technician arrives, which forces diagnosis to rely on comparison across multiple occurrences and repairs rather than a single on-site inspection — this is the underlying reason maintenance history matters, not merely a record-keeping habit. If a record only keeps "which part was ultimately replaced," a later technician has no way to know which causes were already ruled out or which fixes were already tried and failed, and has to start troubleshooting from scratch — wasting not just time but potentially repeating an action already shown to be ineffective or even harmful. A structured timeline (symptom, condition, action, and outcome linked in sequence) supports pattern search and statistical comparison across cases, while free text preserves unexpected context that structured fields cannot hold — "an unrelated maintenance job had just been done" looks irrelevant but can matter. Either one alone noticeably reduces the value of history on reuse: structured data alone tends to miss key context, free text alone is hard to search and compare across cases.

Studying it

Have diagnosticians work through real or reproduced fault cases under different levels of history completeness — a full timeline, only the final outcome, or no history at all — and measure the quality of hypotheses generated, the number of repeated tests, time to root cause, and the rate of replacing the wrong part due to misleading history. A retrospective analysis of an existing maintenance database should also check whether missing records correlate with fault complexity — if the hardest-to-diagnose faults are exactly the ones with the least complete records (perhaps because the response was too chaotic to document in the moment), then any "historical pattern" summarized from that database carries a systematic selection bias and cannot be treated as a general rule.

Where it stops holding

Similar historical symptoms do not prove the current fault shares the same cause as a past one; reapplying a previously successful fix can produce anchoring, locking a diagnostician onto a plausible but wrong hypothesis too early and cutting off further investigation. Whether data comes from an automatic sensor or a manual entry, it needs a stated source, unit, and calibration status at the time of capture, or cross-time comparison will mistake the instrument's own measurement drift for a real change in operating conditions. History involving personal operating details or sensitive process parameters should be access-restricted on a need-to-know basis; "more complete history is always better" is not a reason to open it to everyone indiscriminately.

Applying it

  • Link symptom, condition at the time, evidence gathered, hypotheses proposed, actions taken, and final outcome in chronological order, explicitly marking which hypotheses were ruled out and which issues remain unresolved, rather than keeping only the last step's outcome.
  • Support retrieval by equipment lineage, fault-mode type, and similar operating conditions, while showing each retrieved record's configuration differences from the current asset, so cases from a different configuration are not applied as if they were the same situation.
  • How to check: run a drill with an unknown fault the diagnostician has never seen, comparing repeated-test count and speed of ruling out wrong hypotheses with and without history support, rather than relying on an indirect metric like history-search hit rate to judge the record system's value.

Related

  • Same group: Y8.04.1 Records should be made during work rather than reconstructed afterward · Y8.04.2 Entry cost determines record quality
  • Nearby: Y3.07 Trends and historical review · Y7.05 Accident investigation and organizational learning
  • Search terms: maintenance history · fault diagnosis · service record

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/Y8.04.3