Book a demo
Fault detection & diagnostics

An alarm tells you something changed.
It never tells you why.

Rule-based alarming is standard on a BMS, and on its own it produces a list that is expensive to read: working out what each line means takes time a site rarely has. Automated fault detection and diagnostics is the part that closes that gap — naming the fault, not the symptom.

The questions in order

Six things that have to be true before a diagnosis is worth reading.

Is the reading real?
Drift, stale values, out-of-range and flapping are detected before anything downstream trusts the point. A fault diagnosed from a dead sensor is worse than no diagnosis.
Is the alarm real?
A threshold crossed once is a spike. Confirmation across consecutive intervals, with a delay and severity that suit the asset, is what separates an event from noise.
What is actually failing?
The fault is named and traced through the equipment chain, so the diagnosis lands on the component at fault rather than the sensor that noticed.
How sure, and on what basis?
Candidate causes are ranked by likelihood with the evidence for each — so a diagnosis can be argued with instead of believed.
Was it right?
Confirmed, partially correct or incorrect on every diagnosis. The verdicts come from the engineers who know the plant, and they feed back.
Then what?
A confirmed diagnosis becomes a work order in the same product, carrying the evidence that raised it — nothing re-keyed into a second system.
On the screen

What lands in front of an engineer.

The finding

A named fault, its evidence, and what to do about it.

Root cause first, then the causes considered and why each was ranked where it was, then the action. An engineer can disagree with any part of it, because every part of it is shown.

beconixAI
An AI fault diagnosis showing root cause, ranked possible causes with their evidence, and recommended action
The fleet

If one asset has it, how many others do?

Search the estate for the same root cause rather than the same alarm text — including the assets still below their alarm threshold, which are the ones worth catching.

beconixAI
A fleet-wide search showing every asset across the estate sharing the same diagnosed root cause

Interface representative. Figures are illustrative demonstration data.

How it runs

Agents, in sequence, each one checkable.

Validation, confirmation, diagnosis and action are separate steps rather than one opaque model — so when a verdict looks wrong you can see which step produced it.

Intelligence on bad data is not intelligence — it is a confident guess. So the raw signal is cleaned first: drift, stale values, out-of-range readings and flapping are identified before anything is allowed to become an alarm.

Sudden driftStale valueOut of rangeFlapping
The point of it

A diagnosis nobody acts on is just a better-worded alarm.

Detection only pays for itself at the moment it becomes work — assigned, scheduled, done and verified. That is why fault detection and work management are one product here rather than two, with one asset registry underneath both.

And when the fix was supposed to save energy, measurement and verification is what decides whether it actually did.

  • Validated readings before anything is diagnosed from them
  • Alarms confirmed across intervals, not on a single spike
  • Root cause named and traced through the equipment chain
  • Causes ranked by likelihood, each with its evidence
  • Engineer verdicts fed back on every diagnosis
  • Fleet-wide search for the same cause across the estate
  • A work order raised in the same product, evidence attached

The list is not the problem. The reading of it is.

If your estate has more alarms than anyone can triage, the constraint is not detection. What changes the economics is arriving at the fault instead of arriving at the symptom.

Book a demoSee the whole platform