1.0 Introduction

[an error occurred while processing this directive]

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.

BACnet 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. BACnet 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.

2.0 A simplified definition of BACnet 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.

3.0 Not all devices / objects support COV

The BACnet 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.

4.0 How COV Works

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

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.

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,

5.0 Key Elements of the COV Technology

COV Server:
A BACnet device that supports COV, accepts subscriptions and sends COV notifications messages to a COV Client.

COV Client:
A BACnet 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
  BACnet 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.

[an error occurred while processing this directive] 6.0 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 Multi-state 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

7.0 Discussion and Limitations of COV

7.1 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.

7.1.1 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 BACnet 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.

7.1.2 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.

7.2 Specific Limitations of BACnet COV

7.2.1 Subscriptions may be lost on reset
The BACnet 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.

7.2.2 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.

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

7.2.4 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.

7.2.5 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 a 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.

7.2.6 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.

8.0 Read more

Additional information on BACnet may be found at www.chipkin.com/articles

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]