BACnet Status_Flags and Reliability Explained
A BACnet Present_Value is only as trustworthy as the status properties that travel with it, and the two that matter most are Status_Flags and Reliability. If you map a point's value but ignore its status, you can record a faulted sensor's last reading as if it were live data. This reference explains the four bits inside Status_Flags, what the Reliability enumeration adds, and why any serious integration reads them alongside every value.
BACnet Status_Flags and Reliability in one line: Status_Flags is a four-bit summary of an object's health - In_Alarm, Fault, Overridden, and Out_Of_Service - that tells a client at a glance whether a Present_Value can be trusted. The Reliability property adds detail on why a value is unreliable, enumerating causes such as no sensor, over range, under range, or open loop. Reading both alongside Present_Value is what separates a value you can act on from a number that may be stale or invalid.
The Four Bits Inside Status_Flags
Status_Flags packs four boolean flags into one property. The In_Alarm flag is set when the object's own alarming has determined it is in an alarm state - a temperature above its high limit, for instance. The Fault flag is set when the object cannot be trusted because something is wrong with the measurement itself, which is where Reliability provides the reason. The Overridden flag indicates the value has been forced locally at the device, outside normal control. The Out_Of_Service flag indicates Present_Value has been decoupled from the physical process for testing. Any of these being set changes how a client should treat the value.
The most important flag for data quality is Fault. When Fault is set, Present_Value should not be trusted as a live measurement - the sensor may be open, shorted, or out of range, and the number the object reports is not a reliable reflection of the process. A monitoring client that maps Present_Value but not the Fault flag will trend the faulted value as if it were good, which is exactly the kind of silent bad-data problem that erodes trust in a historian. Mapping Fault to a quality indicator on the tag is the fix.
Overridden and Out_Of_Service both mean the value is not under normal control, but for different reasons. Overridden means someone forced the point at the device, often with a physical hand-off-auto switch or a local override, so the commanded value from the control system is not what is in effect. Out_Of_Service means the object has been deliberately disconnected from its sensor or actuator for testing, so Present_Value is whatever was last written rather than a live reading. Both are legitimate operational states, but a client that ignores them can misread a manually forced point as an automatic one.
What Reliability Adds
Where Status_Flags says whether there is a fault, the Reliability property says what the fault is. It is an enumerated value with entries such as no-fault-detected, no-sensor, over-range, under-range, open-loop, shorted-loop, and unreliable-other, among others. When the Fault flag is set, reading Reliability turns a bare fault indication into a diagnosis: a no-sensor value points at a disconnected or failed sensor, while an over-range value points at a signal outside the object's configured limits. This is diagnostic information a client can log and act on rather than merely flagging that something is wrong.
Reliability is valuable even when it reads no-fault-detected, because that positive confirmation is what lets a client assert a value is good rather than merely assume it. A well-built integration reads Reliability alongside Present_Value and Status_Flags for the objects that matter, so a trend carries not just the value but the evidence that the value was valid at the time it was recorded. That evidence is what allows an operator to trust a historical point when reconstructing an event, rather than wondering whether an odd reading was real or a sensor fault nobody noticed.
The way Reliability and the Fault flag interact is worth stating plainly: the Fault flag is essentially the summary bit that is set whenever Reliability is anything other than no-fault-detected. So the two are consistent by design, and a client can use the cheap single Fault bit as a first-pass quality gate and read the fuller Reliability enumeration only when Fault is set and a diagnosis is wanted. That two-tier approach keeps routine polling lean while still capturing the reason for a fault when one occurs.
Frequently Asked Questions
What do the four BACnet Status_Flags mean?
In_Alarm means the object's alarming has placed it in an alarm state. Fault means the value cannot be trusted because the measurement itself is faulty. Overridden means the value has been forced locally at the device, outside normal control. Out_Of_Service means Present_Value has been decoupled from the physical sensor or actuator for testing. Any flag being set changes how a client should treat the accompanying Present_Value.
What is the difference between Status_Flags Fault and the Reliability property?
The Fault flag is a single bit that says whether the value is untrustworthy. The Reliability property is an enumeration that says why - no sensor, over range, under range, open loop, shorted loop, and so on. The Fault flag is set whenever Reliability is anything other than no-fault-detected, so a client can gate on the cheap Fault bit first and read the fuller Reliability value only when a diagnosis is needed.
Why should a SCADA map BACnet Status_Flags and not just Present_Value?
Because a Present_Value read without its status can record a faulted, overridden, or out-of-service point as if it were live data. Mapping the Fault flag to a tag quality indicator lets the monitoring system mark bad values rather than trend them silently, and mapping Overridden and Out_Of_Service tells operators when a point is not under normal control. Reading status alongside value is what makes the recorded history trustworthy.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.