ASHRAE Journal - November 2011 - B16

ured so that a temporary device may subscribe at a single point, i.e., a central Notiﬁcation Forwarder object, for receiving all notiﬁcations generated in the device or system. The Notiﬁcation Forwarder supports two ways by which Notiﬁcation Recipients are known. Enrollment of Notiﬁcation Recipients works in exactly the same way as it does in regular Notiﬁcation Class objects. Subscription is a new mechanism that has been added. It supports runtime subscriptions, as in Change Of Value (COV) reporting. The subscriptions are considered temporary and have a lifetime, after which the subscription is automatically dropped. This mechanism was added to support Notiﬁcation Recipients that connect at runtime (typically temporarily) and therefore, should not cause persistent conﬁguration changes.

Figure 4: Alert reporting.
Process Identiﬁer Initiating Device Identiﬁer Event Object Identiﬁer Time Stamp As deﬁned in the Notiﬁcation Class for the recipient. The Device object’s identiﬁer of the device in which the Alert Enrollment object resides. The Alert Enrollment object’s identiﬁer. The time of occurrence of the alert.

Stateless Alert Reporting

The Notiﬁcation Class referred to by the Alert Enrollment In the past, many manufacturers imNotiﬁcation Class object. plemented proprietary mechanisms to The priority as deﬁned in the Notiﬁcation Class for the report informational alerts. The standard Priority To-Normal transition. had no good way of generating such noEvent type ‘Extended’ always. Event Type tiﬁcations. The standard event notiﬁcaMessage text associated with the alert. Message Text tions are bound to an Event_State propThe value of the Alert Enrollment object’s Notify_Type erty, and transitions of the value of this Notify Type property. property are reported. With the alarming This ﬂag is cleared (FALSE) always. AckRequired revision, the new concept of stateless Event state Normal always. From State alert reporting has been introduced for Event state Normal always. To State providing informational alerts. This is a The ‘Extended’ option of BACnetNotiﬁcationParameters concept separate from Event State DeEvent Values is used. tection. Informational alerts are stateless { and not acknowledgeable. As an examThe identiﬁcation of the vendor that deﬁned the alert Vendor ID ple, an object may report that the equipnotiﬁcation. ment it represents needs maintenance. Numeric extended event type identiﬁer as per the Vendor ID. Extended Event Type The two major elements in alert reA sequence of primitive data types or property values. Parameters porting are: a new Alert Enrollment { object, and alert notification messagThe object identiﬁer of the Alert Source object. es. The Alert Enrollment object is the Alert Source Object Always ﬁrst in the ‘Parameters’ sequence. core element in the concept and acts as Optionally, a sequence of primitive data type values or the Event Source object for the alert {other parameters} property values. notifications (Figure 4). Alert notifi} cations are regular event notifications } of event type ‘Extended’, but applied in a particular way. The Alert Enrollment object contains Figure 5: Alert notification parameter details. all information required for managing information alerts from objects in the device. If a single Alert Multiple Alert Enrollment objects may be present in a device. Enrollment object is present in a device, then all informational In that case, the association of Alert Source objects with Alert alerts from all objects in the device ﬂow through that object. Enrollment objects is determined by the device, but is not net-

B16

B A C n e t ® To d a y & t h e S m a r t G r i d | A S u p p l e m e n t t o A S H R A E J o u r n a l

November 2011

ASHRAE Journal - November 2011

Table of Contents for the Digital Edition of ASHRAE Journal - November 2011