The Language of BACnet - Objects, Properties and Services
Alerton Technologies, Inc.
Automation and Control Network) is the open data communications protocol which
has been developed over the past nine years by ASHRAE. In December of 1995,
BACnet was adopted by ANSI and is now an American National Standard (ANSI/ASHRAE
135-1995) and is under review by the International Standards Organization (ISO).
BACnet was created to end the frustration caused by the inability of proprietary
control systems to communicate with other systems within a building or other
BACnet provides the method by which computer-based control equipment from
different manufacturers can work together, or "interoperate." It allows
you to expand, mix and match equipment to better fit any size of building's
needs for the present and future. BACnet is designed to handle many types of
building controls, including HVAC, lighting, security, fire, access control,
maintenance, waste management and so forth.
BACnet provides a sophisticated model for describing building automation
systems of all types. This model is based on the ideas that for systems to be
truly interoperable, there must be agreement about various aspects of the
overall operation and the individual systems themselves. For the equipment to
work together, components must be able to exchange and understand BACnet
messages. BACnet specifies four types of local-area networks and a serial
(EIA-232) interface along with networking protocols to get the messages from one
device to another. The content of the messages, the BACnet language, is the
focus of the major portion of the BACnet standard.
BACnet departs from traditional industry conventions with
its object-oriented nomenclature. The industry has long used the general-purpose
term "points", which could refer to sensor inputs, control outputs or control
values, with different characteristics according to manufacturer. BACnet instead
defines a standard set of "Objects", each of which has a standard set of
"Properties"; that describe the Object and its current status to other
devices on the BACnet internetwork. It is through these properties that the
Object may be controlled by other BACnet devices.
One of the standard BACnet objects is the Analog Input Object, which
represents an analog sensor input such as a thermistor. Figure 1 shows a diagram
of just such an Analog Input Object as it might be seen over the network through
five of its properties. Some of the properties-such as Description, Device_Type
and Units-are set during installation. Others, including Present_Value and
Out_Of_Service, provide status about the sensor input represented by the Analog
Input Object. Yet others (an Analog Input Object can have up to 25 Properties)
may be set by the equipment manufacturer. All may be read; in this example, a
query about the Present_Value Property of this Analog Input Object would get the
Figure 1. An Analog Input Object.
BACnet defines 18 standard types of Objects, listed in Table 1. The list is
intended to be comprehensive; each element of a complete building control system
is represented by one or more of the Objects, whether Analog Input for a sensor,
a Schedule for scheduling, or Notification Class for distributing alarms.
The choice of which Objects are present in a BACnet device is determined by
the device's function and capabilities. The BACnet standard does not require all
Objects in all BACnet devices. A device that controls a VAV box is likely to
have several Analog Input and Analog Output Objects while a Windows® workstation
that has neither sensor inputs nor control outputs will not.
Every BACnet device must have a Device Object, the Properties of which fully
describe the BACnet device to the network. The Object_List Property of the
Device Object, for example, provides a list of every Object contained within the
BACnet device. The Vendor_Name, Vendor_Identifier and Model_Name Properties
provide the manufacturer name and model of the device.
In addition, BACnet allows manufacturers to provide proprietary Objects,
which will not necessarily be accessible or understood by equipment from other
manufacturers. However, they will not interfere with standard BACnet objects.
Table 1. Standard BACnet Objects.
||EXAMPLE OF USE|
||Setpoint or other analog control system parameter|
||Binary (digital) control system parameter|
||Defines a list of dates, such as holidays or special events, for
||Writes multiple values to multiple objects in multiple devices to
accomplish a specific purpose, such as day-mode to night-mode, or
||Properties tell what objects and services the device supports, and
other device-specific information such as vendor, firmware revision,
||Describes an event that might be an error condition (e.g., "Input out
of range") or an alarm that other devices to know about. It can directly
tell one device or use a Notification Class object to tell multiple
||Allows read and write access to data files supported by the
||Provides access to multiple properties of multiple objects in a read
||Provides standardized access to a "control loop."|
||Represents the status of a multiple-state process, such as a
refrigerator's On, Off, and Defrost cycles.|
||Represents the desired state of a multiple-state process (such as It's
Time to Cool, It's Cold Enough and it's Time to Defrost).|
||Contains a list of devices to be informed if an Event Enrollment
object determines that a warning or alarm message needs to be sent.|
||Allows a program running in the device to be started, stopped, loaded
and unloaded, and reports the present status of the program.|
||Defines a weekly schedule of operations (performed by writing to
specified list of objects with exceptions such as holidays. Can use a
Calendar object for the exceptions.|
The BACnet standard identifies 123 different Properties
of Objects. A different subset of these Properties is specified for each type of
Object. The BACnet specification requires that certain Properties must be
present for each Object; other specified Properties are optional. In either
case, the implemented Properties have specific behaviors defined by the
specification particularly those involved in alarm or event notifications and
those that have an effect upon control values or states.
A few of the standard Properties are required by the BACnet specification to
be writable while others may be writable at the manufacturer's discretion. All
may be read over the network.
BACnet does allow vendors to add proprietary Properties but, as with
proprietary Objects, the proprietary Properties may not be understood or
accessible by equipment from other manufacturers.
The Analog Input Object is representative of the Objects involved directly
with control elements and many of its Properties reflect this. Table 2 lists the
defined Properties of the Analog Input Object, along with typical or example
values for each property. For example, the Status_Flags, Event_State,
Reliability, Out_Of_Service, Min_Pres_Value, Max_Pres_Value, Notification_Class,
High_Limit, Low_Limit, Limit_Enable, Event_Enable, Acked_Transitions and
Notify_Type Properties all deal with the detecting of unusual and possibly
dangerous conditions at the sensor and generating the appropriate notifications
or alarms in response.
Table 2. Properties of the Analog Input Object.
||Analog Input #1|
||"Outside Air Temperature"|
||In_Alarm, Fault, Overridden,
||Normal (plus various problem-reporting states)|
||No_Fault_Detected (plus various fault conditions)|
||-100.0, minimum reliably read value|
||+300.0, maximum reliably read value|
||Notify if Present_Value changes by increment: 0.5|
||Seconds to wait before detecting out-of-range: 5|
||Send COV notification to Notification Class Object: 2|
||+215.0, Upper normal range|
||-45.0, Lower normal range|
||Enable High-limit-reporting, Low-limit-reporting.|
||Enable To_Offnormal, To_Fault, To_Normal change
||Flags indicating received acknowledgments for above changes.|
||Events or Alarms|
The first three Properties listed-Object_Identifier, Object_Name and
Object_Type-must be present in every Object in a BACnet device.
The Object_Identifier is a 32-bit code that identifies the type of Object
(also identified by the Object_Type Property) and its "Instance" number,
which together uniquely identify the Object within its BACnet device.
Theoretically, a BACnet device could have over four million Objects of a
particular type. The Object_Name is a text string, which has a unique
capability. BACnet devices may broadcast queries for devices that contain
Objects with a specific Object_Name. This can greatly simplify project setup.
BACnet requires one Device Object to be present in every BACnet
device. The Device Object makes information about the device and its
capabilities available to other devices on the networks. Before one BACnet
device starts controls related communications with another, it needs to obtain
some of the information presented by the other device's Device Object. Table 3
gives an example of a Device Object for a BACnet Dual-Duct VAV controller.
Although the list of Properties is imposing, most are fixed by the manufacturer
and are read only by other BACnet devices.
Unlike other Objects, the Device Object's Instance number must be unique
across the entire BACnet internetwork because it is used to uniquely identify
the BACnet devices. It may be used to conveniently identify the BACnet device
from other devices during installation.
Table 3. Properties of the Device Object.
||"Office 36 DD Control"|
||Operational (plus others)|
||"Alerton Technologies, Inc."|
||"Office 36, Floor 3"|
||"(on network 5)"|
||1 (BACnet protocol version)|
||readProperty, writeProperty, atomicWriteFile,...|
||Analog Input, Analog Output,...|
||Analog Input #1, Analog Input #2, ...|
||50 (bytes or characters)|
||Tuesday, March 12, 1996|
||+480 (minutes from GMT/UTM)|
||False (not in effect)|
Services are the means by which one BACnet device
acquires information from another device, commands another device to perform
some actions, or announces to one or more devices that some event has taken
place. Each service request issued and service acknowledgment
(reply) returned becomes a message packet transferred over the network from the
sending to the receiving device.
An "application program" running on the BACnet device issues service
requests and processes them upon receipt. The application program is the actual
software that performs the operations of the device. In the case of an operator
workstation, the software might maintain a display of several sensor inputs for
the operator nad would periodically issue service requests to the appropriate
Objects in the target devices to obtain the latest value of the inputs. In the
monitored device, the service request would be processed in its application
program and the reply containing the requested data returned. This is depicted
in Figure 2.
Figure 2. Service Requests and Replies.
BACnet defines 32 Services and classifies them into five categories. These
Service categories are the Alarm and Event, File Access, Object Access, Remote
Device Management and Virtual Terminal Services. For each of the "Confirmed"
services (a reply, typically with data, is expected), labeled "C" in the
tables following, the BACnet device may have the ability to initiate the Service
request, or the ability to process and respond to a received request of that
type, or both. For each of the "Unconfirmed" (no reply is expected) services,
labeled "U" in the tables following, the BACnet device may have the
capability to initiate the Service request, or the ability to process a received
request of that type, or both.
BACnet devices are not required to implement every single Service. Just one
Service, ReadProperty, is required to be processed by all BACnet devices.
Depending upon the function and complexity of the device, additional Services
may be initiated or executed.
The Alarm and Event Services deal with changes in conditions seen by a BACnet
device including alarms. Alarms and events changes which might indicate problems
or error conditions, such as a sensor reading out of normal range or, for that
matter, returning to normal operation ("Events"); or a change in a reading (of
some increment since the previous report) termed "Change Of Value" or COV.
COV reporting is a useful alternative to repeatedly polling an Object for
some monitored value. A device containing a monitored Object could be subject to
network traffic congestion if many other devices were monitoring it; COV
reporting allows it to send out notices when a change occurs.
Alarm, Event and COV notifications are generated by the application program
monitoring Objects directly related to control operations: specifically, the
various Input, Output and Value Objects, as well as the Loop Object.
Table 4. Alarm and Event Services.
||Used to tell sender of alarm that a human has seen the alarm.|
||Tells subscribing devices of the COV that occurred in a
||Used to tell sender of a possible error condition.
||Requests from a device a list of "active alarms," if any.|
||Requests a list of "event" (possible error) generating objects.|
||Sent by a device to request that it be told of COVs in an
||Tells subscribing devices that a change has occurred to one or more
properties of a particular object.|
File Access Services in BACnet are used to read and manipulate files in
BACnet devices. In BACnet, files represent group databytes of arbitrary length
and meaning; they do not necessarily relate to any kind of mass storage device.
Every BACnet-accessible file has a File Object associated with it.
The word "Atomic" in the service name merely means that only one read or
write operation can take place at a time. Other attempts to access the file
during an access will either fail or be held off.
At present there are no standard BACnet-defined files; by definition, all
file accesses are vendor proprietary though BACnet has reserved the EVENTLOG and
VALUELOG file types for file structures to be defined at a later date.
Table 5. File Access Services.
||Requests part or all of a File object's file.|
||Writes to part or all of a File object's file.|
The Object Access Services provide the means to read, modify and write
Properties, and to add and delete Objects. Multiple Services are provided for
reading and writing properties; the purpose of the more complex Services
(ReadPropertyMultiple and WritePropertyMultiple) is to combine as many reads of
or writes to Properties of Objects within a BACnet device into a single message,
thus reducing network overhead. The ReadPropertyConditional Service goes a step
further; the device processing the request tests each referenced Property
according to criteria included in the request and returns the value only if the
criteria are met.
Although the CreateObject and DeleteObject Services are defined, they will
apply to a limited set of Objects. Objects attached to some physical device, for
instance, are not likely to be either creatable or deleteable. The Group and
Event Enrollment Objects, and possibly the File Object, are likely to be the
usual subjects of the CreateObject and DeleteObject Services.
Table 6. Object Access Services.
||Adds one or more items to a property that is a list.|
||Removes one or more items from a property that is a list.|
||Used to create a new instance of an object in the serving
||Used to delete a particular object in the serving device.|
||Returns a value of one property of one object.|
||Returns the values of multiple properties in multiple objects.|
||Returns the values of multiple properties of multiple objects.|
||Writes a value to one property of one object.|
||Writes values to multiple properties of multiple
The Remote Device Management Services, listed in Table 7, provide a number of
disparate functions, including operator control, specialized message transfer,
and addressing/auto-configuring functions.
The DeviceCommunicationControl and ReinitializeDevice Services are intended
to provide a human operator with diagnostic tools which may be invoked remotely.
With them a BACnet device can be ordered to ignore all BACnet messages (except
for the DeviceCommunicationControl and ReinitializeDevice Services), or either
warm-started or cold-started.
The ConfirmedPrivateTransfer and UnconfirmedPrivateTransfer Services are used
to convey messages outside the BACnet standard, effectively invoking
non-standard Services. These Services bear both the Vendor ID Code and the
Service Code in standard BACnet form; the rest of the content is entirely up to
the vendor and not likely to be interpretable by other manufacturers' devices.
The ConfirmedTextMessage and UnconfirmedTextMessage Services transport text
messages to other devices, such as printers.
The TimeSynchronization Service is transmitted by designated devices which
have clocks to other devices, or broadcast, so that the devices may be
The Who-Is and I-Am Services are used to obtain the network addresses of
BACnet devices on a BACnet internetwork; they can make life much easier for the
installer by reducing or eliminating the need to program other devices'
internetwork addresses into each BACnet device. Instead, a BACnet device that
needs to know the address of one or more devices can broadcast a Who-Is Service
request (message) on the internetwork specifying a Device Object Instance Number
or a range of Instance Numbers. The responses do not come back as a reply.
Instead, the devices that have the specified Device Objects broadcast an I-Am
Service request either on the local network, on a remote network, or on the
entire internetwork, so that the requesting device will see the response, which
carries with it the address information of the responder. This allows other
devices that may need to know about the responders to acquire the address
information without creating more network traffic.
The Who-Has and I-Have Services are similar to the Who-Is and I-Am, but the
Who-Has adds either an Object Identifier (Object type plus Instance number,
unique within each device) or an Object Name (a Property of every Object, unique
within each device). Receiving devices which contain an Object matching the
request broadcast the I-Have Service request.
Table 7. Remote Device Management Services.
||Tells a device to stop (and start!) accepting network messages.
||Sends a vendor-proprietary message to a device.
||Sends a vendor-proprietary message to one or more devices.
||Orders the receiving device to cold- or warm-boot itself.
||Conveys a text message to another device.
||Sends a text message to one or more devices.
||Sends the current time to one or more devices.
||Asks which BACnet devices contain a particular Object.
||Affirmative response to Who-Has, broadcast.
||Asks about the presence of specified BACnet devices.
||Affirmative response to Who-Is, broadcast.|
The Virtual Terminal (VT) Services can be used by an operator to establish a
bi-directional text-based connection with an application program executing in a
remote device. In effect, for the duration of a VT session established with the
remote device, the operator's device looks like a terminal connected to the
remote application program.
Table 8. Virtual Terminal Services.
||Establishes a virtual terminal session with a remote BACnet device.
||Closes an established virtual terminal session.
||Sends text from one device to the other participating in a
Conformance Classes, Function Groups and the PICS:
Evaluating the capabilities of a BACnet device is potentially a formidable
task, given the great choice of Objects, Properties and Services which can be
implemented, as well as the fact that it is not necessary for every BACnet
device to have a full BACnet implementation in order to carry out its task.
ASHRAE's BACnet Committee recognized this problem and responded with aids to
evaluation in the form of "Conformance Classes," "Function Groups" and the
"Protocol Implementation Conformance Statement" (PICS).
The BACnet protocol defines six levels of Conformance Classes, each of which
specifies the minimum subset of Services implemented on the device. The lowest
level, Conformance Class 1, requires only that the BACnet device contain a
Device Object and that it be able to execute (respond to) a ReadProperty Service
request. Each successive Conformance Class level adds Service Requests that must
be executable by the device, as well as the Service Requests it must be able to
initiate. Conformance Class 6 requires 21 types of Service Requests (of the 32
overall) to be implemented, of which 20 must be initiatable and 17 executable.
Conformance Class thus provides a measure of the device's ability to
Function Groups specify a combination of Objects and Services necessary to
carry out certain building automation functions. They are specified
independently of Conformance Class, though the implementation of some of the
Function Groups automatically confers some Conformance Class higher than 1. The
Function Groups specified by BACnet are listed in Table 9, with brief
Table 9. Function Groups.
||Capabilities generally associated with having a clock.|
||Hand-held or portable workstation capabilities.|
|Personal Computer Workstation
||Main operator workstation capabilities.|
||Detect and generate alarms and events.|
||Ability to respond to alarms and events.|
|COV Event Initiation
||Ability to initiate change-of-value notifications.|
|COV Event Response
||Subscribe to and receive change-of-value notifications.|
||Capability to read, write, upload and download files.|
||Ability to be reinitialized from remote device.|
||Capable of providing operator side of virtual terminal session.|
||Capable of providing server side of virtual terminal session.|
||DeviceCommunicationControl Service request execution supported.|
||Able to initiate TimeSynchronization Service
In order to best facilitate evaluations of BACnet devices, the BACnet
specification also provides a standard Protocol Implementation Conformance
Statement (PICS), created by the manufacturer, which provides in detail the
options implemented in the particular device. It identifies the vendor, briefly
describes the device, and details of the implementation. Included in the PICS
- the Conformance Class of the device,
- the supported Function Groups,
- standard and proprietary Services executed and initiated,
- standard and proprietary Objects with any optional, writable, creatable,
or deleteable Properties
and a number of other aspects of the device pertaining to its implementation
per the BACnet standard. The Standard provides a pro forma PICS to simplify the
effort of specification.
BACnet spent nine years under development by a committee drawn from
manufacturers, universities, government agencies and consulting firms in an
effort to produce a truly open protocol whereby equipment from different
manufacturers can interoperate in a complete, integrated building automation
control system. The result is a standard that defines all the elements of
communication between devices, from the abstract language of Objects and
Services right down to the physical LANs. With its adoption as an ANSI standard
and the interest shown by GSA and others, it is safe to say that BACnet points
the way to the future of building automation controls.