12.1 Analog Input Object
COV_Increment REAL O2 This property is required if the object supports COV reporting.
12.2 Analog Input Object Type
12.2.16 COV_Increment
This property, of type REAL, shall specify the minimum change in Present_Value that will cause a COVNotification to be issued to subscriber COV-clients. This property is required if COV reporting is supported by this object.
12.3 Analog Output Object Type
COV_Increment REAL O2 This property is required if the object supports COV reporting.
12.3.17 COV_Increment
This property, of type REAL, shall specify the minimum change in Present_Value that will cause a COVNotification to be issued to subscriber COV-clients. This property is required if COV reporting is supported by this object.
12.4 Analog Value Object Type
COV_Increment This property is required if the object supports COV reporting.
12.4.13 COV_Increment
This property, of type REAL, shall specify the minimum change in Present_Value that will cause a COVNotification to be issued to subscriber COV-clients. This property is required if COV reporting is supported by this object.
12.11 Device Object Type
Active_COV_Subscriptions List of BACnetCOVSubscription O9
This property is required if the device supports execution of either the SubscribeCOV or SubscribeCOVProperty service.
12.11.38 Active_COV_Subscriptions
The Active_COV_Subscriptions property is a List of BACnetCOVSubscription, each of which consists of a Recipient, a Monitored Property Reference, an Issue Confirmed Notifications flag, a Time Remaining value and an optional COV Increment. This property provides a network-visible indication of those COV subscriptions that are active at any given time. Whenever a COV Subscription is created with the SubscribeCOV or SubscribeCOVProperty service, a new entry is added to the Active_COV_Subscriptions list. Similarly, whenever a COV Subscription is terminated, the corresponding entry shall be removed from the Active_COV_Subscriptions list.
This property is required if the device supports execution of either SubscribeCOV or SubscribeCOVProperty service.
12.17 Loop Object Type
COV_Increment This property is required if the object supports COV reporting.
12.17.29 COV_Increment
This property, of type REAL, shall specify the minimum change in Present_Value that will cause a COVNotification to be issued to subscriber COV-clients. This property is required if COV reporting is supported by this object.
12.23 Pulse Converter Object Type
COV_Increment REAL
These properties are required if the object supports COV reporting.
COV_Period Unsigned
These properties are required if the object supports COV reporting.
12.23.18 COV_Increment
This property, of type REAL, shall specify the minimum change in Present_Value that will cause a COV notification to be issued to subscriber COV-clients. This property is required if COV reporting is supported by this object.
12.23.19 COV_Period
The COV_Period property, of type Unsigned, shall indicate the amount of time in seconds between the periodic COV notifications performed by this object. This property is required if COV reporting is supported by this object.
12.25 Trend Log Object Type
The referenced object may reside in the same device as the Trend Log object or in an external device. The referenced property’s value may be recorded upon COV subscription or periodic poll. Where status flags are available (such as when the COVNotification or ReadPropertyMultiple services are used), they are also acquired and saved with the data
COV_Resubscription_Interval unsigned Optional
Client_COV_Increment BACnetClientCOV Optional
12.25.9 Log_Interval
This property, of type Unsigned, specifies the periodic interval in hundredths of seconds for which the referenced property is to be logged. If this property has the value zero then the Trend Log shall issue COV subscriptions for the referenced property. The value of this property must be non-zero if COV_Resubscription_Interval is not present. This property must be writable if present.
12.25.10 COV_Resubscription_Interval
If the Trend Log is acquiring data from a remote device by COV subscription, this property, of type Unsigned, specifies the number of seconds between COV resubscriptions, provided that COV subscription is in effect. SubscribeCOV requests shall specify twice this lifetime for the subscription and shall specify the issuance of confirmed notifications. If COV subscriptions are in effect, the first COV subscription is issued when the Trend Log object begins operation or when Log_Enable becomes TRUE. If present, the value of this property must be non-zero. If this property is not present, then COV subscription shall not be attempted.
12.25.11 Client_COV_Increment
If the Trend Log is acquiring COV data, this property, of type BACnetClientCOV, specifies the increment to be used in determining that a change of value has occurred. If the referenced object and property supports COV reporting according to 13.1, this property may have the value NULL; in this case change of value is determined by the criteria of 13.1.
12.25.22 Event_Enable
This property, of type BACnetEventTransitionBits, shall convey three flags that separately enable and disable reporting of TO-FAULT and TO-NORMAL events. In the context of Trend Log objects, the value of the Records_Since_Notification property becoming equal to or greater than the value of the Notification_Threshold property shall cause a TO-NORMAL transition. The failure of an attempted COV subscription shall cause a TO-FAULT state transition. The TO-NORMAL transition must be enabled when intrinsic reporting is to be used; this shall be set by default. This property is required if intrinsic reporting is supported by this object.
13 ALARM AND EVENT SERVICES
This clause describes the conceptual approach and application services used in BACnet to manage communication related to events. Object types relating to event management are defined in Clause 12. In general, “events” are changes of value of certain properties of certain objects, or internal status changes, that meet predetermined criteria. There are three mechanisms provided in BACnet for managing events: change of value reporting, intrinsic reporting, and algorithmic change reporting.
Change of value (COV) reporting allows a COV-client to subscribe with a COV-server, on a permanent or temporary basis, to receive reports of some changes of value of some referenced property based on fixed criteria. Certain BACnet standard objects may optionally support COV reporting. If a standard object provides COV reporting, then changes of value of specific properties of the object, in some cases based on programmable increments, trigger COV notifications to be sent to one or more subscriber clients. Typically, COV notifications are sent to supervisory programs in COV-client devices or to operators or logging devices. Proprietary objects may support COV reporting at the implementor’s option.
Intrinsic reporting allows a BACnet device to provide one or more event sources, intrinsic to the device, that generate event notifications that may be directed to one or more destinations. Certain BACnet standard objects may optionally support intrinsic reporting by supporting optional properties that define the type of event to be generated and options for handling and routing of the notifications. Internal status changes and alarms may also use intrinsic reporting to generate diagnostic notifications. Proprietary objects may support intrinsic reporting at the implementor’s option.
Algorithmic change reporting allows a notification-client to subscribe with a notification-server to receive reports of changes of value of any property of any object on the basis of predetermined, and network-visible, criteria. Any of the standardized algorithms described in Clause 13.3 may be used to establish criteria for change reporting. Once established, occurrences of change may be reported to one or more destinations based on further criteria. Algorithmic change reporting differs from intrinsic reporting in that Event Enrollment objects are used to determine the event condition(s).
Intrinsic and algorithmic change reporting rely on the concept of event classification for selective reporting of individual occurrences of events. Particular intrinsic or algorithmic change events may specify a notification class number that is directly related to a Notification Class object within the initiating device. The Notification Class object is used to specify the handling and routing of events to one or more destinations. The Notification Class object defines the priorities to be used in event-notification messages, whether acknowledgment by an application process or human operator is required, and at what time periods during the week given destinations are to be used.
BACnet devices that support event notification are free to define any number of unique conditions that trigger alarm or event notifications. Alarms and events are broadly classified into one of three possible groups: fault, offnormal, and normal. A “fault” condition is a malfunction, nearly always representing a failure within the automation system itself. An “offnormal” condition is a condition within the system that is not normally expected or is outside the bounds of ideal operation. A “normal” condition is anything else.
Event-initiating objects may identify their “state” from moment to moment as one of any number of possibly unique event states. Notifications are triggered by the “transition” of conditions for an object, usually from one unique event state to another. A transition to a particular event state may be used to identify specific unique handling for the notification(s) generated by an object, for example, controlling the destination for a notification or whether the particular transition event should require acknowledgment. In these contexts, all transitions that result in a state that is not normal, and not a fault, are considered to be TO-OFFNORMAL transitions. Transitions to any fault state are considered to be TO-FAULT transitions. All other transitions are, by definition, TO-NORMAL transitions. Events may be selectively identified as belonging to the category of “alarms” or “events.” Event-initiating objects indicate this distinction through the Notify_Type property. In BACnet, the singular distinction between alarms and all other events is whether the event will be reported by the GetAlarmSummary service or not. Alarms will be reported by the GetAlarmSummary service, while all other events will not be reported by GetAlarmSummary. In every other respect, BACnet makes no distinction between an alarm and an event.
None of the reporting mechanisms is preferred, as each addresses particular needs generally found in building automation and control systems. A given BACnet device may use any or all of these mechanisms to provide alarm and event management functions. However, each mechanism dictates a standardized complement of services and/or objects that are used to realize their functions.
13.1 Change of Value Reporting
Change of value (COV) reporting allows a COV-client to subscribe with a COV-server, on a permanent or temporary basis, to receive reports of some changes of value of some referenced property based on fixed criteria. If an object provides COV reporting, then changes of value of any subscribed-to properties of the object, in some cases based on programmable increments, trigger COV notifications to be sent to subscribing clients. Typically, COV notifications are sent to supervisory programs in COV-client devices or to operators or logging devices. Any object, proprietary or standard, may support COV reporting at the implementor’s option.
COV subscriptions are established using the SubscribeCOV service or the SubscribeCOVProperty service. The subscription establishes a connection between the change of value detection and reporting mechanism within the COV-server device and a “process” within the COV-client device. Notifications of changes are issued by the COV-server when changes occur after the subscription has been established. The ConfirmedCOVNotification and UnconfirmedCOVNotification services are used by the COV-server to convey change notifications. The choice of confirmed or unconfirmed service is specified in the subscription.
When a BACnet standard object, of a type listed in Table 13-1, supports COV reporting it shall support COV reporting for the property as listed in Table 13-1. At the implementor’s discretion, COV reporting may also be supported for any other property of the object. For properties listed in Table 13-1 that have a REAL datatype, the COV increment used to determine when to generate notifications will be the COV_Increment property of the object unless a COV_Increment parameter is supplied in the SubscribeCOVProperty service. For other properties that have a REAL datatype, the COV increment to use when not supplied with the SubscribeCOVProperty service shall be a local matter. This is to allow multiple subscribers that do not require a specific increment to use a common increment to allow for the reduction of the processing burden on the COV-server. The criteria for COV reporting for properties other than those listed in Table 13-1 is based on the datatype of the property subscribed to and is described in Table 13-1a.
If an object supports the COV_Period property and COV_Period is non-zero, it shall issue COV notifications to all subscribed recipients at the regular interval specified by COV_Period, in addition to the notifications initiated by the change of value of the monitored property. The value of the monitored property conveyed by the periodic COV notification shall be the basis for determining whether a subsequent COV notification is required by the change in value of the monitored property. If COV_Period is zero, the periodic notifications shall not be issued.
It is the responsibility of the COV-server to maintain the list of active subscriptions for each object that supports COV notification. This list of subscriptions shall be capable of holding at least a single subscription for each object that supports COV notification, although multiple subscriptions may be supported at the implementor’s option. The list of subscriptions is network-visible through the device object’s Active_COV_Subscriptions property. Subscriptions may be created with finite lifetimes, meaning that the subscription may lapse and be automatically canceled after a period of time. Optionally, the lifetime may be specified as infinite, meaning that no automatic cancellation occurs. However, the COV-server is not required to guarantee preservation of subscriptions across power failures or “restarts.” Periodic resubscription is allowed and expected and shall simply succeed as if the subscription were new, extending the lifetime of the subscription.
The different standard objects that support standardized COV reporting use different criteria for determining that a “change of value” has occurred, which are summarized in Table 13-1. Proprietary object types, or other standard object types not listed in Table 13-1, that support COV reporting of the Present_Value property, should follow these criteria whenever possible. Any objects that may optionally provide COV support and the change of value algorithms they shall employ are summarized in Tables 13-1 and 13-1a.
13.4 Alarm and Event Occurrence and Notification
The connection between the occurrence of an event and the transmission of a notification message to one or more recipients is established in one of several ways, depending on the type of reporting desired. COV events are connected to one or more subscribers through the use of the SubscribeCOV service. Intrinsic events are connected to one or more recipients indirectly through association with a Notification Class object. Algorithmic change events are connected to one or more recipients by the creation of an Event Enrollment object.
The criteria for event occurrence detection are specified through properties of those objects that may generate event notifications and using parameters of the SubscribeCOV service. These properties are described under the particular objects that may generate events, as summarized in Table 13-2, and in the Event Enrollment object. All objects that generate events have a property that indicates the state of the object with respect to alarm and event handling, and each such object may be explicitly enabled or disabled for reporting of specific events.
Intrinsic object-generated events, and events generated by Event Enrollment objects, may be controlled by a Notification Class object that defines their handling options. Event Enrollment objects, may alternatively specify single recipients to receive notifications without special handling.
COV and event notifications may be specified to use either confirmed or unconfirmed services for notification messages. By providing two kinds of notification mechanisms, BACnet allows the application designer to decide the relative importance of each event and whether or not notification of its occurrence is essential or merely desirable. In the former case, notification can be carried out with a confirmed service and repeated for as many recipients as required. In the latter case, an unconfirmed service using a broadcast or multicast address may be used.
Event Enrollment objects and Notification Class objects specify the destination devices for notification messages using BACnetRecipients. The recipients may be individual devices, groups of devices with a common multicast address, or all devices reachable by a broadcast address. If a broadcast is used, the scope may be limited to all devices on a single network or it may be extended to encompass all devices on a BACnet internetwork. See Clause 6.
The event notification services contain a ‘Time Stamp’ parameter that indicates the chronological order of events. This ‘Time Stamp’ may be the actual time as determined by the local device clock or, if the device has no clock, a sequence number. Sequence numbers are required to increase monotonically up to their maximum value, at which point the number “wraps around” to zero. A device may have a single sequence number for all event-initiating objects, or it may have a separate sequence number for each object.
Eleven services are defined specifically for event management: (a) AcknowledgeAlarm
(b) ConfirmedCOVNotification
(c) UnconfirmedCOVNotification
(d) ConfirmedEventNotification
(e) UnconfirmedEventNotification
(f) GetAlarmSummary
(g) GetEnrollmentSummary
(h) GetEventInformation
(i) LifeSafetyOperation
(j) SubscribeCOV
(k) SubscribeCOVProperty
13.6 ConfirmedCOVNotification Service
The ConfirmedCOVNotification service is used to notify subscribers about changes that may have occurred to the properties of a particular object. Subscriptions for COV notifications are made using the SubscribeCOV service or the SubscribeCOVProperty service.
13.6.1 Structure
The structure of the ConfirmedCOVNotification service primitives is shown in Table 13-7. The terminology and symbology used in this table are explained in 5.6.
13.6.1.1 Argument
This parameter shall convey the parameters for the ConfirmedCOVNotification service request.
13.6.1.2 Subscriber Process Identifier
This parameter, of type Unsigned32, shall convey a numeric “handle” meaningful to the subscriber. This handle shall be used to identify the process within the COV client that should receive the notification.
13.6.1.3 Initiating Device Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the Device Object_Identifier of the device that initiated the ConfirmedCOVNotification service request.
13.6.1.4 Monitored Object Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the Object_Identifier of the object that has changed.
13.6.1.5 Time Remaining
This parameter, of type Unsigned, shall convey the remaining lifetime of the subscription in seconds. A value of zero shall indicate an indefinite lifetime without automatic cancellation.
13.6.1.6 List of Values
This parameter shall convey a list of one or more property values whose contents depends on the type of object being monitored. Table 13-1 summarizes the BACnet standard objects and those property values that shall be returned in the ‘List of Values’ parameter when those objects are enabled for COV reporting. The property values are returned in the order shown in Table 13-1.
13.6.1.7 Result(+)
The ‘Result(+)’ parameter shall indicate that the requested service has succeeded.
13.6.1.8 Result(-)
The ‘Result(-)’ parameter shall indicate that the service request has failed. The reason for failure shall be specified by the ‘Error Type’ parameter.
13.6.1.8.1 Error Type
This parameter shall consist of two component parameters: (1) the ‘Error Class’ and (2) the ‘Error Code’. See Clause 18.
13.6.2 Service Procedure
After verifying the validity of the request, the responding BACnet-user shall take whatever local actions have been assigned to the indicated COV and issue a Result(+)’ service primitive. If the service request cannot be executed, a ‘Result(-)’ service primitive shall be issued indicating the error encountered.
13.7 UnconfirmedCOVNotification Service
The UnconfirmedCOVNotification Service is used to notify subscribers about changes that may have occurred to the properties of a particular object, or to distribute object properties of wide interest (such as outside air conditions) to many devices simultaneously without a subscription. Subscriptions for COV notifications are made using the SubscribeCOV service. For unsubscribed notifications, the algorithm for determining when to issue this service is a local matter and may be based on a change of value, periodic updating, or some other criteria.
13.7.1 Structure
The structure of the UnconfirmedCOVNotification service primitive is shown in Table 13-8. The terminology and symbology used in this table are explained in 5.6.
13.7.1.1 Argument
This parameter shall convey the parameters for the UnconfirmedCOVNotification service request.
13.7.1.2 Subscriber Process Identifier
This parameter, of type Unsigned32, shall convey a numeric “handle” meaningful to the subscriber. This handle shall be used to identify the process within the COVclient that should receive the notification. The value of zero is reserved for unsubscribed COV.
13.7.1.3 Initiating Device Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the Device Object_Identifier of the device that initiated the UnconfirmedCOVNotification service request.
13.7.1.4 Monitored Object Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the Object_Identifier of the object that has changed.
13.7.1.5 Time Remaining
This parameter, of type Unsigned, shall convey the remaining lifetime of the subscription in seconds. A value of zero shall indicate an indefinite lifetime, without automatic cancellation, or an unsubscribed notification.
13.7.1.6 List of Values
This parameter shall convey a list of one or more property values whose contents depend on the type of object being monitored. Table 13-1 summarizes the BACnet standard objects and those property values that shall be returned in the ‘List of Values’ parameter when those objects are enabled for COV reporting.
13.7.2 Service Procedure
Since this is an unconfirmed service, no response primitives are expected. Actions taken in response to this notification are a local matter.
13.14 SubscribeCOV Service
The SubscribeCOV service is used by a COV-client to subscribe for the receipt of notifications of changes that may occur to the properties of a particular object. Certain BACnet standard objects may optionally support COV reporting. If a standard object provides COV reporting, then changes of value of specific properties of the object, in some cases based on programmable increments, trigger COV notifications to be sent to one or more subscriber clients. Typically, COV notifications are sent to supervisory programs in BACnet client devices or to operators or logging devices. Proprietary objects may support COV reporting at the implementor’s option. The standardized objects that may optionally provide COV support and the change of value algorithms they shall employ are summarized in Table 13-1.
The subscription establishes a connection between the change of value detection and reporting mechanism within the COVserver device and a “process” within the COV-client device.
Notifications of changes are issued by the COV-server device when changes occur after the subscription has been established. The ConfirmedCOVNotification and UnconfirmedCOVNotification services are used by the COV-server device to convey change notifications. The choice of confirmed or unconfirmed service is made at the time the subscription is established.
13.14.1 Structure
The structure of the SubscribeCOV service primitives is shown in Table 13-15. The terminology and symbology used in this table are explained in 5.6.
13.14.1.1 Argument
This parameter shall convey the parameters for the SubscribeCOV confirmed service request.
13.14.1.2 Subscriber Process Identifier
This parameter, of type Unsigned32, shall convey a numeric “handle” meaningful to the subscriber. This handle shall be used to match future re-subscriptions and cancellations from the subscriber with the COV context that exists within the COVserver device and with confirmed or unconfirmed COV notifications to identify the process within the COV-client that should receive them. The value zero is reserved for unsubscribed COV notifications as described in 13.7.
13.14.1.3 Monitored Object Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the identifier of the object within the receiving device for which a subscription is desired.
13.14.1.4 Issue Confirmed Notifications
This parameter, of type BOOLEAN, shall convey whether the COV-server device shall issue ConfirmedCOVNotifications (TRUE) or UnconfirmedCOVNotifications (FALSE) when changes occur. This parameter, if present, shall indicate a subscription or re-subscription is to occur and that the lifetime shall be refreshed to its initial state. If both the ‘Issue Confirmed Notifications’ and ‘Lifetime’ parameters are absent, then this shall indicate a cancellation request. If the ‘Lifetime’ parameter is present then the ‘Issue Confirmed Notifications’ parameter shall be present.
13.14.1.5 Lifetime
This parameter, of type Unsigned, shall convey the desired lifetime of the subscription in seconds. A value of zero shall indicate an indefinite lifetime, without automatic cancellation. A non-zero value shall indicate the number of seconds that may elapse before the subscription shall be automatically cancelled. If both the ‘Issue Confirmed Notifications’ and ‘Lifetime’ parameters are absent, then this shall indicate a cancellation request. If the ‘Lifetime’ parameter is present then the ‘Issue Confirmed Notifications’ parameter shall be present.
13.14.1.6 Result(+)
The ‘Result(+)’ parameter shall indicate that the requested service has succeeded.
13.14.1.7 Result(-)
The ‘Result(-)’ parameter shall indicate that the service request has failed. The reason for failure shall be specified by the ‘Error Type’ parameter.
13.14.1.7.1 Error Type
This parameter shall consist of two component parameters: (1) the ‘Error Class’ and (2) the ‘Error Code’. See Clause 18.
13.14.2 Service Procedure
If neither ‘Lifetime’ nor ‘Issue Confirmed Notifications’ are present, then the request shall be considered to be a cancellation. Any COV context that already exists for the same BACnet address contained in the PDU that carries the SubscribeCOV request and has the same ‘Subscriber Process Identifier’ and ‘Monitored Object Identifier’ shall be disabled and a ‘Result(+)’ returned. Cancellations that are issued for which no matching COV context can be found shall succeed as if a context had existed, returning ‘Result(+)’.
If the ‘Lifetime’ parameter is present and has a non-zero value but the device does not support automatic cancellation of subscriptions, then a ‘Result(-)’ shall be returned. If the ‘Lifetime’ parameter is not present but the ‘Issue Confirmed Notifications’ parameter is present, then a value of zero (indefinite lifetime) shall be assumed for the lifetime. If the ‘Issue Confirmed Notifications’ parameter is present but the object to be monitored does not support COV reporting, then a ‘Result(-)’ shall be returned. If the object to be monitored does support COV reporting, then a check shall be made to locate an existing COV context for the same BACnet address contained in the PDU that carries the SubscribeCOV request and has the same ‘Subscriber Process Identifier’ and ‘Monitored Object Identifier’. If an existing COV context is found, then the request shall be considered a re-subscription and shall succeed as if the subscription had been newly created.
If no COV context can be found that matches the request, then a new COV context shall be established that contains the BACnet address from the PDU that carries the SubscribeCOV request and the same ‘Subscriber Process Identifier’ and ‘Monitored Object Identifier’. If no context can be created, then a ‘Result(-)’ shall be returned.
If a new context is created, or a re-subscription is received, then the COV context shall be initialized and given a lifetime as specified by the ‘Lifetime’ parameter, if present, or zero if the ‘Lifetime’ parameter is not present. The subscription shall be automatically cancelled after that many seconds have elapsed unless a re-subscription is received. A lifetime of zero shall indicate that the subscription is indefinite and no automatic cancellation shall occur. In either case, a ‘Result(+)’ shall be returned. A ConfirmedCOVNotification or UnconfirmedCOVNotification shall be issued as soon as possible after the successful completion of a subscription or re-subscription request, as specified by the ‘Issue Confirmed Notifications’ parameter.
13.15 SubscribeCOVProperty Service
The SubscribeCOVProperty service is used by a COV-client to subscribe for the receipt of notifications of changes that may occur to the properties of a particular object. Any object may optionally support COV reporting. If a standard object provides COV reporting, then changes of value of subscribed-to properties of the object, in some cases based on programmable increments, trigger COV notifications to be sent to one or more subscriber clients. Typically, COV notifications are sent to supervisory programs in BACnet client devices or to operators or logging devices.
The subscription establishes a connection between the change of value detection and reporting mechanism within the COVserver device and a “process” within the COV-client device.
Notifications of changes are issued by the COV-server device when changes occur after the subscription has been established. The ConfirmedCOVNotification and UnconfirmedCOVNotification services are used by the COV-server device to convey change notifications. The choice of confirmed or unconfirmed service is made at the time the subscription is established. Any object, proprietary or standard, may support COV reporting for any property at the implementor’s option.
The SubscribeCOVProperty service differs from the SubscribeCOV service in that it allows monitoring of properties other than those listed in Table 13-1.
13.15.1 Structure
The structure of the SubscribeCOVProperty service primitives is shown in Table 13-16. The terminology and symbology used in this table are explained in 5.6.
13.15.1.1 Argument
This parameter shall convey the parameters for the SubscribeCOVProperty confirmed service request.
13.15.1.2 Subscriber Process Identifier
This parameter, of type Unsigned32, shall convey a numeric “handle” meaningful to the subscriber. This handle shall be used to match future re-subscriptions and cancellations from the subscriber with the COV context that exists within the COVserver device and with confirmed or unconfirmed COV notifications to identify the process within the COV-client that should receive them.
13.15.1.3 Monitored Object Identifier
This parameter, of type BACnetObjectIdentifier, shall convey the identifier of the object within the receiving device that contains the property for which a subscription is desired.
13.15.1.4 Issue Confirmed Notifications
This parameter, of type BOOLEAN, shall convey whether the COV-server device shall issue ConfirmedCOVNotifications (TRUE) or UnconfirmedCOVNotifications (FALSE) when changes occur. This parameter, if present, shall indicate that a subscription or re-subscription is to occur and that the lifetime shall be refreshed to its initial state. If both the ‘Issue Confirmed Notifications’ and ‘Lifetime’ parameters are absent, then this shall indicate a cancellation request. If the ‘Lifetime’ parameter is present then the ‘Issue Confirmed Notifications’ parameter shall be present.
13.15.1.5 Lifetime
This parameter, of type Unsigned, shall convey the desired lifetime of the subscription in seconds. A value of zero shall not be allowed. A non-zero value shall indicate the number of seconds that may elapse before the subscription shall be automatically cancelled. If both the ‘Issue Confirmed Notifications’ and ‘Lifetime’ parameters are absent, then this shall indicate a cancellation request. If the ‘Issue Confirmed Notifications’ parameter is present then the ‘Lifetime’ parameter shall be present.
13.15.1.6 Monitored Property Identifier
This parameter, of type BACnetPropertyReference, shall convey the property identifier and optional array index for which a subscription is desired. If COV reporting is supported for a property that has an array datatype, it is a local matter to determine whether to support COV subscriptions for all elements of the array or only for particular elements in the array.
13.15.1.7 COV Increment
This parameter, of type REAL, shall specify the minimum change in the monitored property that will cause a COVNotification to be issued to subscriber COV-clients. This parameter is ignored if the datatype of the monitored property is not REAL. If the monitored property is Present_Value, its datatype is REAL, this parameter is not present, and the monitored object has a COV_Increment property, then the COV increment to use is taken from the COV_Increment property of the monitored object. Otherwise, the COV increment is a local matter. The intent is to allow the subscriber to use a previously established COV increment from another subscription or to allow use of the COV_Increment property in the monitored object.
13.15.1.8 Result(+)
The ‘Result(+)’ parameter shall indicate that the requested service has succeeded.
13.15.1.9 Result(-)
The ‘Result(-)’ parameter shall indicate that the service request has failed. The reason for failure shall be specified by the ‘Error Type’ parameter.
13.15.1.9.1 Error Type
This parameter shall consist of two component parameters: (1) the ‘Error Class’ and (2) the ‘Error Code’. See Clause 18.
13.15.2 Service Procedure
If neither ‘Lifetime’ nor ‘Issue Confirmed Notifications’ are present, then the request shall be considered to be a cancellation. Any COV context that already exists for the same BACnet address contained in the PDU that carries the SubscribeCOVProperty request and has the same ‘Subscriber Process Identifier’, ‘Monitored Object Identifier’ and ‘Monitored Property Identifier’ shall be disabled and a ‘Result(+)’ returned. Cancellations that are issued for which no matching COV context can be found shall succeed as if a context had existed, returning ‘Result(+)’. If an existing COV context is found, it shall be removed from the Active_COV_Subscriptions property in the Device object.
If the ‘Issue Confirmed Notifications’ parameter is present but the property to be monitored does not support COV reporting, then a ‘Result(-)’ shall be returned. If the property to be monitored does support COV reporting, then a check shall be made to locate an existing COV context for the same BACnet address contained in the PDU that carries the SubscribeCOVProperty request and has the same ‘Subscriber Process Identifier’, ‘Monitored Object Identifier’ and ‘Monitored Property Identifier’. If an existing COV context is found, then the request shall be considered a re-subscription and shall succeed as if the subscription had been newly created. If no COV context can be found that matches the request, then a new COV context shall be established that contains the BACnet address from the PDU that carries the SubscribeCOVProperty request and the same ‘Subscriber Process Identifier’, ‘Monitored Object Identifier’ and ‘Monitored Property Identifier’. The new context shall be included in the Active_COV_Subscriptions property of the Device object. If no context can be created, then a ‘Result(-)’ shall be returned.
If a new context is created, or a re-subscription is received, then the COV context shall be initialized and given a lifetime as specified by the ‘Lifetime’ parameter. The subscription shall be automatically cancelled after that many seconds have elapsed unless a re-subscription is received. A ‘Result(+)’ shall be returned and a ConfirmedCOVNotification or UnconfirmedCOVNotification shall be issued as soon as possible after the successful completion of a subscription or resubscription request, as specified by the ‘Issue Confirmed Notifications’ parameter.
18 ERROR, REJECT, and ABORT CODES
All errors associated with the BACnet protocol are enumerated according to a category called “Error Class.” Within each Error Class, the errors are further enumerated individually by “Error Code.” It is thus possible for an application to take remedial action based upon two levels of granularity.
18.2 Error Class – OBJECT
This Error Class pertains to problems related to identifying, accessing, and manipulating BACnet objects, whether BACnetdefined or not. Since these errors generally apply to individual object characteristics, they do not necessarily signal that an entire service request has failed.
18.3.6 NOT_COV_PROPERTY – The property is not conveyed by COV notification.
18.6 Error Class – SERVICES
This Error Class pertains to problems related to the execution of protocol service requests, whether BACnet-defined or not. Without exception, these errors signal the inability of the responding BACnet-user to carry out the desired service in its entirety and are thus “fatal.”
18.6.1 CHARACTER_SET_NOT_SUPPORTED
A character string value was encountered that is not a supported character set.
18.6.2 COV_SUBSCRIPTION_FAILED
COV Subscription failed for some reason.
BACnetPDU ::= CHOICE {
confirmed-request-PDU [0] BACnet-Confirmed-Request-PDU,
unconfirmed-request-PDU [1] BACnet-Unconfirmed-Request-PDU,
simpleACK-PDU [2] BACnet-SimpleACK-PDU,
complexACK-PDU [3] BACnet-ComplexACK-PDU,
segmentAck-PDU [4] BACnet-SegmentACK-PDU,
error-PDU [5] BACnet-Error-PDU,
reject-PDU [6] BACnet-Reject-PDU,
abort-PDU [7] BACnet-Abort-PDU
}
BACnet-Confirmed-Request-PDU ::= SEQUENCE {
pdu-type [0] Unsigned (0..15), — 0 for this PDU type
segmented-message [1] BOOLEAN,
more-follows [2] BOOLEAN,
segmented-response-accepted [3] BOOLEAN,
reserved [4] Unsigned (0..3), — must be set to zero
max-segments-accepted [5] Unsigned (0..7), — as per 20.1.2.4
max-APDU-length-accepted [6] Unsigned (0..15), — as per 20.1.2.5
invokeID [7] Unsigned (0..255),
sequence-number [8] Unsigned (0..255) OPTIONAL, — only if segmented msg
proposed-window-size [9] Unsigned (1..127) OPTIONAL, — only if segmented msg
service-choice [10] BACnetConfirmedServiceChoice,
service-request [11] BACnet-Confirmed-Service-Request OPTIONAL
— Context-specific tags 0..11 are NOT used in header encoding
}
BACnetConfirmedServiceChoice ::= ENUMERATED {
— Alarm and Event Services
acknowledgeAlarm (0),
confirmedCOVNotification (1),
confirmedEventNotification (2),
getAlarmSummary (3),
getEnrollmentSummary (4),
getEventInformation (29),
subscribeCOV (5),
subscribeCOVProperty (28),
lifeSafetyOperation (27),
……… many more ……………….
Services added after 1995
— readRange (26) see Object Access Services
— lifeSafetyOperation (27) see Alarm and Event Services
— subscribeCOVProperty (28) see Alarm and Event Services
— getEventInformation (29) see Alarm and Event Services
}
BACnet-Confirmed-Service-Request ::= CHOICE {
— Alarm and Event Services
acknowledgeAlarm [0] AcknowledgeAlarm-Request,
confirmedCOVNotification [1] ConfirmedCOVNotification-Request,
confirmedEventNotification [2] ConfirmedEventNotification-Request,
— getAlarmSummary conveys no parameters
getEnrollmentSummary [4] GetEnrollmentSummary-Request,
getEventInformation [29] GetEventInformation-Request,
subscribeCOV [5] SubscribeCOV-Request,
subscribeCOVProperty [28] SubscribeCOVProperty-Request,
lifeSafetyOperation [27] LifeSafetyOperation-Request,
….. Many more …………….
— Services added after 1995
— readRange [26] see Object Access Services
— lifeSafetyOperation [27] see Alarm and Event Services
— subscribeCOVProperty [28] see Alarm and Event Services
— getEventInformation [29] see Alarm and Event Services
}
— Context-
ConfirmedCOVNotification-Request ::= SEQUENCE {
subscriberProcessIdentifier [0] Unsigned32,
initiatingDeviceIdentifier [1] BACnetObjectIdentifier,
monitoredObjectIdentifier [2] BACnetObjectIdentifier,
timeRemaining [3] Unsigned,
listOfValues [4] SEQUENCE OF BACnetPropertyValue
}
SubscribeCOV-Request ::= SEQUENCE {
subscriberProcessIdentifier [0] Unsigned32,
monitoredObjectIdentifier [1] BACnetObjectIdentifier,
issueConfirmedNotifications [2] BOOLEAN OPTIONAL,
lifetime [3] Unsigned OPTIONAL
}
SubscribeCOVProperty-Request ::= SEQUENCE {
subscriberProcessIdentifier [0] Unsigned32,
monitoredObjectIdentifier [1] BACnetObjectIdentifier,
issueConfirmedNotifications [2] BOOLEAN OPTIONAL,
lifetime [3] Unsigned OPTIONAL,
monitoredPropertyIdentifier [4] BACnetPropertyReference,
covIncrement [5] REAL OPTIONAL
}
BACnetUnconfirmedServiceChoice ::= ENUMERATED {
i-Am (0),
i-Have (1),
unconfirmedCOVNotification (2),
unconfirmedEventNotification (3),
unconfirmedPrivateTransfer (4),
unconfirmedTextMessage (5),
timeSynchronization (6),
who-Has (7),
who-Is (8),
utcTimeSynchronization (9)
}
— Other services to be added as they are defined. All choice values in this production are reserved for definition by
— ASHRAE. Proprietary extensions are made by using the UnconfirmedPrivateTransfer service. See Clause 23.
BACnet-Unconfirmed-Service-Request ::= CHOICE {
i-Am [0] I-Am-Request,
i-Have [1] I-Have-Request,
unconfirmedCOVNotification [2] UnconfirmedCOVNotification-Request,
unconfirmedEventNotification [3] UnconfirmedEventNotification-Request,
unconfirmedPrivateTransfer [4] UnconfirmedPrivateTransfer-Request,
unconfirmedTextMessage [5] UnconfirmedTextMessage-Request,
timeSynchronization [6] TimeSynchronization-Request,
who-Has [7] Who-Has-Request,
who-Is [8] Who-Is-Request,
utcTimeSynchronization [9] UTCTimeSynchronization-Request
}
UnconfirmedCOVNotification-Request ::= SEQUENCE {
subscriberProcessIdentifier [0] Unsigned32,
initiatingDeviceIdentifier [1] BACnetObjectIdentifier,
monitoredObjectIdentifier [2] BACnetObjectIdentifier,
timeRemaining [3] Unsigned,
listOfValues [4] SEQUENCE OF BACnetPropertyValue
}
BACnet-Error ::= CHOICE {
other [127] Error,
— The remaining choices in this production represent the Result(-) parameters
— defined for each confirmed service.
— Alarm and Event Services
acknowledgeAlarm [0] Error,
confirmedCOVNotification [1] Error,
confirmedEventNotification [2] Error,
getAlarmSummary [3] Error,
getEnrollmentSummary [4] Error,
getEventInformation [29] Error,
subscribeCOV [5] Error,
subscribeCOVProperty [28] Error,
lifeSafetyOperation [27] Error,
— File Access Services
atomicReadFile [6] Error,
atomicWriteFile [7] Error,
— Object Access Services
addListElement [8] ChangeList-Error,
removeListElement [9] ChangeList-Error,
createObject [10] CreateObject-Error,
deleteObject [11] Error,
readProperty [12] Error,
readPropertyConditional [13] Error,
readPropertyMultiple [14] Error,
readRange [26] Error,
writeProperty [15] Error,
writePropertyMultiple [16] WritePropertyMultiple-Error,
— Remote Device Management Services
deviceCommunicationControl [17] Error,
confirmedPrivateTransfer [18] ConfirmedPrivateTransfer-Error,
confirmedTextMessage [19] Error,
reinitializeDevice [20] Error,
— Virtual Terminal Services
vtOpen [21] Error,
vtClose [22] VTClose-Error,
vtData [23] Error,
— Security Services
authenticate [24] Error,
requestKey [25] Error
— Services added after 1995
— readRange [26] see Object Access Services
— lifeSafetyOperation [27] see Alarm and Event Services
— subscribeCOVProperty [28] see Alarm and Event Services
— getEventInformation [29] see Alarm and Event Services
}
Error ::= SEQUENCE {
— NOTE: The valid combinations of error-class and error-code are defined in Clause 18.
error-class ENUMERATED {
device (0),
object (1),
property (2),
resources (3),
security (4),
services (5),
vt (6),
…
},
— Enumerated values 0-63 are reserved for definition by ASHRAE. Enumerated values 64-65535 may be used by others subject to the procedures and constraints described in Clause 23.
error-code ENUMERATED {
other (0),
authentication-failed (1),
character-set-not-supported (41),
configuration-in-progress (2),
datatype-not-supported (47),
device-busy (3),
duplicate-name (48),
duplicate-object-id (49),
dynamic-creation-not-supported (4),
file-access-denied (5),
incompatible-security-levels (6),
inconsistent-parameters (7),
inconsistent-selection-criterion (8),
invalid-array-index (42),
invalid-configuration-data (46),
invalid-data-type (9),
invalid-file-access-method (10),
invalid-file-start-position (11),
invalid-operator-name (12),
invalid-parameter-data-type (13),
invalid-time-stamp (14),
key-generation-error (15),
missing-required-parameter (16),
no-objects-of-specified-type (17),
no-space-for-object (18),
no-space-to-add-list-element (19),
no-space-to-write-property (20),
no-vt-sessions-available (21),
object-deletion-not-permitted (23),
object-identifier-already-exists (24),
operational-problem (25),
optional-functionality-not-supported, (45),
password-failure (26),
property-is-not-a-list (22),
property-is-not-an-array (50),
read-access-denied (27),
security-not-supported (28),
service-request-denied (29),
timeout (30),
unknown-object (31),
unknown-property (32),
— this enumeration was removed (33),
unknown-vt-class (34),
unknown-vt-session (35),
unsupported-object-type (36),
value-out-of-range (37),
vt-session-already-closed (38),
vt-session-termination-failure (39),
write-access-denied (40),
— see character-set-not-supported (41),
— see invalid-array-index (42),
cov-subscription-failed (43),
not-cov-property (44),
— see optional-functionality-not-supported, (45),
— see invalid-configuration-data (46),
— see datatype-not-supported (47),
— see duplicate-name (48),
— see duplicate-object-id (49),
— see property-is-not-an-array (50),
…
}
— Enumerated values 0-255 are reserved for definition by ASHRAE. Enumerated values 256-65535 may be used by others subject to the procedures and constraints described in Clause 23. The last enumeration used in this version is 47.
BACnetClientCOV ::= CHOICE {
real-increment REAL,
default-increment NULL
}
BACnetCOVSubscription ::= SEQUENCE {
Recipient [0] BACnetRecipientProcess,
MonitoredPropertyReference [1] BACnetObjectPropertyReference,
IssueConfirmedNotifications [2] BOOLEAN,
TimeRemaining [3] Unsigned,
COVIncrement [4] REAL OPTIONAL — used only with monitored properties with a datatype of REAL
}
BACnetEventParameter ::= CHOICE {
— These choices have a one-to-one correspondence with the Event_Type enumeration with the exception of the complex-event-type, which is used for proprietary event types.
change-of-bitstring [0] SEQUENCE {
time-delay [0] Unsigned,
bitmask [1] BIT STRING,
list-of-bitstring-values [2] SEQUENCE OF BIT STRING
},
change-of-state [1] SEQUENCE {
time-delay [0] Unsigned,
list-of-values [1] SEQUENCE OF BACnetPropertyStates
},
change-of-value [2] SEQUENCE {
time-delay [0] Unsigned,
cov-criteria [1] CHOICE {
bitmask [0] BIT STRING,
referenced-property-increment [1] REAL
}
},
command-failure [3] SEQUENCE {
time-delay [0] Unsigned,
feedback-property-reference [1] BACnetDeviceObjectPropertyReference
},
floating-limit [4] SEQUENCE {
time-delay [0] Unsigned,
setpoint-reference [1] BACnetDeviceObjectPropertyReference,
low-diff-limit [2] REAL,
high-diff-limit [3] REAL,
deadband [4] REAL
},
out-of-range [5] SEQUENCE {
time-delay [0] Unsigned,
low-limit [1] REAL,
high-limit [2] REAL,
deadband [3] REAL
},
— context tag 7 is deprecated change-of-life-safety [8] SEQUENCE {
time-delay [0] Unsigned,
list-of-life-safety-alarm-values [1] SEQUENCE OF BACnetLifeSafetyState,
list-of-alarm-values [2] SEQUENCE OF BACnetLifeSafetyState,
mode-property-reference [3] BACnetDeviceObjectPropertyReference
},
extended [9] SEQUENCE {
vendorId [0] Unsigned,
extendedEventType [1] Unsigned,
parameters [2] SEQUENCE OF CHOICE {
null NULL,
real REAL,
integer Unsigned,
boolean BOOLEAN,
double DOUBLE,
octet OCTET STRING,
bitstring BIT STRING,
enum ENUMERATED,
reference [0] BACnetDeviceObjectProperty
}
},
buffer-ready [10] SEQUENCE {
notification-threshold [0] Unsigned,
previous-notification-count [1] Unsigned32
},
unsigned-range [11] SEQUENCE {
time-delay [0] Unsigned,
low-limit [1] Unsigned,
high-limit [2] Unsigned
}
}
— CHOICE [6] has been intentionally omitted. It parallels the complex-event-type CHOICE [6] of the BACnetNotificationParameters production which was introduced to allow the addition of proprietary event algorithms whose event parameters are not necessarily network-visible.
BACnetPropertyIdentifier ::= ENUMERATED {
accepted-modes (175),
acked-transitions (0),
ack-required (1),
action (2),
action-text (3),
active-text (4),
active-vt-sessions (5),
active-cov-subscriptions (152),
adjust-value (176),
alarm-value (6),
alarm-values (7),
all (8),
all-writes-successful (9),
apdu-segment-timeout (10),
apdu-timeout (11),
application-software-version (12),
archive (13),
attempted-samples (124),
auto-slave-discovery (169),
average-value (125),
backup-failure-timeout (153),
bias (14),
buffer-size (126),
change-of-state-count (15),
change-of-state-time (16),
— see notification-class (17), the property in this place was deleted (18),
client-cov-increment (127),
configuration-files (154),
controlled-variable-reference (19),
controlled-variable-units (20),
controlled-variable-value (21),
count (177),
count-before-change (178),
count-change-time (179),
cov-increment (22),
cov-period (180),
cov-resubscription-interval (128),
— current-notify-time (129), This property was deleted in version 1 revision 3.
database-revision (155),
date-list (23),
daylight-savings-status (24),
deadband (25),
derivative-constant (26),
derivative-constant-units (27),
description (28),
description-of-halt (29),
device-address-binding (30),
device-type (31),
direct-reading (156),
effective-period (32),
elapsed-active-time (33),
error-limit (34),
event-enable (35),
event-state (36),
event-time-stamps (130),
event-type (37),
event-parameters (83), — renamed from previous version
exception-schedule (38),
fault-values (39),
feedback-value (40),
file-access-method (41),
file-size (42),
file-type (43),
firmware-revision (44),
high-limit (45),
inactive-text (46),
in-process (47),
input-reference (181),
instance-of (48),
integral-constant (49),
integral-constant-units (50),
— issue-confirmed-notifications (51), This property was deleted in version 1 revision 4.
last-notify-record (173),
last-restore-time (157),
life-safety-alarm-values (166),
limit-enable (52),
limit-monitoring-interval (182),
list-of-group-members (53),
list-of-object-property-references (54),
list-of-session-keys (55),
local-date (56),
local-time (57),
location (58),
log-buffer (131),
log-device-object-property (132),
log-enable (133),
log-interval (134),
logging-object (183),
logging-record (184),
low-limit (59),
maintenance-required (158),
manipulated-variable-reference (60),
manual-slave-address-binding (170),
maximum-output (61),
maximum-value (135),
maximum-value-timestamp (149),
max-apdu-length-accepted (62),
max-info-frames (63),
max-master (64),
max-pres-value (65),
max-segments-accepted (167),
member-of (159),
minimum-off-time (66),
minimum-on-time (67),
minimum-output (68),
minimum-value (136),
minimum-value-timestamp (150),
min-pres-value (69),
mode (160),
model-name (70),
modification-date (71),
notification-class (17), — renamed from previous version
notification-threshold (137),
notify-type (72),
number-of-APDU-retries (73),
number-of-states (74),
object-identifier (75),
object-list (76),
object-name (77),
object-property-reference (78),
object-type (79),
operation-expected (161),
optional (80),
out-of-service (81),
output-units (82),
— see event-parameters (83),
polarity (84),
prescale (185),
present-value (85),
— previous-notify-time (138), This property was deleted in version 1 revision 3.
priority (86),
pulse-rate (186),
priority-array (87),
priority-for-writing (88),
process-identifier (89),
profile-name (168),
program-change (90),
program-location (91),
program-state (92),
proportional-constant (93),
proportional-constant-units (94),
— protocol-conformance-class (95), This property was deleted in version 1 revision 2.
protocol-object-types-supported (96),
protocol-revision (139),
protocol-services-supported (97),
protocol-version (98),
read-only (99),
reason-for-halt (100),
— recipient (101), This property was deleted in version 1 revision 4.
recipient-list (102),
records-since-notification (140),
record-count (141),
reliability (103),
relinquish-default (104),
required (105),
resolution (106),
scale (187),
scale-factor (188),
schedule-default (174),
segmentation-supported (107),
setpoint (108),
setpoint-reference (109),
slave-address-binding (171),
setting (162),
silenced (163),
start-time (142),
state-text (110),
status-flags (111),
stop-time (143),
stop-when-full (144),
system-status (112),
time-delay (113),
time-of-active-time-reset (114),
time-of-state-count-reset (115),
time-synchronization-recipients (116),
total-record-count (145),
tracking-value (164),
units (117),
update-interval (118),
update-time (189),
utc-offset (119),
valid-samples (146),
value-before-change (190),
value-set (191),
value-change-time (192),
variance-value (151),
vendor-identifier (120),
vendor-name (121),
vt-classes-supported (122),
weekly-schedule (123),
— see attempted-samples (124),
— see average-value (125),
— see buffer-size (126),
— see client-cov-increment (127),
— see cov-resubscription-interval (128),
— unused (129), current-notify-time was deleted in version 1 revision 3.
— see event-time-stamps (130),
— see log-buffer (131),
— see log-device-object-property (132),
— see log-enable (133),
— see log-interval (134),
— see maximum-value (135),
— see minimum-value (136),
— see notification-threshold (137),
— unused (138), previous-notify-time was deleted in version 1 revision 3.
— see protocol-revision (139),
— see records-since-notification (140),
— see record-count (141),
— see start-time (142),
— see stop-time (143),
— see stop-when-full (144),
— see total-record-count (145),
— see valid-samples (146),
window-interval (147),
window-samples (148),
zone-members (165),
— see maximum-value-timestamp (149),
— see minimum-value-timestamp (150),
— see variance-value (151),
— see active-cov-subscriptions (152),
— see backup-failure-timeout (153),
— see configuration-files (154),
— see database-revision (155),
— see direct-reading (156),
— see last-restore-time, (157),
— see maintenance-required (158),
— see member-of (159),
— see mode (160),
— see operation-expected (161),
— see setting (162),
— see silenced (163),
— see tracking-value (164),
— see zone-members (165),
— see life-safety-alarm-values (166),
— see max-segments-accepted (167),
— see profile-name (168),
— see auto-slave-discovery (169),
— see manual-slave-address-binding (170),
— see slave-address-binding (171),
— see slave-proxy-enable (172),
— see last-notify-time (173),
— see schedule-default (174),
— see accepted-modes (175),
— see adjust-value (176),
— see count (177),
— see count-before-change (178),
— see count-change-time (179),
— see cov-period (180),
— see input-reference (181),
— see limit-monitoring-interval (182),
— see logging-device (183),
— see logging-record (184),
— see prescale (185),
— see pulse-rate (186),
— see scale (187),
— see scale-factor (188),
— see update-time (189),
— see value-before-change (190),
— see value-set (191),
— see value-change-time (192),
…
}
BACnetServicesSupported ::= BIT STRING {
— Alarm and Event Services
acknowledgeAlarm (0),
confirmedCOVNotification (1),
confirmedEventNotification (2),
getAlarmSummary (3),
getEnrollmentSummary (4),
— getEventInformation (39),
subscribeCOV (5),
— subscribeCOVProperty (38),
— lifeSafetyOperation (37),
— File Access Services
atomicReadFile (6),
atomicWriteFile (7),
— Object Access Services
addListElement (8),
removeListElement (9),
createObject (10),
deleteObject (11),
readProperty (12),
readPropertyConditional (13),
readPropertyMultiple (14),
— readRange (35),
writeProperty (15),
writePropertyMultiple (16),
— Remote Device Management Services
deviceCommunicationControl (17),
confirmedPrivateTransfer (18),
confirmedTextMessage (19),
reinitializeDevice (20),
— Virtual Terminal Services
vtOpen (21),
vtClose (22),
vtData (23),
— Security Services
authenticate (24),
requestKey (25),
— Unconfirmed Services
i-Am (26),
i-Have (27),
unconfirmedCOVNotification (28),
unconfirmedEventNotification (29),
unconfirmedPrivateTransfer (30),
unconfirmedTextMessage (31),
timeSynchronization (32),
— utcTimeSynchronization (36),
who-Has (33),
who-Is (34),
— Services added after 1995
readRange (35), — Object Access Service
utcTimeSynchronization (36), — Remote Device Management Service
lifeSafetyOperation (37), — Alarm and Event Service
subscribeCOVProperty (38), — Alarm and Event Service
getEventInformation (39) — Alarm and Event Service
}
ANALOG-INPUT ::= SEQUENCE {
object-identifier [75] BACnetObjectIdentifier,
object-name [77] CharacterString,
object-type [79] BACnetObjectType,
present-value [85] REAL,
description [28] CharacterString OPTIONAL,
device-type [31] CharacterString OPTIONAL,
status-flags [111] BACnetStatusFlags,
event-state [36] BACnetEventState,
reliability [103] BACnetReliability OPTIONAL,
out-of-service [81] BOOLEAN,
update-interval [118] Unsigned OPTIONAL,
units [117] BACnetEngineeringUnits,
min-pres-value [69] REAL OPTIONAL,
max-pres-value [65] REAL OPTIONAL,
resolution [106] REAL OPTIONAL,
cov-increment [22] REAL OPTIONAL,
time-delay [113] Unsigned OPTIONAL,
ANNEX C – FORMAL DESCRIPTION OF OBJECT TYPES (INFORMATIVE)
454 ANSI/ASHRAE 135-2004
notification-class [17] Unsigned OPTIONAL,
high-limit [45] REAL OPTIONAL,
low-limit [59] REAL OPTIONAL,
deadband [25] REAL OPTIONAL,
limit-enable [52] BACnetLimitEnable OPTIONAL,
event-enable [35] BACnetEventTransitionBits OPTIONAL,
acked-transitions [0] BACnetEventTransitionBits OPTIONAL,
notify-type [72] BACnetNotifyType OPTIONAL,
event-time-stamps [130] SEQUENCE OF BACnetTimeStamp OPTIONAL,
— accessed as a BACnetARRAY
profile-name [168] CharacterString OPTIONAL
}
More for other objects
D.2 Example of an Analog Input Object
The following is an example of an Analog Input object that is used for mixed air temperature of an air handler. The object supports both COV and intrinsic reporting.
Property: Object_Identifier = (Analog Input, Instance 1)
Property: Object_Name = “1AH1MAT”
Property: Object_Type = ANALOG_INPUT
Property: Present_Value = 58.1
Property: Description = “Mixed Air Temperature”
Property: Device_Type = “1000 OHM RTD”
Property: Status_Flags = {FALSE, FALSE, FALSE, FALSE}
Property: Event_State = NORMAL
Property: Reliability = NO_FAULT_DETECTED
Property: Out_Of_Service = FALSE
Property: Update_Interval = 10
ANNEX D – EXAMPLES OF STANDARD OBJECT TYPES (INFORMATIVE)
466 ANSI/ASHRAE 135-2004
Property: Units = DEGREES_FAHRENHEIT
Property: Min_Pres_Value = -50.0
Property: Max_Pres_Value = 250.0
Property: Resolution = 0.1
Property: COV_Increment = 0.2
Property: Time_Delay = 10
Property: Notification_Class = 3
Property: High_Limit = 60.0
Property: Low_Limit = 55.0
Property: Deadband = 1.0
Property: Limit_Enable = {TRUE, TRUE}
Property: Event_Enable = {TRUE, FALSE, TRUE}
Property: Acked_Transitions = {TRUE, TRUE, TRUE}
Property: Notify_Type = EVENT
Property: Event_Time_Stamps = ((23-MAR-95,18:50:21.2),
(*-*-*,*:*:*.*),
(23-MAR-95,19:01:34.0))
D.6 Examples of a Binary Input Object
Example 1: A typical Binary Input object.
In this example, the Binary Input is connected to a high static pressure cutoff switch with normally open contacts. Exceeding the static pressure limit of the switch causes the normally open contacts to close. The ACTIVE state of the physical input indicates that the contacts are closed. The object supports both COV and intrinsic reporting.
Property: Object_Identifier = (Binary Input, Instance 1)
Property: Object_Name = “HighPressSwitch”
Property: Object_Type = BINARY_INPUT
Property: Present_Value = ACTIVE
Property: Description = “Penthouse Supply High Static”
Property: Device_Type = “ABC Pressure Switch”
Property: Status_Flags = {TRUE, FALSE, FALSE, FALSE}
Property: Event_State = OFFNORMAL
Property: Reliability = NO_FAULT_DETECTED
Property: Out_Of_Service = FALSE
Property: Polarity = NORMAL
Property: Inactive_Text = “Static Pressure OK”
Property: Active_Text = “High Pressure Alarm”
Property: Change_Of_State_Time = (23-MAR-1995, 19:01:34.0)
Property: Change_Of_State_Count = 134
Property: Time_Of_State_Count_Reset = (1-JAN-1995, 00:00:00.0)
Property: Elapsed_Active_Time = 401
Property: Time_Of_Active_Time_Reset = (1-JAN-1995, 00:00:00.0)
Property: Time_Delay = 10
Property: Notification_Class = 3
Property: Alarm_Value = ACTIVE
Property: Event_Enable = {TRUE, FALSE, TRUE}
Property: Acked_Transitions = {FALSE, TRUE, TRUE}
Property: Notify_Type = ALARM
Property: Event_Time_Stamps = ((23-MAR-95,18:50:21.2),
(*-*-*,*:*:*.*),
(21-MAR-95,01:02:03.0))
D.11 Examples of a Device Object
Example 1: A “sophisticated” BACnet device.
Property: Object_Identifier = (Device, Instance 1)
Property: Object_Name = “AC1 System Controller”
Property: Object_Type = DEVICE
Property: System_Status = OPERATIONAL
Property: Vendor_Name = “ABC Controls”
Property: Vendor_Identifier = 1001
Property: Model_Name = “1000 Plus”
ANNEX D – EXAMPLES OF STANDARD OBJECT TYPES (INFORMATIVE)
472 ANSI/ASHRAE 135-2004
Property: Firmware_Revision = “1.2”
Property: Application_Software_Version = “V4.0 – April 12, 1989”
Property: Location = “Basement Mechanical Room”
Property: Description = “AC1 Controller”
Property: Protocol_Version = 1
Property: Protocol_Revision = 4
Property: Protocol_Services_Supported = B’111111111111111111111111111111111111111′
Property: Protocol_Object_Types_Supported = B’111111111111111111′
Property: Object_List = ((Analog Input, Instance 1),
(Analog Input, Instance 2), …)
Property: Max_APDU_Length_Accepted = 480
Property: Segmentation_Supported = SEGMENTED_BOTH
Property: Max_Segments_Accepted = 16
Property: VT_Classes_Supported = (DEFAULT-TERMINAL, DEC-VT100)
Property: Active_VT_Sessions ((29,5,1, X’0000C0B3EF13′),(23,8,2, X’05’))
Property: Local_Time 12:34:56.78
Property: Local_Date 29-SEP-1989, FRIDAY
Property: UTC_Offset = 6.0
Property: Daylight_Savings_Status = FALSE
Property: APDU_Segment_Timeout = 2000
Property: APDU_Timeout = 3000
Property: Number_Of_APDU_Retries = 3
Property: List_Of_Session_Keys = ((X’3799246237984589′, 1, X’03’),
(X’4446214686489744′, 1, X’05’))
Property: Time_Synchronization_Recipients = (Device, Instance 18)
Property: Device_Address_Binding = (((Device, Instance 1), 1, X’01’),
((Device, Instance 12), 1, X’17’),
((Device, Instance 40), 2, X’02608C41A606′), …)
Property: Database_Revision = 123
Property: Configuration_Files = ((File, Instance 1), (File, Instance 2))
Property: Last_Restore_Time = (2, (29-SEP-1989, 01:00:00.0))
Property: Backup_Failure_Timeout = 300
Property: Active_COV_Subscriptions = ((((0, (Device, Instance 12)), 300),
((Analog Input, Instance 1),Present_Value),TRUE,100,1.0),
(((0, (Device, Instance 40)), 600),
((Analog Input, Instance 1),Present_Value),TRUE,3,1.5))
Example 2: CHANGE_OF_VALUE_EVENT event type.
This is an example of a CHANGE_OF_VALUE Event_Type. The management of recipients is done through the use of optional properties of the Event Enrollment object instead of a Notification Class object.
EVENT_ENROLLMENT
Property: Object_Identifier = (Event Enrollment, Instance 2)
Property: Object_Name = “Zone1TempCOV”
Property: Object_Type = EVENT_ENROLLMENT
Property: Description = “Zone 1 Temperature COV”
Property: Event_Type = CHANGE_OF_VALUE
Property: Notify_Type = EVENT
Property: Event_Parameters = (5, 0.25)
Property: Object_Property_Reference = ((Device, Instance 12),(Analog Input, Instance 2), Present_Value)
Property: Event_State = NORMAL
Property: Event_Enable = (TRUE, FALSE, FALSE)
Property: Acked_Transitions = (TRUE, TRUE, TRUE)
Property: Event_Time_Stamps = ((23-MAR-95,18:50:21.2),
(*-*-*,*:*:*.*),
(23-MAR-95,19:01:34.0))
E.1.2 Example of the ConfirmedCOVNotification Service
The following example illustrates a notification that the present value of a monitored Analog Input object has changed.
Service = ConfirmedCOVNotification
‘Subscriber Process Identifier’ = 18
‘Initiating Device Identifier’ = (Device, Instance 4)
‘Monitored Object Identifier’ = (Analog Input, Instance 10)
‘Time Remaining’ = 0
‘List of Values’ = ((Present_Value, 65.0), (Status_Flags, (FALSE, FALSE, FALSE, FALSE)))
F.1.2 Encoding for Example E.1.2 – ConfirmedCOVNotification Service
X’00’ PDU Type=0 (BACnet-Confirmed-Request-PDU, SEG=0, MOR=0, SA=0)
X’02’ Maximum APDU Size Accepted=206 octets
X’0F’ Invoke ID=15
X’01’ Service Choice=1 (ConfirmedCOVNotification-Request)
X’09’ SD Context Tag 0 (Subscriber Process Identifier, L=1)
X’12’ Subscriber Process Identifier=18
X’1C’ SD Context Tag 1 (Initiating Device Identifier, L=4)
X’02000004′ Device, Instance 4
X’2C’ SD Context Tag 2 (Monitored Object Identifier, L=4)
X’0000000A’ Analog Input, Instance Number=10
X’39’ SD Context Tag 3 (Time Remaining, L=1)
X’00’ Time Remaining=0
X’4E’ PD Opening Tag 4 (List Of Values)
X’09’ SD Context Tag 0 (Property Identifier, L=1)
X’55’ 85 (PRESENT_VALUE)
X’2E’ PD Opening Tag 2 (Value)
X’44’ Application Tag 4 (Real, L=4)
X’42820000′ 65.0
X’2F’ PD Closing Tag 2 (Value)
X’09’ SD Context Tag 0 (Property Identifier, L=1)
X’6F’ 111 (STATUS_FLAGS)
X’2E’ PD Opening Tag 2 (Value)
X’82’ Application Tag 8 (Bit String, L=2)
X’0400′ 0,0,0,0 (FALSE, FALSE, FALSE, FALSE)
X’2F’ PD Closing Tag 2 (Value)
X’4F’ PD Closing Tag 4 (List Of Values)
Assuming the service procedure executes correctly, a simple acknowledgment is returned:
X’20’ PDU Type=2 (BACnet-SimpleACK-PDU)
X’0F’ Invoke ID=15
X’01’ Service ACK Choice=1 (ConfirmedCOVNotification)
E.1.3 Example of the UnconfirmedCOVNotification Service
The following example illustrates a notification that the present value of a monitored Analog Input object has changed.
Service = UnconfirmedCOVNotification
‘Subscriber Process Identifier’ = 18
‘Initiating Device Identifier’ = (Device, Instance 4)
‘Monitored Object Identifier’ = (Analog Input, Instance 10)
‘Time Remaining’ = 0 ‘List of Values’ = ((Present_Value, 65.0), (Status_Flags, (FALSE, FALSE, FALSE, FALSE)))
F.1.3 Encoding for Example E.1.3 – UnconfirmedCOVNotification Service
X’10’ PDU Type=1 (BACnet-Unconfirmed-Request-PDU)
X’02’ Service Choice=2 (UnconfirmedCOVNotification-Request)
X’09’ SD Context Tag 0 (Subscriber Process Identifier, L=1)
X’12’ 18
X’1C’ SD Context Tag 1 (Initiating Device Identifier, L=4)
ANNEX F – EXAMPLES OF APDU ENCODING (INFORMATIVE)
ANSI/ASHRAE 135-2004 505
X’02000004′ Device, Instance Number=4
X’2C’ SD Context Tag 2 (Monitored Object Identifier, L=4)
X’0000000A’ Analog Input, Instance Number=10
X’39’ SD Context Tag 3 (Time Remaining, L=1)
X’00’ 0
X’4E’ PD Opening Tag 4 (List Of Values)
X’09’ SD Context Tag 0 (Property Identifier, L=1)
X’55’ 85 (PRESENT_VALUE)
X’2E’ PD Opening Tag 2 (Value)
X’44’ Application Tag 4 (Real, L=4)
X’42820000′ 65.0
X’2F’ PD Closing Tag 2 (Value)
X’09’ SD Context Tag 0 (Property Identifier, L=1)
X’6F’ 111 (STATUS_FLAGS)
X’2E’ PD Opening Tag 2 (Value)
X’82’ Application Tag 8 (Bit String, L=2)
X’0400′ 0,0,0,0 (FALSE, FALSE ,FALSE, FALSE)
X’2F’ PD Closing Tag 2 (Value)
X’4F’ PD Closing Tag 4 (List Of Values)
E.1.10 Example of the SubscribeCOV Service
This example illustrates the use of the SubscribeCOV service to subscribe indefinitely to COV notifications from an Analog Input object.
Service = SubscribeCOV
‘Subscriber Process Identifier’ = 18
‘Monitored Object Identifier’ = (Analog Input, Instance 10)
ANNEX E – EXAMPLES OF BACnet APPLICATION SERVICES (INFORMATIVE)
ANSI/ASHRAE 135-2004 489
‘Issue Confirmed Notifications’ = TRUE
‘Lifetime’ = 0
F.1.10 Encoding for Example E.1.10 – SubscribeCOV
X’00’ PDU Type=0 (BACnet-Confirmed-Request-PDU, SEG=0, MOR=0, SA=0)
X’02’ Maximum APDU Size Accepted=206 octets
X’0F’ Invoke ID=15
X’05’ Service Choice=5 (SubscribeCOV-Request)
X’09’ SD Context Tag 0 (Subscriber Process Identifier, L=1)
X’12’ 18
X’1C’ SD Context Tag 1 (Monitored Object Identifier, L=4)
X’0000000A’ Analog Input, Instance Number=10
X’29’ SD Context Tag 2 (Issue Confirmed Notifications, L=1)
X’01’ 1 (TRUE)
X’39’ SD Context Tag 3 (Lifetime, L=1)
X’00’ 0
Assuming the service procedure executes correctly, a simple acknowledgment is returned:
X’20’ PDU Type=2 (BACnet-SimpleACK-PDU)
X’0F’ Invoke ID=15
X’05’ Service ACK Choice=5 (SubscribeCOV)
E.1.11 Example of the SubscribeCOVProperty Service
This example illustrates the use of the SubscribeCOVProperty service to subscribe to COV notifications on the present-value of an Analog Input object.
Service = SubscribeCOVProperty
‘Subscriber Process Identifier’ = 18
‘Monitored Object Identifier’ = (Analog Input, Instance 10)
‘Issue Confirmed Notifications’ = TRUE
‘Lifetime’ = 60
‘Monitored Property’ = (Present_Value)
‘COV Increment’ = 1.0
F.1.11 Encoding for Example E.1.11 – SubscribeCOVProperty
X’00’ PDU Type=0 (BACnet-Confirmed-Request-PDU, SEG=0, MOR=0, SA=0)
X’02’ Maximum APDU Size Accepted=206 octets
X’0F’ Invoke ID=15
X’1C’ Service Choice=28 (SubscribeCOVProperty-Request)
ANNEX F – EXAMPLES OF APDU ENCODING (INFORMATIVE)
ANSI/ASHRAE 135-2004 513
X’09’ SD Context Tag 0 (Subscriber Process Identifier, L=1)
X’12’ 18
X’1C’ SD Context Tag 1 (Monitored Object Identifier, L=4)
X’0000000A’ Analog Input, Instance Number=10
X’29’ SD Context Tag 2 (Issue Confirmed Notifications, L=1)
X’01’ 1 (TRUE)
X’39’ SD Context Tag 3 (Lifetime, L=1)
X’3C’ 60
X’4E’ PD Opening Tag 4 (Monitored Property, L=1)
X’09’ SD Context Tag 0 (Property Identifier, L=1)
X’55’ 85 (PRESENT_VALUE)
X’4F’ PD Closing Tag 4 (Property Identifier)
X’5C’ SD Context Tag 5 (COV Increment, L=4)
X3F800000′ 1.0
Assuming the service procedure executes correctly, a simple acknowledgment is returned:
X’20’ PDU Type=2 (BACnet-SimpleACK-PDU)
X’0F’ Invoke ID=15
X’1C’ Service ACK Choice=28 (SubscribeCOVProperty)
ANNEX K – BACnet INTEROPERABILITY BUILDING BLOCKS (BIBBs) (NORMATIVE)
BACnet Interoperability Building Blocks (BIBBs) are collections of one or more BACnet services. These are prescribed in terms of an “A” and a “B” device. Both of these devices are nodes on a BACnet internetwork. In most cases, the “A” device will act as the user of data (client), and the “B” device will be the provider of this data (server). In addition, certain BIBBs may also be predicated on the support of certain, otherwise optional, BACnet objects or properties and may place constraints on the allowable values of specific properties or service parameters.
ANNEX L – DESCRIPTIONS AND PROFILES OF STANDARDIZED BACnet DEVICES (NORMATIVE)……………….590
L.1 BACent Operator Workstation (B-OWS)
L.2 BACnet Building Controller (B-BC)
L.3 BACnet Advanced Application Controller (B-AAC)
L.4 BACnet Application Specific Controller (B-ASC)
L.5 BACnet Smart Actuator (B-SA)
L.6 BACnet Smart Sensor (B-SS)
L.7 Profiles of the Standard BACnet Devices
Watch for change in Annex L
Below is obsolete
This is the newer one but there is one more update
bacnetmodbus 