Basic BACnet: objects and properties

Hard to believe it's been over 13 years since my article "The Language of BACnet" was published (available on the BACnet.org website), but here we're revisiting that material again, though a bit more briefly and in this blog post I will only cover BACnet Objects and Properties, leaving Services for a subsequent posting.

In this posting we will focus on how data is presented over the networks to other devices by the application program. In some protocols data may be fetched simply by a number (e.g. "Give me data item #37"), but one has to know beforehand what one is asking for: what its datatype is (is it an integer, a floating-point number, or a string of text?), and what it represents (is it a status indicator, a message, a measure value?). Such protocols are easily implemented on controllers with very little memory, but configuring systems using them takes a bit of work.

BACnet, on the other hand, uses a self-descriptive system called "objects and properties." Very roughly, an "object" represents some aspect of the device. For example, an "Analog Input" object could represent a temperature or air velocity sensor. A "Binary Output" object might control a relay. A "Multi-state Output" might be a fan speed control -- off, low and high. A "Calendar object"... well, we'll look at the various kinds of BACnet objects later.

A general rule is that an object presents some element of a building automation system, including I/O, schedules, issuing alarms, trendlogging data values, downloading and executing user-created programs and so on. Often the object is "centered" on a data value as in the example here, where a thermometer input is represented by an Analog Input object and that data value is presented in a "property" of the object called "Present_Value" (in the drawing just "Value"). Of course, that number is useless by itself because we don't know the units -- it could be degrees Fahrenheit, Celsius, Kelvin or Rankine. (Does anyone use Rankine?) So we need another property called, of course, Units. Part of the object's self-description is to advertise its object type in yet another property (shown here as "Type" but actually called Object_Type").

Every object in a device is uniquely identified by its type and "instance number" (Binary Value 0, Binary Value 1, ..., Binary Value 9999). But it can also be uniquely labeled through either the Object_Name property or the Description property, both of which hold text strings though the former property is required and the latter is optional (a decision to be made by the implementer of the device).

Required versus Optional: BACnet establishes a minimum set of properties for each object type, but defines additional properties that can be included if certain additional capabilities are supported. For example, if one wants to issue alarms for a temperature being out of range one can add a set of properties that include the range limits, as shown here.

The following table (from "The Language of BACnet" article) shows the full set of defined properties for the Analog Input object, (at least as it was in 1996; properties have been added since then):

A property of an object is accessed, for reading or writing, by sending a message that says, for example: "Tell me the value in object Analog Input 1's Present_Value property." If that object is the on in the table, the answer would say: "the value in object Analog Input 1's Present_Value property is 68.0".