BACnet Data Quality Flags: Missing, Bad and Out-of-Range Values

There is a free quality signal sitting in every BACnet object and it is discarded by most integrations before it ever reaches a database. The object does not just hold a value; it holds a set of properties describing whether that value should be believed. Reading the number and ignoring the rest is the single cheapest data quality mistake available, and it is nearly universal.

The message up front: capture what the device already tells you, add the checks it cannot make, and then flag rather than discard. Three categories of problem need separating because they have different owners: a communications fault, where no current value exists; an invalid value, where the device knows something is wrong; and an implausible value, where the device is content and physics is not. Collapse them into one "bad data" bucket and you will route every one of them to the wrong person.

1. What the device already tells you

Alongside the present value, a BACnet object carries properties describing its own condition. The full object model is in BACnet objects, device instances and addressing; these are the ones that matter for quality.

• Status flags. A small set covering whether the object is in alarm, in fault, overridden, or out of service. Reading a value without them means you cannot distinguish a good reading from a faulted one.
• Reliability. Why the object believes its value may be unreliable: open circuit, shorted, over range, under range, communications failure, and others depending on the device. This is the most informative property available and the most consistently ignored.
• Out of service. When set, the object is decoupled from the physical world and its value is being supplied manually, usually for testing. A plausible number from an out-of-service object is pure fiction, and the flag is the only way to know.
• Overridden. Indicates somebody has intervened. Not necessarily bad, always worth recording.

None of this costs extra network traffic worth mentioning, because the properties are read alongside the value. The reason they are discarded is almost always that the integration was built around a single-column model and nobody asked for more.

2. Three categories that need separating

The last two rows are the hard part, because a quality rule cannot reliably tell an implausible reading from an extreme real one. That is an argument for flagging rather than filtering, which is section 5.

3. How to store it

• Keep the raw value always. Even where you believe it is wrong. A suppressed row cannot be re-examined when the rule turns out to be wrong.
• A quality column per reading, from a controlled vocabulary rather than free text, so it can be filtered on.
• Record the source of the flag. Device-reported or derived by your own rule. Those carry very different weight and should not look identical later.
• Store the device properties as received, not just your interpretation of them, so a later analysis can apply a different interpretation.
• Never overwrite a value with a corrected one in place. A correction goes in its own field with the method recorded, which is the same discipline as in energy meter reset and rollover.

4. The checks the device cannot make

A device knows about itself. It does not know what the value ought to be, so these rules are yours.

• Range plausibility per point type. Not the alarm limit, which is about operations, but the physically possible band. A space temperature outside any habitable range is a sensor problem whatever the alarm thresholds say.
• Rate of change. A quantity with thermal inertia that moves faster than physics allows has a data problem rather than a plant problem.
• Stale value detection. A reading that has not moved at all while the associated plant is running. The classic failed-sensor signature, described in BMS points lists and field devices.
• Cross-point consistency. Related points that must bear a relationship to each other: a mixed temperature between its inputs, a flow consistent with a drive speed, a status consistent with a command. Disagreement means one of them is lying.
• Arrival-interval conformance. Readings arriving faster or slower than the configured rate, which indicates a collection problem rather than a sensor one.
• Exactly-at-limit values. A reading sitting precisely at a range boundary is often a saturated or disconnected input rather than a measurement.

The thresholds for all of these come from the design and the equipment, not from a general rule, and they belong recorded against the point in the register described in the BMS point dictionary.

5. Flag, do not filter

The tempting design drops bad readings at ingestion so that downstream consumers only ever see clean data. It is wrong for three reasons.

• You cannot audit a rule you applied destructively. When somebody asks whether the rule is too aggressive, the evidence has gone.
• A gap is ambiguous. Removed-as-bad looks identical to never-collected, which means every later investigation has to reconstruct which it was.
• Extreme real values get filtered. The reading most likely to be rejected as implausible is the one from the genuine incident, which is precisely the reading you will want.

The alternative is cheap: keep everything, flag it, and let each consumer decide. Reporting excludes flagged rows by an explicit rule you can state. Analytics can choose differently. An investigation sees everything.

6. What consumers should do with the flags

• Alerting should evaluate only trusted readings, and raise a separate data quality alert for the rest, routed to whoever owns instrumentation rather than to the plant team. Mixing the two is why energy and condition alerting gets switched off.
• Reports should state their exclusion rule and the volume excluded. A total computed from ninety percent of the data is fine if it says so.
• Charts should show flagged periods rather than hiding them, so a reader can see that a flat line is missing data and not a steady condition.
• Aggregates must exclude flagged rows before averaging, or one faulted sensor pulls a whole period.
• Analytics and fault detection need the flags most of all, because an anomaly model trained on faulted data learns the fault. This is the prerequisite behind anomaly detection data readiness.

7. Retrofitting this onto an existing integration

• Find out whether the properties are even being read. Usually they are not, and adding them is a configuration change rather than a redesign.
• Add the quality column before the rules. Populate it with device-reported status first, which needs no thresholds and immediately finds the out-of-service points.
• Run the rules in report-only mode first. Count what they would flag, for a month, before anything acts on them. This is where you discover whether your plausibility bands are right.
• Start with the points that feed something. Alarming points, analytics inputs, energy meters. Everything else can wait.
• Expect an uncomfortable first result. The initial count of suspect points is usually higher than anyone expects, and that number is the finding rather than a reason to loosen the rules.

The idea to walk away with

The device already knows more than you are storing. Capturing status, reliability and out-of-service costs nothing and converts an entire class of silent failure into something visible.

Then separate communications faults from invalid values from implausible ones, because they have different owners and sending them all to the same person wastes most of the visits. And flag rather than filter, because the reading your rule is most likely to reject is the one from the incident you will later need to explain.

Final thoughts

One query is worth running today if you capture the properties at all: how many points are currently reporting out of service, and for how long.

In an estate that has never looked, the answer is rarely zero, and each one is a value somebody somewhere is treating as a measurement. If you do not capture the property, that query cannot be run, which is itself the answer to whether this is worth doing.

Related reading: BACnet objects and addressing, BMS points lists and field devices, BMS data completeness KPIs, BMS point dictionary, Sensor units and scaling, Connectivity loss playbook.