Status merger for Bacnet proxy points

Bacnet proxy points are unique from proxy points in most other field bus drivers, because the BACnet protocol provides for native “abnormal status” of data objects. Niagara can learn about this from the “Status_Flags” property of a BACnet object.

Possible abnormal BACnet “Status_Flags” include the following:

IN_ALARM — appears as {alarm} in Niagara
FAULT — appears as {fault} in Niagara
OVERRIDDEN — appears as {overridden} in Niagara
OUT_OF_SERVICE — appears as {disabled} in Niagara

To get this native status, you do not have to create a proxy point expressly for the “statusFlags” of a BACnet object—however, this is handled differently in the Bacnet driver by NiagaraAX release level:

Starting in AX-3.2, for polled points, by default only the selected property is polled and reflected in the Read Value of the ProxyExt. However, you can include the polling of other data (including “statusFlags”), by adding to the facets of the point. See Facets usage to poll additional properties.
- If “statusFlags” is added to facets, a “status merger” with Niagara point status occurs—just as it does “automatically” for pre-AX-3.2 Bacnet proxy points.
- If “statusFlags” is not added to facets, no status merger occurs—only Niagara status is shown for the proxy point (e.g., if the BACnet object is “in_alarm”, it will likely show “ok” in Niagara).
Prior to AX-3.2, if you create a proxy point for any other property (typically, “presentValue” or” eventState”), “statusFlags” is also automatically polled. Values from both properties reflect in the Read Value of the ProxyExt. A “status merger” with Niagara point status occurs.
Starting in AX-3.7u1, default behavior of Bacnet proxy points using COV (not polling) changed, to now match polled point behavior for status. Before this change, by default, proxy points using COV included “Status_Flags” data, where a “status merger” was used. For related details, see Changes in COV statusFlags reporting.

Status merger operation

In the parent proxy point, any of the above “native” abnormal statuses are OR’ed with the equivalent Niagara-originated statuses, and merged with Niagara-only status flags, such as “stale,” “unackedAlarm,” etc. (see “About point status” and “How status flags are set” in the User Guide).

This is mentioned because it is possible to see a proxy point show a status (as one example) “disabled,” and yet it is enabled in Niagara (the source BACnet object is set to “Out of Service”). Or, you may encounter a variety of other combinations.

Note that the “Read Value” property of a point’s ProxyExt should only show the BACnet status, so it can be used to distinguish between Niagara and BACnet contributions to the status bit string. Also, consider the possibility of any independent alarm and fault parameters between the source BACnet object, and any possible NiagaraAX alarm extension on the proxy point.