Ways of reading values

BACnet supports two ways of reading values:

·   a ReadProperty request is used for one-time reading of a selected attribute of a specific object (polling).

There is a ReadProperty-Multiple variant, which is used to request multiple attributes of different objects by a single request.

·   a request of the SubscribeCOV (COV = Change Of Value) type is used to subscribe to changes in the selected attribute of a specific object. The BACnet client, thus, notifies the BACnet device that it is interested in receiving notifications. The SubscribeCOV request is valid only for the period specified in it and must then be renewed. By default, the BACnet device responds by sending an acknowledgment and the current value (specialty: the specific Saphire Communication Controller we met sent the value of the object only after the change, so there is a station parameter Read value after subscribe, which causes a ReadProperty request to be sent to determine the current value).

There is a SubscribeCOVProperty variant that allows changes to be sent only if they are greater than the specified value (i.e., setting the filter directly on the source). It is up to the manufacturers, whether and for what types of objects (and their specific attributes) they support the method of reading using SubscribeCOV or  SubscribeCOVProperty.

Notifications are an implementation of the on-change method of sending changes and have a smaller overhead for the client, server, and network than periodic readings by polling. Notifications may be either unconfirmed or confirmed. Acknowledged notifications require the BACnet client to send an acknowledgment of receipt to the BACnet device (e.g. in the case of critical building security systems, fire detectors, etc.). Unconfirmed notifications could be lost, on the other hand, they have a smaller overhead.

What types of values does BACnet support? Before we can answer this question clearly, let's explain what BACnet messages look like.

All message data elements are called tags in the BACnet protocol. There are two types of tags:

·   application tags - their type is strictly fixed - they are primitive (basic) data types

·   context tags - their type depends on the definition of the message in which they occur

The BACnet standard describes messages in ASN.1 syntax, which allows relatively clear and easy-to-read symbolic notation of data structures. In this syntax, an application tag is specified by a type and a context tag is a number in square brackets and a type. Tags are organized into sequences (keyword SEQUENCE).

The strength of the BACnet protocol is the variability of messages - various methods of specification visible in Figure 9, optional parameters, sequence repetition. Arrays are supported as well.

Now that we know what the message specification looks like, we can have a look at the messages that are used to read the attribute value.

We can see that the request is straightforward - it specifies the object identifier by using context tags, the attribute identifier, and optionally the index in the array  (if it is an array attribute). The answer contains the same tags as well as a value. But it is of the ABSTRACT-SYNTAX.&Type type. What does it mean?

In human speech, it means "anything could be here." Okay, but how are we going to parse it? How can a client process a message that contains "anything"?

The key to an answer is again ASN.1, or the encoding of ASN.1 tags in binary format, which is used in BACnet protocol. The encoding of each data element of the message contains a TLV triple -Tag (a number and a flag, whether it is context tag or application tag), Length (length of data), and Value (data itself). The start and the end of the sequence (and its tag) are also captured in a binary format. In this way, the BACnet client can process a response containing any structure. The only problem is that if the data element is a context tag (e.g. [2] with a length of 4 bytes), then additional information is needed on how to interpret its value (it can be Unsigned, Signed, Real, Character String, BACnetObjectIdentifier and others).

If the message does not contain simple data (whether application tagged or context tagged), but a structured "anything", the configuration dialog of the measured point allows entering the so-called complex address and specifying which item of structured data will be assigned to the measurement point.

Figure 11 shows a measured point with a complex address [1].3.2.[1]. This means that the received data is first searched for context tag no. 1 (a sequence is expected), then within this sequence the third tag in the sequence (again the sequence must be found) and in it the second tag in the sequence (again the sequence) and finally in this last sequence the context tag 1. Since it is a context tag, it is necessary to use the Application tag parameter (in the figure just above the complex address) to specify that it must be interpreted as a real number (Real).

A specific case of the implementation of a complex message containing structured data is an object of schedule type(17) implemented in the Siemens Desigo PXC64-U device used to create time schedules. When reading the weekly-schedule attribute (123) with array index 1 (the Array configuration parameter), the D2000 KOM parsed the received response as follows:

The value (propertyValue) contains a sequence in which there are alternating time and a positive value. The complex address for accessing the first time would be 1.1, the first value would be 1.2, the next time and the values 1.3 and 1.4. The context tags would not be used because the sequence and all values nested within the propertyValue sequence are application-tagged.

The read value represents the value of a time schedule for the first day of the week (hence the Array index mentioned above). The time/value pair indicates at which hour the schedule is to be changed to the desired value (which can, for example, represent the heating level). If we read without the array index, we would get a propertyValue containing seven sequences, one for each day of the week.

This implementation of the weekly-schedule attribute complies with the BACnet standard, which specifies the weekly-schedule attribute as an array of seven BACnetDailySchedule items:

The BACnetDailySchedule type is a sequence of BACnetTimeValue, which is a sequence of time and values:

It is important to realize that according to the note in the standard definition, the value field can be of any primitive type - so a different manufacturer (or Siemens on another device) can implement the weekly-schedule attribute using a type other than Unsigned. And really, e.g. Delta Controls DAC-1146 implements a schedule based on 0/1 values ​​(i.e., it does not specify, e.g., the heating level but only the heating/not-heating information), which are implemented not as Boolean(1) but as Enumerated(9) data type. The reason may be scalability and backward compatibility in the future (support for multilevel time-schedules).

The BACnet protocol allows manufacturers to define their own types of objects, in which their own attributes and the values ​​of these attributes do not have to be simple, but arbitrarily complicated and nested structures. The client implementation can parse them - if  the context tags are used, it is necessary to specify the primitive data type of a particular tag. No other protocol we have encountered offers a similar level of flexibility.

The D2000 KOM process supports the reading of the entire structured value to a single measured point. If the point is configured as a text input (TxtI) without specifying the Application tag parameter, the complex value displayed in Figure 12 (sequence of three time-value pairs) is written as a text value "{ T0:0:0; u2; T4:0:0; u3; T22:0:0; u1 }".

The T character indicates that a value of type Time follows, the character u that a value of Unsigned type follows (other data types are described in D2000 help), the curly brackets delimit the sequence. For a specific case (a time-schedule), this method is more suitable, because each of the seven days of the week can contain any number of time/value pairs. Therefore, it is generally not appropriate to index them using a complex address, but it is better to read the entire schedule (or its individual days) into a text measurement point and then parse it in an ESL script and display it to the user in table for editing.