What to Do When a BMS Fault Clears Before a Technician Arrives

Intermittent faults are the most expensive category of maintenance work and the least well handled by maintenance systems, because the system is built around a model where a problem exists, is attended, and is fixed. When the problem has gone by the time someone arrives, every field in that model is awkward to fill in, and the path of least resistance is to close the record with nothing useful in it. Do that a dozen times and you have paid for a dozen visits and learned nothing at all.

The message up front: a condition that cleared on its own is not a false alarm and should never be closed as one. It needs its own disposition, distinct from fixed and from no fault found, that records what the data showed at the time and either sets a watch or links the event to an existing case. The critical step happens automatically, before anyone attends: capture the surrounding data at the moment of clearing, because that window is the only evidence that will ever exist, and it is gone within days under a normal retention policy.

1. Why "no fault found" is the worst available answer

It is the honest answer from the technician's point of view, and it is still the wrong thing to record, for four reasons.

• It asserts something untrue. A fault was found, by the building system, with a timestamp and a value. It was not found by the person who attended later. Those are different statements and the record should say the second, not the first.
• It terminates the thread. A record closed as nothing wrong does not join to the next occurrence, so the pattern never forms. The mechanism that would otherwise catch it is described in converting repeated BMS faults into one CMMS case, and that mechanism needs each occurrence to be recorded as an occurrence.
• It poisons the alarm. Enough no-fault-found outcomes on one alarm and somebody will propose removing it. Occasionally that is right. More often the alarm is correct and the response model is wrong.
• It hides genuinely intermittent failures, which are both common and, in the end, expensive, because they tend to resolve into loose connections, marginal components and control instability. Those are cheap to fix once identified and costly to keep attending.

What to record instead is a separate disposition such as condition cleared before attendance, with the evidence attached. Any structured coding scheme can carry it; the fit with problem, cause and action coding is discussed in failure codes.

2. The reasons a fault clears on its own

They are not equivalent and they call for different responses, which is the main argument for not collapsing them into one outcome.

The fourth row is worth dwelling on, because dispatching a plant technician to an instrumentation problem is the single most common way these visits get wasted, and the data usually distinguishes the two clearly if anyone looks before dispatching.

3. Capture the evidence automatically, at the moment it clears

This is the part that has to be built in advance, because by the time a human is involved the opportunity has passed.

When an alarm clears on a point that generated a work order, the integration should automatically attach a snapshot to that record. What to include:

• The alarming point's trend across a window either side of the event, at the finest resolution available. The shape of the curve is what distinguishes a gradual excursion from an abrupt one, and that distinction drives the whole diagnosis above.
• Related points on the same asset, over the same window: commands and statuses, setpoints, mode, enable states. A fault that coincides exactly with a mode change is explained by the mode change.
• The status and quality flags at the time, including whether the object was out of service. A value from an out-of-service object is simulated, and the mechanics of that are in BACnet objects, device instances and addressing.
• Duration and exact clear time, which the audit trail should already be capturing as described in the alert-to-work-order audit trail.
• Whether anybody acknowledged or commanded anything in the interval, from the operator log. This is how you distinguish "cleared itself" from "somebody reset it", and the two look identical without it.
• Prior occurrences of the same condition on the same asset, with their dates. Three dates on the record changes how the technician approaches the visit.

4. The decision: cancel, attend, or watch

Once the condition has cleared, somebody has to decide what happens to the job that is already in flight. Three legitimate answers, and the choice should be a rule rather than a judgement call made by whoever answers the phone.

• Stand down and record. Appropriate where the data shows a genuine passing condition with an explanation, the asset is not critical, and there is no history. The record is still an occurrence, not a cancellation. Nobody travels.
• Attend anyway. Appropriate where the asset is critical, the pattern suggests an intermittent physical fault, or the clearing is unexplained. The visit's purpose changes from repair to inspection: look for the loose, the marginal and the hot, rather than for the fault that is no longer there. Say that explicitly on the job, because a technician sent to fix nothing will find nothing.
• Convert to a watch. Appropriate for most intermittent cases. No visit now; instead a monitoring disposition with a defined trigger for action.

Criticality is the main input to that choice, and it should come from the classification rather than from the caller's instinct, which is what asset criticality classification exists to provide.

5. The watch, and how to make it mean something

A watch that is only an intention is the same as closing the job. To be real it needs four things:

• A defined trigger. Stated in advance: a number of recurrences, a recurrence within a period, a duration exceeded, or any occurrence during a critical window. Written on the record, not held in someone's head.
• An automatic escalation when the trigger is met, which raises work rather than a notification somebody may miss. A watch that depends on a human noticing the pattern is not a watch.
• An expiry. If the trigger has not been met within a defined period, the watch closes with a quiet-period note. Watches without expiry accumulate until nobody reads the list.
• A named owner. The same requirement as for any persistent record, and the one most often skipped.

The natural home for a watch is the case layer rather than the work order, because a case is designed to persist across occurrences while a work order is not. Where no case layer exists, a watch tends to become an open work order that ages badly and distorts backlog reporting, which is visible in backlog and downtime tracking and is a reasonable argument for building the case layer first.

6. When it is the instrument rather than the plant

A disproportionate share of self-clearing faults are instrumentation defects, and they have a recognisable signature in the captured data: values that jump rather than move, readings that sit at a range limit, several points behind one controller behaving together, or gaps where data should be.

The important workflow consequence is that these should be routed differently. An intermittent reading from a sensor is work for whoever maintains instrumentation and controls, which on many estates is a different party under a different contract from the plant maintainer. Sending it to the plant team produces a visit, an inspection of healthy equipment, and a no-fault-found outcome, which is exactly the loop this article exists to break.

Practically, that means the triage rule should inspect the evidence snapshot before dispatch, and the field device failure modes worth recognising are catalogued in BMS points lists and field devices. Where the controls party is the only one who can investigate, the scope and cost of that sit under the arrangement discussed in BMS service contracts.

7. What to record so the next occurrence is useful

The whole value of handling one self-clearing fault well is realised at the third or fourth. That only works if the record is written for a reader who was not there.

8. Measuring it

• Share of BMS-originated work orders where the condition cleared before attendance. The headline. A rising share usually means thresholds or delays need review, not that the building is deteriorating.
• The same, by alarm type. A small number of alarm types will dominate, and those are candidates for an on-delay at the point rather than for a better response process.
• Travel time spent on cleared conditions. Converts the problem into a number that justifies fixing it.
• Watches that converted to real findings. The measure that tells you whether the watch mechanism is earning its place.
• Recurrence after a stand-down. High recurrence means the stand-down rule is too generous.

Where a single alarm type keeps producing cleared conditions, the fix is usually a delay or deadband at the point rather than anything downstream, which is the same conclusion reached from a different direction in alert deduplication between BMS and CMMS.

The idea to walk away with

The building saw something. That is a fact with a timestamp, and it does not stop being a fact because a person arrived later and saw nothing. Design the workflow around that asymmetry: a disposition that records what happened rather than what was found, evidence captured automatically at the moment of clearing, and a watch with a real trigger instead of an intention.

Of those, the automatic evidence capture is the one to build first. Everything else is process you can agree in a meeting. The data window either side of the clearing is the only thing you cannot recover later, and it is the thing that eventually names the cause.

Final thoughts

Run one query against last year's reactive work: jobs closed with no fault found, no parts and little labour, grouped by asset. In most estates a handful of assets dominate, and those are not assets without problems, they are assets whose problems nobody has been present for.

That list is the business case and the starting point at the same time. Put a proper watch on the top five, with evidence capture turned on, and within a few months you will usually know what three of them are. The others will need somebody standing in the plant room at the wrong time of night, which is the honest answer for a genuinely rare intermittent fault and always has been.

Related reading: Repeated faults into one case, The alert-to-work-order audit trail, BMS connectivity loss playbook, BMS data retention policy, Failure codes: problem, cause, action, BMS points lists and field devices.