The Building Automation Control Network (BACnet) protocol is not new to building management systems. Its development began in 1987, in 1995 it became the ANSI/ASHRAE standard and in 2003 it was standardized in ISO 16484-5. In process stations, however, it appears only gradually, especially for its not quite easy implementation. As with any communication protocol, the creators were looking for the optimum point between a quick and cost-effective implementation on a variety of hardware types and a simple, understandable application in practice. Thus, unlike relatively simple communication protocols such as Modbus, a number of services and objects are defined in BACnet that make it easier for application engineers to work in programming and commissioning technologies.
If we want to get acquainted with the BACnet protocol from the PLC programmer's point of view, a complete description of the standard, which has more than 1300 pages in the 2016 edition, would probably discourage us. Norm makes more sense for a beginner as a reference book than a textbook. Let's look at BACnet as a measurement and control technician, who is not so interested in the particular form of telegrams, but rather in the relationship of BACnet to the concepts we know from the PLC world.
BACnet uses the client-server model, so we must always distinguish whether certain hardware works as a BACnet client or a BACnet server. It is possible for one device to support both functions, but this is not common - except for programmable PLCs. To put it simply, the server contains objects, the client reads it and writes into it.
The BACnet server contains data in the form of objects. BACnet defines 60 standard object types, such as an analog value, a time program, a trend log, or a group of lifts. Some objects, as we can see, have a clear link to building management. A BACnet object is a structure that has several BACnet properties. A property is basically a variable that is of a defined type, has a name, and takes some value. To distinguish objects of the same type within the device, each has a unique Instance Number. Thus, the unique identification of an object on a device consists of the object type and its instance number. Assuming a BACnet input module with 8 analog inputs, it will most likely contain Analog Input 1 to Analog Input 8 objects. The objects are grouped in a "container", a BACnet device. There can only be one object of this type in a hardware device, such as a PLC. The device also has some features. These define communication options in particular, and the BACnet client reads them first to know how to communicate optimally with the server.
Fig. Device object properties
The table is a screenshot of the BACnet client, the Yabe program, which is used as a BACnet device explorer. The program found the BACnet server on the network and read the BACnet device and its properties. Property names are in the left column, their values in the right column. One of the properties is Local Time, its value says that the real-time clock in the BACnet server shows 13:36:03. Later we will see that some features are required by standard, others are optional - even if the device does not, it still complies with the standard. Some properties may be required only under certain conditions: For example, the Local Time property is only required if the device contains a real-time clock.
An important property of the device is the Object List property. It is a list of all the objects that the device contains and which the client can then query. The table shows a part of the list of objects with their object types and instance numbers. For example, it is clear from indexes 4 and 5 that the device contains, among other things, two Binary Output objects with instance numbers 1 and 2. This is enough for the client to ask them in other queries and have their properties listed.
Even the properties are standardized. The norm specifies nearly 500 of them. Each property has its own text identifier, property identifier, as well as a number: for example, the most commonly used property of the object, present value, which, for example, bears the measured temperature at the temperature sensor, is 85. The table shows the standardized properties of the Analog Value object:
Fig. Properties of the Analog Value Object Type. Source: ISO 16484-5, (C) ISO 2016
The table shows the name of the property (eg Present Value), its type (here REAL) and whether it is a read-only (R), read-only and writable (W) or optional (O). The property numbers in the table are not listed, but it is good to know because many visualization programs allow you to set the used property by number to define the data points - it is probably easier than a long drop-down box with hundreds of properties (which would still lack of specific features that manufacturers can define arbitrarily, see below). Notes for optional variables - superscripts - specify the conditions under which, for example, optional properties become mandatory, limit their ranges, etc.
Variable types are either simple, such as Real, CharacterString, Boolean, Enumerated, etc., or BACnet-specific - for example, BACnetPriorityArray. Their detailed description would be found in the norm, we will not deal with it now.
Equipment designers can define their proprietary properties in addition to the object standard. These are used, for example, to define the location of an object in a hierarchical structure (tree) so that clients can display variables in a structured way by technology, and not just all of them clearly below each other.
Fig. Proprietary properties. Source: BACnet Browser Test Sequencer User’s Manual, (C) Siemens
According to the standard, Property ID numbers up to 511 are reserved for standard properties defined by the standard, numbers from 512 above can be used for specific, custom properties. In the figure above, we see properties with Property ID (first column) of 3000 and above. These are typical of Siemens implementation.
So we have a device containing objects. But how to read them? This is what BACnet thinks about and defines so-called services. They are actually standardized functions for working with data - they determine the format of queries and answers. Some services have somewhat bizarre names, such as Who-Is, I-Am, Who-Has, I-Have - these are used to detect and explore devices and objects. For others, the function is evident from the naming: Read-Property and Write-Property are obviously used to read and write individual properties in objects. Services are not so interesting to us, they are more important for driver programmers than for application engineers. However, their names appear in the Wireshark listing, so it is useful to know them as we will see later.
There are about 40 services and in addition to working with variables, it also solves functions such as alarm acknowledgment, time synchronization, dynamic creation and deletion of objects, as well as file transfer or data transfer using a terminal. File transfer can be used, for example, to play an application program. In the next section, we will try using services to explore the objects that are contained in the device.