BACnet COV - Change Of Value

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

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.

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

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

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.

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 bandwith 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 do not 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 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.

7.2.6 Notifications can be sent without a change of value

The criteria for triggering notification messages require 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 several data client systems ignore this element of the notification data.