Alert Deduplication Between BMS and CMMS

The integration demo always looks the same. A fault is forced on a plant item, an alarm appears in the building management system, and a work order materialises in the maintenance system a second later. Everyone agrees it is impressive. What the demo never shows is Saturday night, when a differential pressure switch on a filter starts hovering at its setpoint and toggles two hundred times before Monday, and the maintenance team arrives to a backlog that has been destroyed by a single loose contact.

The message up front: deduplication is not a filter you add later, it is part of the integration design, and the decision that governs everything else is the choice of deduplication key. Decide what makes two alerts the same thing, pick a time window that reflects how long the underlying condition realistically lasts, collapse repeats into one case with an occurrence count rather than discarding them, and keep every suppressed event visible somewhere. Get the key wrong in the generous direction and you drown the backlog. Get it wrong in the strict direction and you hide a genuine second fault inside an open case nobody is looking at.

1. Why one fault produces many alerts

Before designing the rule it helps to separate the four quite different things that all present as "too many alerts", because they need different treatment and a single rule handles none of them well.

• The identical repeat. The same point, in the same alarm state, re-reported. Some systems re-send an active alarm on a timer until it is acknowledged; some re-send on reconnection; some re-send because two collection paths were configured and nobody noticed. This is the easiest case and the most common.
• Flutter, also called chatter. A value sitting exactly on a threshold, crossing and recrossing. Each crossing is a legitimate alarm-and-clear pair as far as the system is concerned. One underlying condition, dozens or hundreds of state changes. This is what fills a weekend.
• The correlated cascade. One root cause expressing itself through many points. A chilled water pump stops, and within a minute you have a flow alarm, a differential pressure alarm, several zone temperature alarms and a plant enable fault. Every one of those alarms is true. They are not duplicates of each other in any literal sense, and collapsing them naively loses real information.
• The cross-system echo. The same physical condition arriving twice because two systems both report it: the building management system and a standalone metering or monitoring platform, or a head end and a gateway that were both configured to forward. Common after a project where two integrators worked in sequence.

Only the first two are duplicates in the strict sense. The third is a correlation problem and the fourth is a configuration problem that is usually better fixed at source than deduplicated downstream.

2. Where in the chain to do it

You have three places to put the logic, and the choice has consequences well beyond tidiness.

In practice the answer is usually more than one of them. Flutter is fixed at the point, in the BMS, because that is the only place the root condition exists. Repeat suppression and case grouping sit in the middleware or the maintenance system, because that is where the concept of an open case lives. Trying to solve flutter downstream is the most common design mistake here: you end up writing increasingly elaborate rules to paper over a sensor that needs a deadband.

3. The deduplication key: what makes two alerts the same

This is the whole design, compressed into one decision. Every incoming alert is reduced to a key, and two alerts sharing a key within the window are treated as one occurrence. The candidates:

• Source point identity. The strictest sensible key. In BACnet terms this is the device instance plus object type plus object instance, not the point name, for the reasons set out in BACnet objects, device instances and addressing. Names get edited; identifiers do not.
• Point identity plus alarm condition. Better, because a point can be in high alarm today and fault tomorrow, and those are different problems. Adding the condition stops a low-limit alarm being absorbed into an open high-limit case.
• Asset plus condition class. Looser, and usually what the maintenance side actually wants. Three points on the same air handling unit all reporting a cooling problem are, to a technician, one visit. This requires the point-to-asset mapping to exist and be trustworthy, which is its own discipline and the subject of BMS point-to-asset mapping.
• Asset alone. Too loose for most estates. It means a filter alarm and a fan fault on the same unit become one case, and the second one effectively disappears.

What I would recommend as a default: key on asset plus condition class for the work order, while retaining point identity plus condition on every individual occurrence recorded against that work order. You get one visit per real problem, and the technician can still see exactly which points fired and when. The two-level structure is what makes the looser key safe.

4. Choosing the time window

The window is the second half of the rule, and the instinct is to pick a round number and move on. A better approach is to derive it from what the condition means.

• Match the window to the realistic duration of the underlying condition, not to how often the alert arrives. A blocked filter persists for weeks, so repeats over days are the same problem. A space temperature excursion on a hot afternoon persists for hours. A communications dropout may persist for minutes. One window across all alert types is the thing to avoid.
• Prefer a window anchored to the case, not a fixed clock. "While an open case exists on this asset for this condition, attach the occurrence to it" is more useful than "within 24 hours", because it survives the case staying open for a week, and it automatically stops suppressing once the case is closed.
• Add a re-open rule. If the same key fires shortly after a case was closed, that is a failed repair, and it is one of the most valuable signals your estate produces. Re-open the original case or raise a linked one, and flag it. Silently creating a brand new unrelated case loses the fact that the first fix did not work.
• Separate the alarm from the clear. An alert that raises and clears within seconds, repeatedly, is flutter and should be handled as described below. An alert that raises and stays raised is a condition. Treating both with the same window produces either noise or blindness.

5. Handling flutter properly

Flutter deserves separate treatment because downstream deduplication handles it badly: each crossing is technically a new alarm instance, so a naive key sees a legitimate new event every time.

The correct fix is at the point, in the controls, and it is ordinary alarm engineering rather than anything exotic: a deadband so the alarm clears at a different value from the one that raised it, and an on-delay so a condition must persist before it is reported at all. Both are standard capabilities. Neither is usually configured, because the default is zero and nobody revisits it. The wider discipline this belongs to is alarm rationalisation, which sits with the commissioning work described in BMS commissioning, graphics and operator dashboards.

Where you cannot get the controls changed, which is common on a system under a restrictive service contract, the downstream mitigation is a state-change counter with a hold-down: count transitions per point per interval, and once the count passes a threshold, stop creating work orders for that point and instead raise a single different case, "point X is unstable", routed to whoever owns instrumentation rather than to the plant technician. That reframing matters. An unstable point is an instrumentation defect, not a plant fault, and sending it to the plant team wastes the visit.

6. Cascades, which are correlation rather than duplication

When a pump stops and nine alarms follow, deduplication is the wrong tool. These are distinct conditions with a common cause, and the useful operation is to group them under a parent rather than to collapse them into one.

A practical approach that does not require anything clever:

• Define parent-child relationships from the asset hierarchy you already have. If a plant item is the parent of the zones it serves, an alarm on the parent within a short window before child alarms makes the children candidates for grouping. This is one of the concrete returns on having a real asset hierarchy rather than a flat list.
• Group, do not suppress. One work order for the parent, with the child alarms attached as evidence. The technician sees the whole picture. If the parent turns out not to be the cause, the children are all still there.
• Use a short correlation window, matched to how fast the physical effect actually propagates. Zone temperatures do not respond to a pump stopping in ten seconds, so a window that is too short misses the relationship entirely and one that is too long sweeps in unrelated events.
• Treat communications loss as a special parent. When a controller goes offline, every point behind it may alarm or go stale at once. That is one event, not forty, and it belongs in the playbook described in BMS connectivity loss.

7. The cross-system echo

Where the same condition arrives from two sources, resist the temptation to deduplicate it. Find out why there are two sources.

The usual causes are a metering or monitoring platform added alongside the building management system with overlapping scope, a gateway left forwarding after a head end was given a direct connection, or two integrators each configuring their own path during a phased project. In every one of those cases the correct answer is to decide which source is authoritative for that condition and turn the other off, because two live paths will drift: they will disagree on timing, on thresholds, and eventually on whether the condition exists at all. A deduplication rule that silently hides the disagreement removes your only clue that the configuration is wrong.

If both paths genuinely must stay, record the source on every event and make the deduplication explicit and visible, so that a disagreement between sources surfaces as a finding rather than being quietly resolved in favour of whichever arrived first.

8. Measuring whether the rule is right

Deduplication is tuned, not set. These are the measures I would put on a monthly review, all of which come free once suppressed occurrences are retained:

9. A sequence that works

Deduplication is usually retrofitted to an integration that is already live and already generating complaints, which constrains the order of work.

• Measure before changing anything. A fortnight of raw event counts per point and per asset. Almost always a small number of points dominate, and knowing which ones changes what you build.
• Fix the top offenders at source first. Deadbands and on-delays on the handful of points producing most of the volume will often remove the majority of the problem before any rule is written. Cheaper and more correct than any downstream logic.
• Introduce case grouping with occurrence counting. One case per asset per condition class, occurrences attached. This is the structural change and it is where most of the benefit is.
• Add the re-open rule. Cheap, and it immediately starts producing the failed-repair signal.
• Add cascade grouping last, if at all. It needs a trustworthy asset hierarchy and it benefits a smaller set of situations. Many estates never need it.
• Review monthly for the first quarter, then quarterly. The rule that fits a building in January will not fit it in July, because the alarms a building generates are seasonal.

One thing to settle before any of this: who owns the rule. Deduplication logic sits between two systems owned by different parties and tends to become nobody's, at which point it stops being tuned and starts being worked around. Name the owner before the first rule is written rather than after the first argument, and give them the severity and escalation framework in alarm severity and escalation design to work from.

The idea to walk away with

Deduplication is a data modelling decision dressed up as a noise problem. The question is not "how do we get fewer work orders", it is "what is the unit of work here", and once you answer that properly the rule writes itself. One case per real problem, every occurrence recorded against it, the count visible, nothing discarded.

Design it in at integration time rather than bolting it on after the first bad weekend. It costs very little at design stage and it is the difference between a maintenance team that trusts the alerts and one that has learned to ignore them, which is a far more expensive condition to reverse than to prevent.

Final thoughts

If you already have the problem, the single most useful hour is spent counting rather than designing: raw alert volumes per point for the last fortnight, sorted. In most estates a handful of points produce most of the noise, and several of them turn out to be instruments that have been failing quietly for months. That list usually makes the case for the work, identifies the real defects, and tells you how loose or tight the eventual rule needs to be, all at once.

Related reading: Converting repeated BMS faults into one CMMS case, Alarm severity and escalation design, The alert-to-work-order audit trail, IoT integration with CMMS, BMS and CAFM integration architecture, CMMS work order types.