Alarm reporting configuration

The BACnet driver supports intrinsic event reporting more commonly called alarming. Support is available for both client and server operations, which means that a station can both receive (and reroute) BACnet alarms from BACnet proxy points, and also send BACnet alarms from components that have been exported as BACnet objects.

Any station that is exporting control points to BACnet can also route BACnet alarms from those points to BACnet devices. A BacnetDestination component in the Alarming folder of the bacnet palette is used to specify a receiving BACnet client device.

Prerequisites for exporting alarms

Only Framework components in the station that are exported as BACnet objects can generate BACnet alarms, where alarming capability is intrinsic to that object. For example, a control point exposed as an analog input object must use an out-of-range algorithm provided by an OutOfRangeAlarmExt. Another alarm extension, such as the StatusAlarmExt, is not supported.

In general, only components exported as BACnet object types: Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Multistate Input, Multistate Output, or Multistate Value are good candidates for exporting alarms. In a station these include control points (often proxy points) and components from the kitControl module, at least those with a NullProxyExt. Calendar and Schedule components cannot export alarms.

A separate BacnetDestination component must be added under the station’s AlarmService for each remote BACnet client to which alarms need to be sent (one-to-one BacnetDestination to device). In this component, you specify the unique BACnet device identifier for this device, and possibly make other non-default configuration changes.

Restrictions on exporting alarms

Only one alarm extension is supported on a point configured for BACnet alarming (referencing an alarm classs linked to a BacnetDestination).

Each alarm class component that you link to a BacnetDestination component must be exported to BACnet, as a notification class object. Linked BacnetDestination components automatically appear as entries in the Recipient List of these notification class objects.

Unless the alarm classes you are using define escalation levels, alarms are not regenerated. If a BACnet device is down when the component sends an alarm, the driver does not save the alarm for retransmission. Of course, the station maintains a record of alarms in the alarm database.

Exposing fault out-of-range algorithms

As of Niagara 4.14, the analog input and analog, large analog, integer, and positive integer value BACnet descriptors enable reading and writing of the BACnet faultHighLimit and faultLowLimit properties when the fault out-of-range algorithm is used with the offnormal out-of-range algorithm on the underlying Niagara point.

 NOTE: On the server, the faultHighLimit and faultLowLimit properties are not visible on the descriptor but you can change their values on the underlying point's alarm extension. 
Figure 2.   Client view of server

As of Niagara 4.14, the fault properties are accessible to any BACnet client including a Niagara client through Config objects or BACnet virtuals.

Image