A Proposed Change of Value (COV) System

White Paper

A proposed Change of Value (COV) System

2014Feb Peter Chipkin

Chipkin Automation Systems

Abstact

Most field devices are passive servers. They wait passively for a system to poll them for data and only then do the devices respond. A consequence of this is that the data client only knows the value of an object property when it polls for the value. If the duration of an event (change of value) is shorter than the interval between polls then the data client will not know the event occurred.

Proposed COV system provides a solution for this by defining services to report events. These services allow a device to be transformed from a passive server to an active server since it is now capable of sending messages reporting the value of an object property based on some event rules. Proposed COV system COV is a sub-set of the ‘Alarm and Event Services’.

This article discusses how the technology operates and then provides a discussion on some weaknesses in the COV system.

COV

A simplified definition of Proposed COV system COV

Data clients subscribe to an object for COV reporting. The device monitors the value of the object property, monitors the subscription list and the change criteria. When the change criteria are met the devices sends notifications of the new value to the subscribers.

Not all devices / objects support COV

The Proposed COV system COV system is not a mandatory part of the protocol. Each vendor decides if they want to support it. In addition, each vendor gets to decide which properties of which objects support COV.

The device object of a COV server indicates whether there is support for COV. Beyond that you have to look for the presence of certain properties such a “COV Increment’ to tell if an object supports COV or you have to refer to the vendor documentation.
COV2

Proposed COV System

  • Subscribe

Data Client sends messages to the device to subscribe to COV notifications. The server must accept the subscription.
COV

  • Monitor

COV Server device monitors the property values of subscribed objects and the COV change criteria.

  • Notify

When a change has occurred that meets the COV change criteria the server sends notifications to the subscribers or for those objects with a COV Period defined, notifications are sent based on the period if there has been no change.
COV-notify

  • Process Notification

The data client must process the notification and update the display, log ….

  • Unsubscribe / Renew Subscription

If the data client no longer needs the subscription it unsubscribe. If it needs the subscription maintained then the client should periodically re-subscribe.
The system is a little more complex than this. For example, subscriptions have durations and there is more than one way the notification can be sent

Key Elements of the COV Technology

  • COV Server :

A Proposed COV system device that supports COV, accepts subscriptions and sends COV notifications messages to a COV Client.

  • COV Client :

A Proposed COV system device, typically a SCADA or Logging application, which can subscribe for COV notification and which can process the notification messages.

  • Subscription :

Establishes a relationship between a COV Server and a COV Client. Subscriptions have the following attributes ; • Subscription to an Object or to a Property Proposed COV system provides two services for subscription. One subscribes to an object and the other to a property of an object. • Identification of the Subscriber The server needs to know where to send the notifications. • Object Identifier Eg. Analog Input 1 If subscribing to a property then the property must be identified too. • Lifetime Is indefinite or a specific number of seconds. Values can be large. • Notification Type Notification can be sent with/without requiring confirmation from the data client. • COV Increment This parameter is only used in subscriptions to object properties. If not specified in the subscription the object uses its own increment.

  • Notification :

A message which reports the current value of the changed property as well as the current state of the objects Status Flag property if it exists. The notification also contains the number of seconds remaining to the subscription. Confirmed notifications require a response from the COV client.

Change Criteria

The change criteria are based on the type of subscription

Subscribe to the object : Either of these changes trigger notification

1) If the status flags change at all

2) If the Present Value changes
– Binary, Life Safety and Multistate Objects : any change to Present Value

– Analog, Loop and Pulse Objects: change by COV_Increment
Subscribe to a property : Either of these changes trigger notification

1) If the status flags change at all (if the object has status flags)

2) If the Property Value changes
– Property is of type REAL : change by COV_Increment ( which may be defined in the subscription or may be the native increment defined in the device).

– Property is of some other type: any change to Present Value

Discussion and Limitations of COV

General Discussion

There are some intrinsic problems with event or change reporting systems.

In our experience it is fairly common to learn that a well configured system failed to deliver the critical information only after a significant failure. We learn the hard way that we polled for data too slowly, the logger was offline when the notification was sent or that the logger was swamped with data because of the failure of incoming feed. With this in mind we draw your attention to some if the issues you should consider.

The deluge of changes problem

These event reporting systems are commonly implemented to reduce the bandwidth requirements for monitoring remote devices or to ensure that the data client sees changes whose durations are less than their minimum polling interval. When a client reduces the frequency of its polls for data or reduces which objects it polls this reduces the bandwidth requirements of the system. To compensate for the lower frequency of updates a COV system may be employed.

If COV systems are employed to ‘guarantee the delivery of critical data’ great care should be taken is assessing the so called ‘guarantee’. The guarantee is often based on the assumption that changes are infrequent and small in scope but this isn’t always the case. Often a single change can spawn a number of changes and those changes can spawn more changes in a system similar to a nuclear reaction. The more changes that occur the more notifications that must be sent. If all the changes occur in a short interval then it easy to foresee a situation where a network or data client can be deluged with notifications. Now we have to assume there is enough bandwidth to handle sending them all and that each client can handle all the incoming messages quickly. If the notifications require confirmation then the speed of the client in processing the messages is material. If there is no notification required then it is conceivable in a poor Proposed COV system implementation that the client could drop messages when its buffer is full.

It is very difficult to test these conditions because the test requires monitoring large data sets and the test setup requires a knowledge of how changes can spawn other changes within a device and / or a system. A consequence of these difficulties is that the performance of COV systems can be unpredictable.

The offline Subscriber problem

A subscriber may be offline when a notification is sent. If the subscription required confirmed notification then this could present a temporary but significant loss of bandwidth while the COS server waits the timeout period before sending the next notification. If no confirmation was required then there is no way of knowing that the subscriber was offline and even if it wanted to the COS server device cannot signal this in anyway.

The COV system does not require vendors to manage notifications sent to offline subscribers. Thus the COV server does not have to queue them and resend them. Thus, it is possible for a COV client to lose its data synchronization with the Server. The only way around this is to use occasional polling. However, if the data client was a logging system then the damage is already done and the log records will not be made.

Specific Limitations of Proposed COV system COV

Subscriptions may be lost on reset

The Proposed COV system spec does not require vendors to maintain the subscriptions if the device resets. Thus a reset may result in the loss of all subscriptions. Now the system is dependent on the frequency of the re-subscription by the data client. That frequency is a vendor choice too and some systems don’t send periodic re-subscriptions.

Single/Multiple Subscriptions

A single data client can potentially subscribe more than once to the same data object. This is possible because in identifying itself, in the subscription, the client provides two elements of information – identifier and handle. The identifier tells the server where to send responses. The handle is a number allocated by the client for some internal purpose. Changing the handle is enough to make a subscription unique and hence it is possible to have multiple subscriptions to the same object from the same client.

Subscribing to Arrays

The spec allows vendors to choose whether to support subscriptions to all or particular elements of the array.

Variable Number of Subscriptions

Each vendor chooses how many subscriptions to an object / property are supported. The spec requires that at least one must be supported. You should assume the list is finite and fairly short.

It’s conceivable that subscription space could be wasted by temporary subscriptions from test equipment of software thus denying room for important subscriptions.

It is important to understand how your COV client application handles and reports failed subscriptions as these events can be as important as the event they are attempting to monitor.

Unconfirmed Notifications can be sent without Subscription

The spec allows a device to send unconfirmed notifications for any property of any object to any other device on the network. Thus a device can send changes of an object property that has a wide area interest such as an outside air temperature. The vendor chooses if they wish to implement this, which objects, which properties and the frequency of the notification.

Notifications can be sent without a change of value

The criteria for triggering notification messages requires notifications to be sent if the Status Flags associated with the object change even if the value hasn’t changed. This is potentially, important information but a number of data client systems ignore this element of the notification data.

Change of State (COS) Design Details

White Paper

Change of State (COS) COS

Understanding Subscriber Node COS Queue (SNCQ)

2014Mar – Peter Chipkin, Chipkin Automation Systems Inc.

Jargon

DA = Data Array – A memory location in which the present values and other dynamic parameter values are stored.

Subscriber = A remote node interested in receiving periodic or event based update notifications. An active client subscribes and then waits for the active server to send it notifications while it listens in passive client mode.

COS Subscriptions – Trigger Rules relationships with DA’s

For the purposes of the following notes

A COS trigger rule (CosTR) = a rule for publishing the data as well as a pointer to the device/md the data must be sent to.

Each element of each DA needs to be able to be connected to a set of CosTR’s.

A single DA element may be associated with more than one CosTR. This arises when a single DA element has been subscribed to from more than one source

A set of DA elements may be associated with a single CosTR. This arises when a subscription if for more than one element.
For example, the following arrangements may be possible.

Two single element CosTR’s

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#2

One CosTR spanning a range

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1 CosTR#1 CosTR#1 CosTR#1

One CosTR applied to non-continuous DA elements

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1 CosTR#1 CosTR#1

Two CosTR’s subscribe to same DA element

DA element 0 1 2 3 4 5 6 7
CosTR#1
CosTR#2

Complex

DA element 0 1 2 3 4 5 6 7
CosTR#1 CosTR#1
CosTR#2 CosTR#2 CosTR#2
CosTR#3
CosTR#4 CosTR#4 CosTR#4 CosTR#4

and Therefore

It would seem sensible to have a list of CosTR’s that are stored independently of the DA’s and then point part of the DA structure to the list.

This is similar but not the same as responsible MD’s (not the same because only one responsible MD for each DA element)
Adding a subscription is done the following way.

eg Add CosTR#1 to DAx:y
Add the CosTR#1 to the list of of CosTR’s. (if an identical one exists then increment the instance count – don’t add a duplicate – this discussion may be irrelevant because the rule may be the same but why would the subscriber be the same ?) In the DA find element ‘y’. Add an item to its list of CosTR pointers. The list of pointers may already exist because another CosTR may have been associated with DAx:y
If a CosTR is removed then decrement its instance count. If zero then we could remove it but what about the DA’s pointing to the CosTR. We could make the pointing bi-directional or we could mark the CosTR as dead and leave it in place so that when a DAx:y is updated the pointer points to a dead rule and when this is discovered the DA removes the pointer.

How to define the Subscriber

A subscription consists of two elements

  1. CosTR’s (Change of State Trigger Rules)
  2. Publishing Information.

Say we DAx:y is updated in such a way that it triggers COS publishing. IN AR003 we have discussed the fact that the COS data gets sent to the Subscriber Node COS Queue (SNCQ ) which will manage the publishing.
BUT

What properties of the publishing driver need to be associated with the CosTR of DAx:y

At the very least an address need to be associated because when the data is published the publisher must send the updated DAx:y data and identify it with an address.

For example: Modbus RTU. You cannot just send data. You send a write message which contains a Data_Type, address, length and data. The length can be derived. The Data_Type could be derived but I suspect that the subscriber may want to specify this and certainly the address must be known in advance. Hence A subscription could read as follows: When DAx:y=1 then send this data as if it were the contents of binary input 10001.
Another example: The DA contains enough info: DAx:y sent by SMT only needs to send a message that contains the DA name, offset and length.

The point is this

Protocol dependent

Not always required.

COS Process

Configuration Stage

Configuration can be static (CSV) or dynamic. Both process result in the creation of connections, nodes, publishing rules and special MD like structures called Trigger rules.

Trigger rules define how the COS events are define and then in the MD part of the structure provide info on how to publish the data because they provide protocol, node, co0nnection, address and other related info.
configuration-stage

Post Configuration Stage

When trigger rules are created, the kernel visits each DA structure to be watched and makes that DAx:y point to a set of trigger rules that are relevant for DAx:y
post-configuration-stage

Data Events

When a da_put is called just prior to the update, the old value and new value are grabbed and a trigger rule processing function is called. For DAx:y each associated rules is inspected. If warranted, a SNCQ Q-item is created and added to the SNCQ (Subscriber Node COS Queue)
data-event

Publishing – SNCQ Idle

An idle task browses the Q. For each subscriber node it checks the bandwidth rules. If we have recently sent data and a new message would violate the bandwidth rules then the next node is processed.

If permitted then the publishing rules are applied to Q items for a node. (The Q may be in recovery mode and the publishing process is different from the note below). The Q item provides a pointer to a trigger rule which in turn provides an MD which can be passed to pex fast track writes.
Publishing-SNCQ-Idle

Revisions

Date Rev By Note
2014Mar10 1 PMC Created
2014Apr 2 SWS Added notes on COS Processing

A study of the BACnet Data Communications Change of State / Value COV

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.

Tables 13-1
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.

Figure13-11
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.

Table13-7

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.

Table13-8

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.

Table13-15

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.

Table13-16

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 K3 ANNEX K2 ANNEX K

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

Annex L

This is the newer one but there is one more update
Annex L22 Annex L33

White Paper – Node Status Recovery with Change of State Systems and Alarm Deluge Prevention

By Peter Chipkin, Chipkin Automation Systems Inc

whitepapers@chipkin.com

2014Mar10

Abstract

Many changes to state reporting system do not provide a connection recovery mechanism.

  • For example, using the Rockwell consumer/producer model, if a produced change in IO state message is lost (because of a connection failure) the consumer will not see the change and the producer will not know the message was lost.

CAS Gateway (CASgw)’s COS engine provide several configurable and robust recovery mechanisms. They are outlined in this paper.

Many changes of state reporting systems can produce alarm message deluges when a single major event produces thousands of subsequent events.

  • For example, the loss of a major communication connection can produce a deluge of alarms from nodes using the connection if the node count is high. Systems which employ AI and other technologies to filter and prioritize alarms generally require that all alarms are known before the analysis and filters can be applied thus still necessitating large volumes of alarm messages.

CAS Gateway (CASgw) provides a flexible architecture which can be used to intelligently reduce alarm deluges and ensure only critical messages reach the front end (MMI) while still providing a trace of all original events. This architecture is discussed in this paper.

 

The problem with many COS systems.

COS systems free bandwidth when a system is operating under normal conditions and often swamp available bandwidth with a significant event triggers thousands of subsidiary events.

In the system below

  1. SMC=Environmental Controller
  2. CASGW = FS = Protrocol Converter Gateway . Collects data from a field based data gathering device. In the case of this paper, for the p[urposes of example a SMC Gas Sentry is refereed to. It is a device which measures LEL of various gases. It and produces SNMP traps in response to alarm conditions.

When the T1 connection fails the twp classic COS problems are highlighted.

  1. The published data does not reach the client. The MMI cannot alarm the events as the alarms do not reach the MMI. Worse still, the MMI as a passive client relies on published COS data, does not know the connection to each / all nodes have been lost.
  2. When the node is recovered an alarm deluge can be produced as each node reports its status.

GAS-CASgw

 

CAS Gateway (CASgw)’s Change of State Technology – A robust and flexible solution.

Connection Recovery Using CAS Gateway (CASgw)’s COS technology.

The CAS Gateway (CASgw) technology providing COS support is known as Subscribe / Publish. There are several different implementations. A general description is provided below.

 

Summary:

“Subscription” is jargon for the action taken by a remote client to inform the publisher of its interest in receiving unsolicited messages. ‘Publication’ is jargon for the action taken by a COS capable device in sending messages with COS data to subscribers.

A client subscribes for data. Subscription can be an active process (message from client) or a configuration process. Publishing means the act of sending a message that contains COS data.

 

Subscribing:

There are two main attributes of a subscription

  • Scope of Subscription: Defines what data the remote client is interested in. May be defined on a
    • Per node basis
    • Per data object basis
    • Per data range basis
  • Type of Subscription: A subscriber tells the publisher some specifics of the subscription or these attributes are taken from the CAS Gateway (CASgw) configuration. The types of subscription allow the driver to override defaults and config file settings for ALL the publication rules.

 

Publishing

Publishing COS Data: A subscription not only provides info about the subscriber but also tells the publisher the rules that trigger COS data and rules for publishing this data.

There are two main attributes groups for Publishing.

  • COS Trigger Rules

 

These rules include one or more of the following

    • Delta – Determines how much a value must change by before a COS is produced.
    • Deadband – Determines how much a value must change by before a subsequent COS is produced.
    • Hysteresis – Determines how much a value must rewind too before a new alarm COS is produced.
    • Change from Normal – Defines normal. When a value becomes abnormal A COS is produced.
    • Change of State –
    • Min Update – Determines a time interval during which, if no COS is produced then by a value change then a COS is produced based on the interval.
    • Max Update – Determines a time interval that must pass after a COS is produced before which no subsequent COS is produced.
    • High Alarm – Determines       a threshold a value must reach to produced COS data.
    • High High Alarm – Determines       a threshold a value must reach to produced COS data.
    • Low Alarm – Determines       a threshold a value must reach to produced COS data.
    • Low Low Alarm – Determines       a threshold a value must reach to produced COS data.

 

  • Publishing Process, Rules and Recovery

COS data is not sent directly to the subscriber node. It is sent to the SNCQ (Subscriber Node COS Queue). From this queue messages are sent to the subscriber if the subscriber node is online or are held / processed / dropped for later publishing if the subscriber node if offline. This queue is thus used to prevent alarm deluges and to recover from a loss of a connection .

A large number of configurable publishing rules may be defined for each subscriber node. The rules are applied according to the state of the remote subscriber node’s connection – three states are recognized – offline, probation (recovery from offline) and online.

The rules include

  • Subscriber Node COS Queue (SNCQ) Length
  • Queue full rule
  • Node Bandwidth Rules (Online)
  • Priority Rules (Online)
  • On ‘transition to offline’ rule
  • LIFO/FIFO Rules for offline publishing
  • Max Queue Age (Recovery)
  • Priority Rules (Recovery)
  • LIFO/FIFO/FILO Rules (Recovery)
  • Node Bandwidth Rules (Recovery)
  • On ‘ transition to online’ Rule for recovery publishing

 

Example:

A remote client is subscribed for COS data associated with a process variable monitored by a CAS Gateway (CASgw). Each time that the monitored process variable changes by its ‘delta’ rule a COS event is queued. As the CAS Gateway (CASgw) processes the queue it applies the node bandwidth publication rules ensuring that the remote node is not swamped Now the connection is lost. Events are queued. Now the connection is re-established. The CAS Gateway (CASgw) processes the queue applying the recovery rules. In this case the recovery rules may say that the subscriber node is only interested in the current state or the subscriber node may want all messages so that it can track the change of state for its data log application.

 

Node Status Monitoring

Customer client applications are often Change of State Data Subscribers. This often makes them passive clients and as such they don’t know whether a remote server node is disconnected / failed or whether there haven’t been any events to publish.

There are several solutions to this problem.

  • By getting the client to poll each remote server node on a periodic bass the client can report the status of the connection to the remote node. This is possible if the client is an application like NetCool from Micromuse as well as for most other client applications.
  • By configuring a heartbeat monitor in the client. The client watches for published data which contains a heartbeat from each node. If the heartbeat stops updating the client can report the connection to that node as having failed.
  • By having an independent client node monitor the remote server nodes and having a direct connection between the front end client the monitor node it is possible to relieve the client of extra work and only monitor a reduced point list from the monitor node.

In the diagram below a monitor node has been added. The node plays two roles. Firstly is polls for a single data element from each remote server node. If the connection to a node is lost the MMI can report this by monitoring the node status as made available in the monitor node. Because the MMI client and the monitor node are on the same network they are not subject to the connection problems that can occur with the remote server nodes. In addition the monitor mode can act as a responder to periodic polls from each remote server node. This allows the remote server nodes to ‘know’ if they still have a connection to their subscriber.

monitor-client

 

Version Info

Date Rev By Notes
2014Mar 1 PMC Work in progress to SWS

 

Types of Pressure Sensors

Pressure Transducers

Pressure sensing based upon diaphragm technology measures the difference in pressure of the two sides of the diaphragm. Depending upon the relevant pressure, pressure sensors have been classified into following three categories:

  1. Absolute pressure sensor: It measures absolute pressure using a vacuum as a reference point.
  2. Gauge sensor: It measures pressure by reference to the ambient atmospheric pressure. “Gauge” pressure is defined relative to atmospheric conditions.
  3. Differential pressure sensor: It measures the pressure difference between two contacts or ports. Differential pressure transducers are frequently employed in flow measurement where they are used to measure the pressure difference across a venturi, orifice, or other type of primary element. The detected pressure differential is related to flowing velocity and as a result to volumetric flow. Many features of modern pressure transmitters have appeared from the differential pressure transducer.

Pressure Gauge

It is normally referred to as a self-contained indicator which can transform the detected process pressure into the mechanical motion of a pointer. A pressure transducer might join the sensor element of a gauge with a mechanical-to-electrical or mechanical-to-pneumatic converter and a power supply.

Performance Characteristics

  1. Accuracy: “It refers to the degree of conformity of the measured value to an accepted standard. It is usually expressed as a percentage of either the full scale or of the actual reading of the instrument. In case of percent-full-scale devices, error increases as the absolute value of the measurement drops”.[1]
  2. Repeatability: It refers to the closeness of agreement among a number of successive measurements of the same variable.
  3. Linearity: It is a measure of how appropriate the output of transducer increases linearly with increasing pressure.
  4. Hysteresis error: This characteristic explains the phenomenon according to which the same process pressure results in different output signals depending upon whether the pressure is approached from a lower or higher pressure.
  5. Sensitivity: It determines the amount of variation that occurs in the output voltage as and when the input voltage varies, keeping in view that the measured pressure and the rated pressure of the transducer remains constant.

In industrial applications, good repeatability is considered more significant as compared to absolute accuracy. For pressure variations over a wide range, transducers with good linearity and low hysteresis are the ideal choice.

Limitations

  • Ambient and process temperature variations cause errors in pressure measurements, mainly in detecting low pressures and small differential pressures. For these applications, temperature compensators can be employed.
  • Power supply variations also affect the performance of pressure transducers.

Maintenance and Calibration

Pressure sensors call for scheduled, periodic maintenance and recalibration without any exemption. It is obligatory to periodically remove the transducer from the process for the maintenance purpose. It should be ensured that this procedure does not require shutting down the process and does not cause any injury or damage. Since the process fluid may be toxic, corrosive, or otherwise noxious to personnel or the environment, it is essential to guard against the release of such fluids during maintenance.
Pressure transducers can be recalibrated on-line or in a calibration laboratory. Laboratory recalibration is usually chosen over the other one. In the laboratory, there are generally two types of calibration devices:

  1. Deadweight testers: They provide primary, base-line standards,
  2. “Laboratory” or “Field” standard calibration devices: These are periodically recalibrated against the primary. These secondary standards are less accurate than the primary, but they provide a more convenient means of testing other instruments.

Modbus BACnet Protocol Gateways

Load Cell

Load Cell is a specific type of transducer or sensor capable of transforming force (load) into a measurable electrical output. Load cells measure tension, compression, or shear. A typical load cell device comprises of four strain gauges in a Wheatstone bridge configuration.

 

Working

Force conversion into an electrical signal by a load cell is usually carried out indirectly and in two stages. The first stage conversion is done through a mechanical arrangement in which the force being sensed deforms the strain gauge. This strain gauge then converts the deformation (strain) to electrical signals. One can also get load cells with one or two strain gauges. The electrical signal generated by strain gauge is in the order of a few millivolts which needs further amplification by an instrumentation amplifier. The output of the transducer is fed to an algorithm calculator to calculate the force applied to the transducer.

 

Classification of Load Cells

Load cell designs are classified on various bases. They are classified according to the

Type of output signal generated

  • Pneumatic
  • Hydraulic
  • Electric

Way they detect weight

  • Compression: Compression load cells measure a pushing together force along a single axis
  • Tension: Tension load cells measure a pulling apart force along a single axis
  • Shear: Shear load cells measure the displacement of a structural element to find out force. Shear cell types for load sensors include shear beam, bending beam, or single point bending beam.

 

Hydraulic Load Cells

Hydraulic load cells are also referred to as hydrostatic load cells. These are mainly used in industrial applications. These are force -balance devices, measuring weight as a change in pressure of the internal filling fluid. They give linear output reasonably unaffected by the amount of the filling fluid or by its temperature. Accuracy can be achieved within 0.25% full scale or better, provided the load cells have been correctly installed and calibrated. This range of accuracy is suitable for most process weighing applications. Since this sensor has no electric components, it is perfect for use in hazardous areas. Typical hydraulic load cell applications include tank, bin, and hopper weighing. These load cells can eliminate troubles encountered with strain gauge load cells. Hydraulic load cell is probably the best load cell to use in an outdoor environment because it is immune to transient voltage (lighting).

Pneumatic Load Cells

Pneumatic load cells also work on the force-balance operating principle. These devices make use of multiple dampener chambers to offer higher accuracy as compared to a hydraulic device. In several designs, the first dampener chamber is utilized as a tare weight chamber. Pneumatic load cells are frequently employed to measure moderately small weights in industries where cleanliness and safety are principal concerns.
Advantages

  • Inherently explosion proof
  • Insensitive to temperature variations
  • They contain no fluids hence there is no chance of contamination of the process if the diaphragm ruptures.

Disadvantages

  • Comparatively slow speed of response
  • Need for clean, dry, regulated air or nitrogen

Strain-gauge Load Cells

Strain-gauge load cells are bonded onto a beam or structural member which gets deformed when weight is applied. In majority of the cases, four strain gages are employed to achieve maximum sensitivity and temperature compensation. Two of the gauges remain generally in tension, and two in compression, and are wired with compensation adjustments. When weight is applied, the strain changes the electrical resistance of the gauges in proportion to the load.
Advantages: As compared to other load cells strain gage load cells offers more accuracy and lower unit costs. Although there are several varieties of load cells available, strain gauge based load cells are the most widely used type.

Piezo-electric Load Cells

In these types of load cells a piezoelectric material is compressed which then generates a charge that is conditioned by a charge amplifier. It is valuable for dynamically measuring force. Geomechanical applications entail vibrating wire load cells owing to their low amounts of drift. All load cell rings when they are subjected to an abrupt load change and this is caused by the spring like behavior of the load cell.

Selection of a Load Cell

Following points must be kept in mind while selecting a proper load cell:

  1. It is crucial to decide whether one wants a tension or a compression load cell. A tension load cell measures the amount of weight pulling it, whereas a compression load cell measures the weight by pushing against it. A compression load cell is generally placed beneath the object that needs to be weighed. Keeping all this in mind, one can easily choose an appropriate load cell.
  2. The number of cells should be decided based upon the number of supports used. In ideal situations, each support should have a load cell and this is more essential if the weight is not equally distributed between the supports.

Modbus Bacnet gateways

Communication Data Loss

Data loss means unanticipated loss of data or information. A number of techniques are available in communication systems to ensure that receiver sees all of the transmitted data and that data arrives without errors. Following are the major ways to ensure an error free transmission:

  1. Flow control
  2. Buffering
  3. Use of polling or interrupts to detect received data
  4. Acknowledging received data
  5. Error checking