Newsroom

Article

The diagnostic that shows its work

A useful diagnosis is one another engineer can challenge: here is the evidence, here is the reasoning, and here is what remains unknown.

Millwright

A Millwright evidence board with live tags hung off a process drawing

At 02:13, a chilled-water pump trips on low suction pressure. The obvious answer is cavitation. It is also only a hypothesis. The same symptom can follow a closed isolation valve, a blocked strainer, a bad transmitter, or low level in the supply tank. Acting on the first plausible cause is how a quick diagnosis becomes a long outage.

A useful diagnostic must do more than name a fault. It should preserve the chain from observation to conclusion: which signals changed, in what order, what evidence rules alternatives in or out, and what the system could not verify.

Start with a sequence, not a summary

Alarm lists flatten an event into rows. Diagnosis depends on sequence.

For the pump trip, an investigation might establish that:

  • tank level had been falling for 40 minutes;
  • suction pressure became noisy before it fell;
  • motor current dropped after pressure, not before it;
  • the standby pump saw the same suction-pressure disturbance; and
  • no valve-position change was recorded.

That sequence makes an electrical fault less likely and a shared upstream restriction more likely. It still does not prove whether the restriction is a strainer, valve, or low supply. The distinction matters: the first conclusion can guide a safe inspection; the second would be an unsupported guess.

Millwright records each claim beside the trend, alarm, work order, or procedure that supports it. An engineer can open the cited source, change the time range, and disagree with the conclusion without recreating the entire investigation.

Unknown is an operationally useful result

Diagnostic software is often judged by answer rate. In a plant, that can be the wrong incentive. A system rewarded for always producing an answer will turn missing telemetry into confident prose.

There are common reasons to stop:

  • a critical point is stale or has been overridden;
  • two tags that should agree differ beyond their tolerances;
  • maintenance changed the asset configuration but not the model;
  • the relevant valve has no position feedback; or
  • the available history does not include a comparable operating state.

In those cases, the next useful step is a question: Is HV-204 physically open? Was the suction strainer cleaned during last week’s outage? Can an operator confirm the local tank gauge? A precise request for one missing observation is more valuable than a polished paragraph built around its absence.

Make the result reusable

Once reviewed, the investigation can travel with the work. The ticket retains the event window and cited evidence. If the crew confirms a blocked strainer, the final record can include the differential pressure, the inspection finding, and the action taken. The next time the pattern appears, another engineer has a comparison grounded in an actual repair rather than a vague note that says “pump issue resolved.”

That is the standard we use for a diagnostic: not whether it sounds convincing, but whether someone who was not present can inspect it, challenge it, and safely decide what to do next.