In today’s blog, we continue in the process of releasing freshly translated blog posts by Peter Humaj. The last two blog posts were focused on the Modbus protocol. The upcoming blog posts will create a BACnet series consisting of three articles dedicated to the protocol. The first part of the series will introduce basic information about the protocol, the protocol routing and device modeling.

The BACnet communication protocol is a very interesting and flexible protocol. Subjectively, this is the most complex and extensible protocol I have encountered in practice. At the same time, this is nothing new in terms of time of creation or protocol implementation in the D2000 real-time application server. Let's look at it with regard to its features, usability, and issues that its users may encounter.

Introduction to BACnet

The BACnet protocol already has a target area of use encoded in its name. BACnet stands for Building Automation and Control networks, which includes systems such as HVAC (Heating, Ventilation, Air Conditioning), lighting, access control, fire systems - in short, building automation systems.

BACnet is an open protocol that is being developed since 1987 by the ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers). It has become the ASHRAE/ANSI standard no. 135 in 1995 and ISO standard 16484-5 in 2003.

What makes it interesting and what are its characteristics?

Media

Physical layer: BACnet is supported on several combinations of physical/line media:

·         ISO 8802-3 ("Ethernet") LAN - this means "plain" Ethernet without the                 TCP/IP layer

·         BACnet/IP - communication is wrapped in UDP packets

·         ARCNET - LAN network popular in the 80s

·         MASTER-SLAVE/TOKEN PASSING (MS/TP) LAN - serial communication on           RS485

·         POINT-TO-POINT (PTP) - e.g. modems or RS-232 interfaces

·         LonTalk LAN (LonWorks)

At the beginning of the implementation of the BACnet protocol in D2000 (the year 2005), most of the communicated devices were equipped with a LON interface. Later, BACnet/IP devices began to predominate. MS/TP is rare (I know of one microwave dryer of the customer and at least one OEM partner has such communication up and running). The other media mentioned above are not supported by D2000 yet.

Protocol routing

The BACnet protocol allows specifying the Source network, Destination network, and Destination Address parameters in the packet. Thus, it supports protocol-defined message routing - i.e. also between different types of networks. There are devices - BACnet routers - equipped with multiple communication interfaces and capable of routing BACnet messages. An example is the Siemens Desigo PXG80-N, which is a BACnet router with both Ethernet and LonTalk interfaces, used to connect BACnet devices on the LonTalk network to other devices (e.g. the superior SCADA system) on Ethernet.

Device modeling

BACnet models physical devices as a collection of objects of different types (an object type is a 10-bit number). Object types are defined by the standard and the list is gradually being extended in newer versions. Types 0-127 are reserved for use by the standard, the manufacturers can use higher types (128-1023) for their own definitions.

A particular object has its type (e.g. Analog Input) and its instance (22-bit number). The combination of object type and instance (10+22 = 32-bit number) is sufficient enough to identify the object in the BACnet device and is used in all operations on the object.

Each physical device contains exactly one Device (8) object. The standard in the appendix also states that there is the possibility of multiple "virtual" Device objects, but in that case, the device must look like a router and all "virtual" Device objects pretend to be on other networks (and are available via addressing containing a unique combination of Destination network and Destination Address).

Each object type has attributes (properties) of different types. For each type of object, the standard defines a list of attributes together with the specification of whether they are intended for reading (Read) or also for writing (Write) and whether their implementation is optional (Optional). As with object types, the standard reserves attributes 0-511 and above for the manufacturers, so they can implement a non-standard attribute to standard object types (e.g. Analog Input) that makes sense in the context of a specific device (in the case of Analog Input, you can imagine, for example, various statistics for the last minute/hour - average, maximum, minimum ..). The configuration dialog of measured points in the D2000 system allows you to select both the object type and the attribute from a predefined list, or they can be entered directly (object type number/attribute number), which enables addressing the manufacturer-defined object types and attributes.

The next part of the BACnet series will focus on the supported ways of reading values in BACnet.