The Language of BACnet-Objects, Properties
BACnet (Building 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 manufacturers' systems.
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.
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 reply "68.0".
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.
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.
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.
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.
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.
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.
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 synchronized.
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.
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.
[Note: Due to changes in the BACnet standard years after this article was published, the following section is out of date and no longer applies. Please see Annexes A, B, K and L in BACnet-2004. --Bill Swan]
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 communicate.
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 descriptions.
Table 9. Function Groups.
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 are:
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.