BACnet - Brief Introduction to the Basics Part 5

COV - Change of Value

COV, or Change of Value, is a mechanism by which network traffic is optimized. In general, the client would like to have the most up-to-date data from the server. This would mean that he would have to query variables over and over again, and would most likely receive the same values as in previous queries, because the values of the variables usually do not change as often. At the same time, it would burden the network and the server with unnecessary queries.

Therefore, BACnet allows you to use the COV service. It is not a mandatory function, each manufacturer decides whether to support it or not. If the client wants to use the COV service, it sends a subscription request to the server to subscribe to reports that the value of a property of an object has changed. The server receives it, registers the client and sends a message to the client when the appropriate value changes. Therefore, the client does not have to inquire periodically, it is just waiting for information about the change, the so-called notification. This should reduce the frequency of queries while increasing the speed of transfer of changes from the server to the client. If the client is no longer interested in the update, he can cancel the registration - for example, if the user switched to another page in the visualization or left the menu on the control panel.

Upon registration, the client will also request whether the notification should be unconfirmed or confirmed. For an unconfirmed server, it sends data and does not determine if the client has received it. This means less load for both the server and the network, but the information may not reach the client. When the notification is acknowledged, the server expects the client to acknowledge receipt of the data. If this does not happen within a certain time (timeout), the notification is repeated. This means greater transmission reliability, but at the same time a greater burden on the network and both participants in the communication.

Fig. Successful application for COV registration

The figure above shows a communication listing in which in packet 45 the client requests a COV registration for the Analog Input 0 object. In packet 46, the server acknowledges this registration (Simple-ACK) and then sends the first notification in package 47 with the property values of this object. We see that this is an unconfirmed notification - another packet, 52 and beyond, is already dealing with the reading of another object, Analog Input 4.

If a confirmed notification is registered, the client, after receiving it, responds to the server with a confirmation message: in packet 14 the server sends the current values immediately after registration, in packet 15 the client confirms this notification:

Fig. Notification confirmation

On the contrary, the following figure shows a situation where the server does not support the COV service and rejected the registration request (Reject: Unrecognized Service). The client then no longer resolves the COV and periodically reads the current value of the Analog Input 4 object using the Read Property service.

Fig. Rejected application for COV registration

How does the server determine when to send a notification? For binary or multistate (integer) variables, it is clear when the change occurred: instead of True, False or vice versa, the integer is at least 1 larger or smaller. However, for variables of the real type, it must be determined how much change is to be considered significant enough to trigger a notification (sending a notification at the slightest change in analog value would probably burden the line even more than regular polling without COV). The COV Increment parameter is used for this.

This is a mandatory property for objects that support COV. Therefore, the notification is sent only if the value change since the last notification is greater than the COV Increment.

COV Increment has the server set as a reasonable default value, but it can also be specified by the client as an optional parameter in the registration request. For values such as temperature, a typical COV Increment is 0.1 ° C.

The application for registration contains, among other things, the identification of the object whose data the client is interested in and the time for which the registration is to last. After this time, it is assumed that the server deletes the registration so that it does not unnecessarily keep the old, no longer current in the registration memory. On the contrary, the client should renew the registration periodically, preferably in advance.

Examples of registration times and renewal periods for some clients:

Tab. Examples of COV timing

However, the BACnet standard does not specify what the longest required registration time can be for a client (it can also be "infinity"). If the server supports COV, it should accept a registration time of at least 8 hours. However, it is not prescribed that the server would have to maintain registrations even after a power failure. Although the server can store registrations in memory, which is not deleted when restarted, but then there is a risk that a large number of registrations for an infinitely long time will fill its memory over time - so it is necessary to define rules for periodic memory cleanup. Therefore, situations may occur when, for example:

• the client successfully requests registration, for example, for 12 hours, after a few minutes the server is restarted, while the registrations are deleted. The client lives in the belief that it would receive notifications, however, it does not receive information about new values,
• the client registers without confirmation a large number of values ​​for a long time, after which a situation occurs in the server when a large number of changes occur suddenly (short-term power failure, closing hundreds of fire dampers, etc.). The client is not able to process incoming changes and data may be lost,
• clients register a large number of values, but do not cancel the registration - the server must either allocate enough memory to store all requests or eventually begin to reject new requests.
• etc.

We must take these properties into account when designing networks and considering the reliability of communication. It always depends on how good the implementation of BACnet in a given device is.