David Fisher, is president of PolarSoftÒ Inc., Pittsburgh, Pa. He was a charter voting member of ASHRAE’s Standards Project Committee 135P and has been active in the development of the BACnet standard (ANSI/ASHRAE 135-1995) since its inception. He served on the Standing Standards Project Committee-135 until July 2000. He has taught many courses about BACnet, networking and communications, and direct digital controls.

BACnet® at Work

By David Fisher


Most building owners, consultants and specifying engineers know something about BACnet. Not since the introduction of direct digital control to building automation more than twenty years ago, has there been so much confusion, and misinformation about something that ultimately is good for everybody. By accident or intent, BACnet has caused a permanent shift in thinking. The change creates new opportunities to reexamine our assumptions about what is possible and desirable with building automation.

In the past, building systems and controls mostly were proprietary. Once an owner bought into a particular vendor, they had limited choice about the range of possibilities for making that equipment or system interoperate with other systems. There are many reasons for wanting non-proprietary interoperability. Some owners think that interoperability gives them flexibility in designing and configuring systems, so that they can choose the best technology or best price with less compromise. Some think that interoperability enables competitive bidding in what were once locked-in or sole-source situations. Some think that if they are restricted to choosing the lowest bidder price, for example in government and municipal procurements, they may be forced into supporting multiple incompatible systems.

Many issues have added to the pressure to break away from the proprietary mindset. Regardless of the causes, the industry became motivated to bring together a diverse group of interests within ASHRAE beginning in 1987. After an intense effort over a period of eight years, ANSI/ASHRAE Standard 135-1995, BACnet–A Data Communication Protocol for Building Automation and Control Networks, emerged as a world-class model for achieving interoperability within a contentious and fiercely competitive industry.

Five years later, dozens of manufacturers and a worldwide deployment of BACnet in thousands of successfully interoperating systems have affirmed the need for a standard for building automation interoperability. The nay saying has drifted away from "whether" and "when" to the now serious stewardship of BACnet’s growing presence and domination in medium to large-scale interoperability projects on every continent. Traditional "proprietary" companies are losing market share to companies that have the broadest and most comprehensive adoption of BACnet. The shift is real, and the rate of change is accelerating.

It is more important than ever to understand what opportunities and liabilities come from the use of, and failure to use, interoperable systems. This article attempts to dispel some of the myths about BACnet.

Why is BACnet Important to Specifying Engineers?

BACnet is the only practical option for achieving real interoperability of automation systems at a system (non-sensor/field bus) level. As an American National Standard, BACnet creates a safe and robust method for specifiers to ensure intersystem interoperability, while remaining open and flexible to accommodate different approaches between vendors. In small and medium size systems, interoperability above the sensor/actuator level has never been feasible before, but now it is. This creates new opportunities for owners and specifiers.

Before getting into specific issues, we need to keep in mind that building automation is a complex industry with many overlapping layers and dimensions. Along one dimension is the dynamic issue of "lowest first cost" vs. "best performance/maintainability." Another dimension is the issue of size and scalability. A third is mechanical system vs. controls system orientation. Each of these and other dimensions tend to bias one’s thinking significantly about appropriate interoperability solutions, and even interoperability needs, in one of several directions. To greatly oversimplify the problem, the industry tends to fall into three schools of thought about interoperability: small systems, large systems and "who needs it."

For a specifier or building owner, the issues of interoperability are different depending on the scope of systems you deal with, and how you envision the growth and management of those assets across their lifetime. For example, with small systems involving single buildings, a 20-ton (70 kW) rooftop unit, and a handful of thermostats, you might be more concerned about interoperability between sensor devices, thermostats, and actuators and the control system for the mechanical equipment. The size of such buildings and the relatively static nature of the mechanical system will limit the need for a lot of scalability, or the growth of the system through the addition of more controls and automation. On the other hand, if you view such buildings in the context of groups of buildings with centralized management or maintenance; or integration with a centralized physical plant; or even other types of automation such as lighting, fire and security, then the picture can become quite different.

The bottom line is that "system" interoperability has different requirements that depend on size and scope, and the issues are not the same. Interoperability at the sensor/actuator level of thinking is different in many ways from interoperability at a system-to-system level, at a multi-system facility level, or inter-system within a facility. Although several competing strategies exist for effectively managing some kinds of interoperability at the sensor/actuator level, BACnet is the first comprehensive standard that addresses the management and scalability issues that dominate other types of interoperability requirements in venues with larger scope. Since many specifiers are called upon to design or plan for these kinds of system-wide integration, growth capabilities and so forth, BACnet is increasingly important as a potential solution.

Small vs. Large: Where is BACnet Appropriate and Why?

There’s no question that BACnet is intended as a system-level mechanism for interoperability. While it is possible to create pure "native BACnet" sensor and actuator devices, the economics of BACnet are somewhat marginal for these applications. Having said that, BACnet over MS/TP (Master-Slave/Token-Passing) still provides a lower cost solution for these applications than many other methods, including LonTalk as a complete field bus. There are several examples of sensor and actuator devices already on the market that use BACnet. While this has not been compelling to developers of field devices so far, it is a positive indication of what’s coming. As soon as you have a device that can perform several functions, such as a small controller, or a multi-input sensor multiplexing device, BACnet becomes quite practical. If there is an anticipated need for interoperability with building automation systems, then BACnet quickly becomes not only practical, but preferable.

Examples of situations where this kind of interoperability would be a benefit include: a small building with one or two package units and several thermostats and the need to provide dial-in access for maintenance purposes; room-level controls in a hotel with independent heat-pumps for each room and integrated lighting control; and multiple school buildings, or a small office park.

BACnet offers several choices for LAN technology that provide a lot of flexibility in small systems. Using MS/TP over EIA-485 allows you to configure small local networks that are up to 5,000 ft (1524 m) long using shielded twisted pair wiring. Despite the distance, these networks can deliver modest performance up to about 76K baud, which is fast compared to proprietary networks of only a few years ago. The multimaster capability allows peer-to-peer operation where desirable, for example, allowing multiple devices to share resources like sensor readings, dial-in/out routers and so forth easily.

Using LonTalk as a BACnet datalink technology allows a wider choice of media than simply twisted pair, and the opportunity to trade off distance for increased speed and cost, up to 1.25 Mbps, although small systems usually use lower cost/speed solutions that are similar to MS/TP in terms of cost and performance. Another popular option for small systems is ARCNET using a scaled-down speed of 156K baud over EIA-485. For a modest cost premium over MS/TP, you can have a much faster speed and more efficient token-passing.

We are often asked, "at what kind of point count does BACnet start to make sense?" That’s really the wrong way to think about interoperability, and perhaps a better question to ask is, "when does BACnet become practical or desirable for a small system?" As soon as two or more controller devices need to interoperate, and a potential exists for one or more of them to be replaced by a different vendor at some future date, then BACnet is practical and desirable.

The nature of this kind of small system makes the decision potentially a gray area, because the "need" for interoperability as a feature or capability is a much more subjective measurement. Small systems tend to be bid competitively, and any extra feature tends to add cost, so any kind of interoperability may be viewed as a frill.

The picture changes for medium to large-sized systems, multibuilding sites, integration with central plant, integration with other building systems, etc. It is increasingly difficult to even find larger systems that don’t use at least one of these kinds of interoperability features. In those cases, BACnet is the only alternative for many reasons:

These and other considerations also make BACnet the only serious contender as an International Standard presently.

BACnet Politics

Other approaches exist for achieving interoperability to varying degrees. Nearly all of these are based on some proprietary solution or technology that has been promoted as an "open" systems answer to the issues of interoperability. In some cases, aggressive marketing campaigns have helped to paint rosy pictures of the benefits of particular technologies. When comparing their solutions to BACnet, unfortunately, some misstatements have appeared in print. Since BACnet has been a truly open pro bono effort, it has no marketing agenda other than to provide some much-needed advancement for the industry as a whole. As a result, its promotional efforts have been more modest, and perhaps "the voice of BACnet" has not been heard above the screeching of marketing dollars in search of an audience.

Misconception 1: BACnet is only useful in large systems

Well, that depends on the definition of large. For two or more controller devices, such as simple "unitary-style" controllers, that need to interoperate or to potentially interoperate into a larger facility, then BACnet is immediately practical, and some would say necessary. It’s a question of perspective. In a small system, with only a handful of data points being measured and controlled, how much "interoperability" is needed? In such venues, single controllers are used typically. If multiple functions, such as HVAC and lighting control, are required, then typically single controllers with those capabilities are much more cost-effective than multiple individually specialized control devices that interoperate. As soon as you have several controllers interoperating, the benefits of BACnet in terms of scalability and choice of compatibility with other systems and vendors is overwhelmingly greater.

A popular example is a multizone scenario such as a floor of an office building. Multiple office areas each require automation for HVAC and lighting. One school of thought says to use "low cost" dedicated lighting controllers for each office connected together using LonTalk, and dedicated HVAC controllers connected on the same network. The HVAC controller for Office X and the lighting controller for Office X interoperate with each other to coordinate the activities for that office. An alternative is to use a single controller for each office that accomplishes both tasks. In either case, BACnet can be used as the communication scheme, and there is no cost premium for doing so based on currently available products.

The issue becomes: what device(s) are communicating with each office and how do they interact with other systems in the building? Again, once the sphere of interoperability expands beyond two control devices, all of the issues that BACnet covers robustly come into play. Is BACnet the most cost-effective technology for use with a single controller and a handful of sensor/actuator devices? Not usually. If that controller needs to interoperate with anything else...the answer changes to yes.

Misconception 2: Specifying Interoperability with BACnet is Difficult

When BACnet was first released as an ANSI standard in 1995, it would have been difficult for non-experts to specify systems based on BACnet. Since that time, a huge effort has been made on the part of the "BACnet community" to change that. This grass roots effort was aimed at simplifying the specification of common BACnet interoperability needs, using language that would be familiar to most building automation systems specifiers.

The breakthrough was the idea of defining BACnet Interoperability Building Blocks (BIBBs), a term coined by H. Michael Newman of Cornell University. The intent of BIBB is to provide a way for a specifier to write a performance specification without the need to understand all of the technical details of how it would be implemented. For each BIBB, there is a discussion about what kinds of things can be included in the specification if that particular BIBB is supported. Having selected an appropriate collection of BIBBs, the specifier can describe how the system is to perform and leave many of the implementation details to the bidders. This is somewhat analogous to providing a sequence of operation but not specifying in a proscriptive way how it is to be implemented.

In essence, a BIBB is a simple definition of an interoperability function or capability that refers to a specific set of BACnet features that must be implemented by a device to support that BIBB. As a rule, BIBBs come in pairs: one set of capabilities needed by a device making a specific kind of request, and another set of capabilities needed by a device that responds to the request. A BIBB typically takes one or two sentences to define in a specification. Today, more than 50 BIBBs have been defined and are in common use. These BIBBs are under discussion for inclusion in a future addendum to BACnet under the continuous maintenance procedures for the standard. If this inclusion is adopted, then the BIBBs can simply be referenced directly in specifications. Today, they must be included in any specification that uses them (requiring only two pages for the entire set).

Specification of BACnet interoperability involves the definition of specific interoperability functions that given devices need to provide. These functions use two or more BIBBs to define the "user" and "provider" roles in each interoperability relationship. Typically, though facilities may have a large number of building automation and controls functions and types of controller devices, there are relatively few unique kinds of interoperability relationships. Often, it is straightforward to define several generic "interoperable controller types" that have the same kinds of requirements for interoperability. This greatly simplifies the problem of specifying interoperability using BACnet.

Each "controller type" can be defined in a few paragraphs that describe the interoperable functions that are required of each type, in terms of the BIBBs required to realize those functions. Typical examples of such specifications can require only a few pages to define the interoperability requirements for even a large facility. The bottom line is that a large facility’s BACnet interoperability specification can be covered in 10 to12 pages of specification.

ASHRAE offers a one-day Professional Development Seminar called "Understanding and Specifying BACnet" that covers this topic in some detail. You can also find out more about BIBBs at www.BACnet.org. A good reference that shows BIBBs in action is the NISTIR 6392. This reference also has a table that suggests particular combinations of BIBBs for a variety of common building control devices.

Misconception 3: Nobody Really Needs Interoperability

Of course, not everyone needs interoperability. Proprietary systems have done a fine job of building automation for a long time, with little or no interoperability, so why change? Well, you don’t have to. However, with that decision comes some liabilities:

1. If you want to expand a proprietary system, you’re probably locked into using the same vendor and often the same system. If the vendor’s service, quality, price and value become undesirable, you’re stuck.

2. Given the rapid changes in technology, the system you buy today will certainly suffer from obsolescence faster than ever before. How committed is that proprietary vendor to "backwards compatibility"? If you want to use their next generation system a few years from now, how compatible will it be with the system you buy today?

3. If you are required to procure based on "lowest bidder" there is no guarantee that the next addition to your system will be able to be integrated with what you have. If you have Vendor X now, but Vendor Y is low bidder tomorrow, you’re stuck with two systems that don’t necessarily work together.

4. Even when replacing an entire subsystem (like a chiller controller) a proprietary system might force you to replace more than you need to when switching vendors. For example, if you replace a chiller, you don’t necessarily have to replace the cooling tower and its controls. With a proprietary chiller/cooling tower control system, you might be forced to upgrade both.

The point is that having a system based on BACnet mostly obviates these kinds of concerns. While it is true that BACnet is not, and does not pretend to be, a "plug and play" kind of standard, it is also true that from a system perspective, BACnet allows you to have a lot of flexibility in choosing expansion and replacement controllers and subsystems. Multivendor systems with BACnet exist and examples abound of facilities with two or more BACnet vendors.

Vendor choice, scalability, and backwards compatibility are some of the benefits that BACnet provides to facilitate interoperability. Do you "need" these benefits? If I point out that having these benefits doesn’t really cost any more, the real question is: can you afford to ignore them?

Misconception 4: BACnet is All Pie-In-The-Sky and Not Down to Earth

Not to put too fine a point on it, but the real issue is money. Down here on earth, most owners are concerned with costs and the durability of their investments. Buildings cost money to operate and maintain. Wasted energy is wasted profit. The more effectively a facility is automated, the more profitable it is to run. Expansion without obsolescence, a choice of vendors/service/performance, best-of-breed technology: these are all down to earth concerns for any owner and responsible specifier. Let’s consider some facts:

One of the most common misstatements I hear all the time is "What about the cost of interoperability?" Having interoperability using BACnet doesn’t add to the cost. In today’s market, systems based on BACnet are competitive with proprietary systems in every category. I think the real question is "What about the cost of not having BACnet?" In nearly every venue I can think of, having a choice of vendors beyond the initial installation; scalability and expansion options without "lock-in;" backwards-compatibility; and forwards-compatibility with future technologies, at no cost premium, are compelling reasons to consider BACnet for every building automation system specification and purchasing today. Speaking to those issues is simply down to earth thinking aimed at lowering costs, providing flexibility, and assuring the return on investment in building technologies.

Not for Everybody

BACnet is certainly not the answer to all problems. You may not need interoperability, or the other benefits that BACnet provides. Although BACnet doesn’t add cost to procurement, considerations of interoperability and their specification do add complexity to specifications and the process of choosing and qualifying vendors, and that has some real cost. The shift in the marketplace is real, as is the sharply increasing presence of BACnet in more and more facilities worldwide. The specification of BACnet is getting easier. The choice of BACnet products is getting broader. A wide range of building owners and specifiers are taking advantage of these new opportunities. And that’s a fact.


Several websites provide insights and useful information, as well as background for specifiers. While they do not represent the official views of ASHRAE, they are nonetheless central points for locating knowledgeable and informed news and material:

www.BACnet.org    the "unofficial" official BACnet committee website
www.BIG-NA.org    the BACnet Interest Group North America website
www.bacnetassociation.org    the BACnet Manufacturers Association website