The Fault Won't Happen While You're There (Decision Tree)
Why this matters
The customer swears it fails, and while you stand there it runs flawless. Correlating the fault to a pattern is a start, but a pattern is not a diagnosis you can act on. To actually find and fix an intermittent, you usually have to see it happen, which means making it happen: recreating the condition that triggers it, or engineering a way to catch it when it does. This is the difference between "it probably does it when it gets hot" and "I made it get hot, watched it fail, and found the part." Waiting passively for a fault to cooperate wastes visits. Building the condition on purpose is the skill.
Start here: name the condition it needs
A fault that hides while you watch is waiting on a condition that is not present right now. Your first job is to name that condition, because you cannot recreate what you have not identified. Interview and pattern point you at it: when does it fail, and what is different then versus now. The answer falls into a small number of buckets.
If recreating the condition could recreate a hazard (heat, pressure, electrical stress, a combustion issue), plan the safety before you build the condition. Force the fault under control, with a way to shut it down fast, not by pushing a system blindly until something lets go.
Identify the missing condition, then build it
Match the pattern to the condition, then apply the condition on demand instead of waiting for nature to supply it.
| The fault needs | How to recreate it on the spot |
|---|---|
| Heat (fails when hot) | Run it to temperature, block cooling briefly if safe, or warm a suspect component with a heat source to find a thermally sensitive part |
| Cold (fails when cold) | Chill a suspect part with cold spray to find one that fails at low temperature |
| Full load or demand | Apply the real load, or a test load, so it works as hard as it does in service |
| Runtime or soak | Let it run through its full cycle and past it; short bench runs miss a fault that needs time to develop |
| Moisture or humidity | Wet the suspect area or run a controlled water test on the path the weather would take |
| A weather or environmental event | Simulate what the event does: a hose for wind-driven rain, sun load, a temperature swing; wait for the event only if it cannot be simulated |
| Vibration or motion | Wiggle-test and tap-test connections, or run it under the motion it sees in service |
The heat and cold tricks are worth their weight: spot-heating or spot-chilling one component at a time is how you turn "it fails sometime when the temperature moves" into "this exact part fails at temperature."
When you cannot recreate it, engineer the catch
Some conditions will not come on command: a specific weather event, an electrical disturbance from the grid, a rare coincidence of loads. Then you set the fault up to record itself.
- Leave a data logger on the suspect signal so the next event is timestamped and captured without you present.
- Return at the right time if the condition is predictable (the hottest part of the day, a tide, a scheduled load) rather than at a convenient one.
- Instrument the customer with a short, specific list of what to capture the instant it happens.
Waiting is a fallback, not the first move. Recreate what you can; catch what you cannot.
Confirm you reproduced the real fault
Forcing a condition can produce a failure that is not the customer's failure. Before you diagnose from what you induced, check that the symptom you triggered matches the reported one in kind, not just that you broke something.
- Does the failure you produced look and behave like what the customer described?
- Did it take a plausible version of the real-world condition, or did you have to push far past anything the equipment sees in service?
- If you had to overstress it to fail it, you may have found a different, weaker limit than the actual fault. Recheck the pattern.
The judgment to bank: an intermittent that will not perform for you is an invitation to build its trigger, not a reason to guess. Name the condition, recreate it under control, and only fall back to logging and waiting for the conditions you truly cannot make.
Recap
- Name the absent condition the fault needs before trying to reproduce anything.
- Plan the safety when recreating a hazardous condition.
- Build the condition on demand (heat, cold, load, runtime, moisture, simulated event) rather than waiting for it.
- For conditions you cannot make, log or return at the right time, and always confirm the failure you induced is the real one.
References
- Trade-standard practice on fault reproduction using controlled thermal, load, and moisture stress
- Manufacturer documentation on operating limits and safe test conditions
- See related: You Only Get One Visit to Diagnose an Intermittent; The Static Reading Is Fine but It Fails Under Load