Using Native BACnet Systems In Open Protocol Installations

By Larry K. Haakenstad


Steven T. Tom, pH.D., P.E.

One of the most popular open communication protocols for building automation systems is the ANSI/ASHRAE Standard 135-1995: BACnetTM - A Data Communication Protocol for Building Automation and Control Networks. This open protocol standard was approved by ASHRAE and adopted by ANSI in 1995. Systems using this communication protocol have been installed to integrate components from different manufacturers. New and existing installations use BACnet for all aspects of communication, including workstation, field panel, custom application controller and unitary controller communications and are commonly referred to as native BACnet systems.

This article reviews reasons to use an open protocol standard and specific reasons why BACnet works for the building automation industry. It then describes projects that have been implemented using native BACnet controllers at every system level. These projects include integration of controllers from different manufacturers using BACnet as the communication protocol of choice.

Why Choose an Open Protocol Standard?

First, an owner needs to decide whether or not to purchase a control system that uses an open protocol. The entire controls industry is wrestling with the issue of interoperability. Using an open protocol makes it easier for control components manufactured by one company to interoperate with controls supplied with equipment or controls made by a different company. An open protocol simplifies integration with building systems such as fire alarm, security, access control, etc.

The owner also needs to decide whether the open protocol should also be a protocol standard. An open protocol can be any protocol that a company or an individual chooses to publish. It does not have to be monitored by any entity and can be changed at any time. An open protocol standard is published by a governing body and adopted by a national or international standards body. Any changes to this protocol are typically published for public review and must be approved by the governing body. An open protocol that is also a standard ensures long-term stability of the protocol with no undue influence from companies or individuals.

Deciding to adopt an open protocol means keeping options open for future expansions or partial replacements. Today's proprietary communication protocols used by most manufacturers handle communications adequately within their own proprietary network, and customers can be reasonably certain the system can be expanded in the future--but only if equipment is purchased from the same vendor. The problem arises if a customer wants to do business with a different manufacturer when it's time to expand the existing system.

It is difficult to make two systems with different proprietary communication protocols to talk to each other. The cost and the custom programming required is far beyond the resources of most building owners. Similarly, replacing all of the existing controls with an entirely new system is usually cost prohibitive. Instead, the owner must choose between buying expansion systems from the vendor who installed the original system or installing a stand-alone system for the new addition, complete with a separate front-end computer interface. In addition to the difficulties of training operators in multiple systems, the lack of interoperability makes it impossible to take a facility-wide approach to electrical demand limiting, heating and cooling optimization, and similar energy saving strategies.

Because of these difficulties, many customers are interested in the interoperability capabilities provided by an open protocol. Even building owners who are satisfied with their current vendor's service may be interested in open protocols to preserve their options for future expansion. Building managers who use a competitive bid process to award contracts for control system expansion find that specifying an open protocol is the only way to get true competition and interoperability for follow-on work. While it selfdoms makes sense to mix primary control system manufacturers within a single project, specifying an open protocol on a current project keeps the door open to competition on future projects.

Why would an owner Use BACnet?

Once the owner decides to adopt an open communication protocol, the next decision is "which protocol to choose?" BACnet and LonWorks are in widespread use, but they are not the only open protocols available. CAB, PROFIBUS, BatiBus, EIB--there are many open protocols which are being proposed for use in the building automation industry.

An open protocol should be powerful and robust, capable of meeting all future communication needs, as well as the present needs throughout all system levels. Any communication protocol which doesn't meet these criteria should be eliminated from further consideration. BACnet passes this test because of the range of communication networks it supports, from high speed Ethernet LANs to low cost MS/TP device networks. BACnet can be used by an automation system at all system levels.

The high-speed capabilities of BACnet give a system room for future growth, while its flexibility in networking options allows it to be used in small zone controller subnets. Ethernet capability allows connection directly to wide area networks (WANs) that link multiple campus-wide LANs. The fact that BACnet does not impose a set hierarchy on the control system layout gives manufacturers the flexibility to match the cost and performance of the controls to the needs of the application.

BACnet's object-oriented services provide powerful tools for interconnectivity, because the program was designed from the outset to foster interconnectivity in a large building automation system. Therefore, it provides methods to share complex information such as alarms and scheduling, as well as basic input/output (I/O) point data. BACnet also allows prioritized commands, which allow a fire alarm system to override a temperature control system and allow an emergency control panel to override both systems.

BACnet's open structure and object-oriented commands enables developers to provide enhancements or features, while still maintaining full interoperability for all core operations. If use of a new control feature becomes widespread and there is a need for it to be standardized among vendors. ASHRAE provides a procedure for it to be adopted as a standard BACnet object or service.

BACnet is a widely accepted, non-proprietary open protocol standard. Companies began announcing their support for BACnet even before the final draft of the standard was released. The fact that ASHRAE developed BACnet plays a significant role in this acceptance. ANSI perceived BACnet to be a significant development and adopted it as a protocol standard within months of acceptance by ASHRAE.

The non-proprietary nature of this standard is important to owners, because no one company or consortium will have undue influence on the future development of the standard, nor will any company have "inside knowledge" of upcoming changes. An open committee that included representatives from industry, academia and government developed BACnet. The standard is kept on a "continuous maintenance" status, meaning that changes can be proposed at any time. The BACnet committee meets semi-annually to consider these proposals, and any changes they feel should be incorporated into the standard are published for public review and comment. This open process offers no advantage to any one competitor and ensures that BACnet will continue to grow and evolve.

BACnet Project

Thousands of projects have been implemented using the BACnet communication protocol. Many of these projects have used BACnet as the integration protocol between equipment from different manufacturers. This trend shows that BACnet can be used to integrate systems from multiple manufacturers. Projects also utilize BACnet as the protocol of choice at the operator workstation all the way down to the unitary controllers.

450 Golden Gate

!450BLDG.JPG (22156 bytes)One of the largest BACnet installations is the 450 Golden Gate project in San Francisco. This project at the Phillip Burton Federal Building includes installation of nearly 1000 native BACnet controllers and a native BACnet Ethernet network for communication to the operator workstations. The project includes integration with multiple manufacturers' equipment and integration with systems other that the HVAC system. This project will be covered in a future issue.


Buckbee-Mears Corporation

buck.jpg (20035 bytes)Buckbee-Mears Corporation in Cortland, N.Y., expanded its state-of-the-art, high-tech manufacturing plant to accommodate a demand for two new production lines. The control system installation in this expansion uses BACnet as the communication protocol for all controllers (see Figure 1). Control is provided for multiple air-handling units, reheat coils, steam heat exchangers, boilers and chillers. Native BACnet controllers are also installed on heat pumps and Variable Air Volume (VAV) boxes in the expansion.

An Ethernet network provides the BACnet data link layer to connect the operator workstation with the network/global controller. The network/global controller communicates over a BACnet MS/TP LAN to all custom application controllers and all unitary controllers. Custom application controllers are installed on all air-handling units and are used for hot water control and chilled water control. Unitary controllers are installed on the water source heat pumps and VAV boxes.

Each native BACnet air-handler controller provides stand-alone control for the unit. This stand-alone control includes modulating the chilled water valve and the steam reheat valve, modulating the economizer, start/stop of the fan and modulating the inlet guide vanes. Each controller senses temperatures, HEPA filter status, fan status and total airflow via air monitoring stations. Precise control is necessary because of the clean room environment they supply. Similar control is provided for makeup air-handling units. Hot water and chilled water control monitors temperatures, starts and stops pumps and modulates valves as needed.

Native BACnet unitary controllers are installed on each water source heat pump and each VAV box in the expansion. Each heat pump controller is a stand-alone unit and provides control of the heat pump fan, compressor and reversing valve. Control of these outputs is based on occupancy, zone temperature and zone set point. Discharge air temperature from the heat pump is also sensed to assure the heat pump is operating correctly.

Each VAV unitary controller provides control of the VAV box damper and heating coils. An onboard flow sensor provides airflow indication to assure minimum and maximum airflow set points are followed. Zone temperature sensors provide feedback for control to zone set point. All control logic is internal to the unitary controller that communicates all information using BACnet over the MS/TP LAN back to the network/global controller.

West Valley Accord Ice Center

wvcityutah.jpg (20510 bytes)Preparation for the 2002 Winter Olympics is already underway. The Ice Center in West Valley City, Utah, will be used as a venue for skater from all over the world. A BACnet-based control system was installed to provide environmental and ice making control for this facility (see Figure 2). The control system, which is installed on air-handling equipment and VAV boxes, provides boiler control and pump controls and interfaces with multiple chillers from a different manufacturer using BACnet.

The operator workstation communicates using BACnet over an Ethernet LAN to a network/global controller and also to the chiller interface panel(s). The network/global controller communicates using BACnet over an MS/TP LAN to the air-handler controllers, boiler and pump controllers, and also to the VAV box controllers. Every controller provides stand-alone control and every controller in the system communicates using BACnet.

BACnet is used to implement an interface between controllers supplied by the controls manufacturer and controls supplied by the equipment supplier. This is an important factor for using open protocols. No custom hardware or software needed to be developed for this integration. Both manufacturers provided BACnet compatible equipment using the same LAN type. The interface work was simply a matter of establishing the application parameters.

Portsmouth Municipal Complex

The Portsmouth Municipal Complex is an eight building installation in Portsmouth, VA. This controls installation mixes BACnet Ethernet LANs, BACnet MS/TP LANs and BACnet Point-to-Point (PTP) communication to reach all buildings in the complex (see Figure 3). A single operator workstation communicates via the Ethernet LAN and also to the PTP modem connection to remote buildings. This controls installation shows the versatility of BACnet as a communication protocol.

The civic center, jail, police headquarters, judicial building and city hall are interconnected using Ethernet and MS/TP LANs. Modem connections using BACnet PTP to offsite buildings allow offsite communications to the Public Health Building, Main Library and Human Services Building. Modems are connected via PTP to the building controller within each building. The building controllers use BACnet MS/TP LANs to communicate to custom application controllers in each building.

Control functions provided throughout these buildings include chilled water and hot water control, rooftop unit control, air handler and chiller control. Night setback is provided for all buildings and VAV box control is provided in those buildings that include VAV boxes. All controllers are completely stand-alone and communicate using the BACnet protocol and LANs.


The move to open protocols and interoperability among vendors will change the way business is done. All the necessary elements are in place: strong customer demand, a robust open standard and manufacturer's support of the standard. BACnet seems to provide a complete solution to interoperability issues for building owners.