The Development Of BACnetTM

Ira Goldschmidt, P.E.
Senior Engineer
RNL Design


BACnetTM1, the standard communications protocol for the HVAC controls industry, is clearly becoming the accepted alternative to the proprietary communications solutions that to-date have dominated most HVAC controls installations. Its promise of interoperability has been widely anticipated for over ten years.

As a co-author of the standard, I am often confronted with impatience regarding the pace of the standard's development and market penetration. A simple response to this concern is that interoperability in DDC controls is a complex issue that should only be met by a carefully designed and released solution. A more cynical view is that the building design, construction, and management industry is not normally willing to participate in the learning curve of a new technology. To make new technology palatable to the building industry, computerized controls have been sold with overblown claims and expectations. Readers with experience in first-generation computerized energy management and DDC systems should understand this challenge and appreciate a careful transition to the industry dominance of BACnet.

BACnet products are widely available and can be found in thousands of installations. Recent articles2,3 have documented the growing popularity of BACnet and the completion of a multi-vendor project at the Phillip Burton Federal Building in San Francisco (known as "450 Golden Gate"). Nevertheless, further efforts, developments and patience are required before BACnet becomes the de facto technology in most building controls projects. This article provides insight into the challenges and complexities that were confronted in the development of BACnet. It also describes the steps remaining to fully transition the industry to BACnet. Ultimately, this story will help the reader understand that the success of the standard can only be assured through the patient participation from everyone in the building industry--a corollary to "you are either part of the solution or part of the problem."


The growing pains in the early 1980's development of computerized direct digital control (DDC) systems quickly gave way to a concern for the proprietary communications methods incorporated into these systems. DDC products from a given manufacturer could not operate within a single system with other manufacturers' products (referred to as "interoperability" in this article). The typical complaint leveled by users was that competitively-priced additions to DDC systems could not be procured, and that these additions were limited to only those products offered by the original system's manufacturer. While these frustrations were understandable, it is important to recognize that proprietary communications were a natural result of the lack of off-the-shelf communication solutions and the immaturity in digital communications technology.

Large facilities quickly became concerned about the limitations inherent in DDC systems' proprietary communications. One such user, Michael Newman at Cornell University, quickly decided to take matters into his own hands through the challenge of developing a universal "host" to Cornell's campus of multiple-manufacturer DDC systems. Additionally, some of the energy management system manufacturers that began in the 70's and 80's understood that dominance by industry controls giants could not be challenged without open communications. In fact, American Auto-Matrix opened a communications protocol to the industry via publication of "Public Host Protocol" in 1985. Meanwhile, many consulting engineers felt powerless to help building owners with abandoned or under-utilized DDC systems that could not be improved.

These forces led to the seminal 1987 roundtable on "Standardizing EMS Protocols"4 organized by Energy User News in New York City. This roundtable highlighted the coincidental announcement5 that Mike Newman would chair an ASHRAE committee to develop a standard protocol. These events drew support for the ASHRAE committee from those that attended the roundtable or found the Energy User News articles compelling. A few consulting engineers, like this author, were drawn to the committee with a "revenge of the nerds" goal, and were hoping to use the standard on projects that were just entering design. The committee came together optimistic that, with cooperation from all involved, the standard could be completed in a year. Unfortunately, Mike Newman's prediction that if "...cooperation is less than complete, it could take forever."5 was closer to the truth.


Early meetings of the committee quickly led to the realization that developing a standard communications protocol was a technological and political challenge well beyond our initial optimism. We quickly discovered that concurrent and interdependent work would be required on a number of issues, including:

In addition to the above technical issues, the politics inherent in gaining consensus from competing manufacturers, some of whose representatives appeared to be threatened by the goals of the committee, led some of us to wonder if we had cashed a check on an account that could never be opened!

Fortunately, after a few initial meetings, the committee started to make some important choices, including:

Meanwhile, other efforts to create open/standard protocols in the late 1980's, notably by the Intelligent Buildings Institute and Public Works Canada, put pressure on the need for ASHRAE to move ahead.


As the committee's efforts continued into the 90's, it became obvious that each meeting would devote significant time on revisiting old issues. It was not always clear whether this constant rehashing was due to opposition to the standard or just a lack of understanding. Ironically, while it was often tempting to give up in frustration, this constant prodding and reevaluation proved to test the soundness of our decisions and would lead to a better standard!

We continued to refine the choices made earlier in the standard's development. In particular, the decision to develop an EIA-485 LAN technology--later to become known as "MS/TP"-- meant that extensive protoyping would be required. In the end, this effort required several years and extensive off-line efforts by members skilled at electronic design. To keep consensus, optional data parameters were defined, and choices in implementing services were allowed. It was understood that these options and choices would make interoperability difficult, but we expected that the market would constrain the use of the standard to achieve interoperability. I'm not sure if the committee fully understood the ramifications of this decision.

Early in the development of the standard, we became aware of a new product offering called "LonTalkTM." Its message delivery functions (not including its applications services and data structures) appeared to be an off-the-shelf alternative to MS/TP (i.e., a low cost/low speed LAN). However, concerns over its proprietary origins (it was developed and largely controlled by Echelon) meant that it would not be included in the first public review of the standard in 1991. Eventually, pressure from manufacturers making investments in the development of LonTalk-based products led to a showdown on the issue. Committee members not committed to the use of LonTalk were concerned that its growing popularity was more a result of big marketing dollars than the benefit it could provide to BACnet. The issue of including LonTalk as a LAN technology within BACnet was passed prior to the third public review of the standard in 1995. The alternative appeared to be a deadlock and potential appeal of BACnet by Echelon, which led to an observer's remark that some committee members held their noses while voting "yes."

Unfortunately, the large disparity between the services and data structures of BACnet and LonTalk means that a BACnet system will never interoperate with a full LonTalk system without the use of a gateway. (For an excellent discussion of the issue of gateways, see reference 6.) Less controversial, the committee also included IEEE 802.3 (the standardized version of Ethernet) and ARCNET as high speed LAN choices, and developed a direct/modem connection technology called PTP (for "Point-to-Point").

The question of whether a standard protocol could constrain DDC product design continually brought heated discussions. Eventually, it became clear that some constraint was inevitable given the goals of BACnet. Committee member representatives for some of the manufacturers were not overjoyed with this prospect given the cost to redesign their products to implement the standard. To help soften the blow, we tried to develop models for such functions as alarming and scheduling that drew on some of these manufacturers' current philosophies. Again, to gain consensus, options and choices were also included.

A realization that occurred just shortly before the completion of the standard's first draft was that modern DDC systems required routing functions to allow for a connection of multiple DDC networks. This realization led to expanding the standard's use of the OSI model to include a network layer made up of simple functions created by the committee. This decision would help pave the way for BACnet's future use on the Internet.

One of the final efforts before the release of the standard was to develop a method to facilitate the specification of BACnet-based systems. It was understood that an intimate knowledge of the 500 page standard could not be expected of the consulting engineering community. Therefore the "Conformance and Specification" clause was written as an attempt to provide everything a consulting engineer would need to know to specify BACnet. It was never the intent of this section to constrain BACnet's myriad of choices and options to provide interoperability.

Of course the wisdom in the above decisions is not yet fully proven. However, experience with other successful standards and de facto standards (e.g., the PC) has shown that an excessive focus on perfection is not necessary, and may even be the kiss of death.


It would have been easy to forever find reasons to delay the release of the standard, especially with a committee composed of engineers, some of whom were apparently opposed to BACnet. However, it became clear by 1991 that the standard must be constrained to the core issue of a communications protocol to hasten its completion. In particular, we chose to leave a number of peripheral issues for future efforts. These issues included development of a method for testing conformance to the standard, and the selection of an organization for managing the certification of BACnet products. It was understood that after release of the standard, these issues would need attention before BACnet could become fully viable.

Two other key events served to hasten BACnet's release:

  1. Product Development and Testing - A standard that defines a complex set of rules governing digital communications cannot be developed exclusively on paper. At some point, the ideas must be prototyped in real devices as a true test of soundness. The "BACnet Interoperability and Testing Consortium" was organized by the National Institute of Standards and Technology, to provide an environment where manufacturers could test product prototypes. Unfortunately, participation in this consortium was half hearted until a commitment to complete the standard was made.
  2. The Trane Company chose to market a BACnet-compatible product well before completion of the final version of the standard. This gambit probably helped to generate market interest and to convince other manufacturers that any further delays might relinquish a major advantage to Trane.

As an ANSI standards body, ASHRAE is bound by the rules of public review and comment. From the time of BACnet's first published draft it took four years, three public reviews and the individual resolution of 741 comments to gain approval of formal publication of the standard in 1995. This process helped make BACnet stronger than any proprietary protocol could ever hope for, but delayed its release to the point where it could have died on the vine.


Completion of the BACnet standard merely marked the start of a "...'re-tooling' of the controls contracting industry for delivery of truly integrated building automation solutions."2 For this "retooling" to occur the committee must complete some unfinished business that has been in the works for a number of years, including:

This last effort is the cause of much current controversy with the standard. As discussed earlier, the "Conformance and Specification" clause was never expected to ensure interoperability. It was always hoped that the market would constrain the choices and options within BACnet to the degree needed to provide interoperability. However, manufacturers are gun-shy of releasing products that may not interoperate with other manufacturer's BACnet products. The committee never foresaw this "Catch-22". This quandary is due to the insistence by most manufacturers during the development of the standard to include choices and options--the very choices and options that are the cause of this interoperability challenge! So, the committee is now completing efforts to rewrite the "Conformance and Specification" clause to provide the degree of constraint needed to assure interoperability. Ironically, these constraints will undoubtedly make obsolete many of the sacred cows that were originally included in BACnet for the purpose of achieving consensus.

With the completion of the above efforts expected before the end of the year, the retooling of the controls industry will involve a number of possible aspects, including:


BACnet will continue its path to market dominance because it represents a comprehensive consensus of industry ideas. This dominance can be hastened through support of manufacturers that are upgrading their products to comply with the standard. This support could result in your participation in single-manufacturer installations that use these products, while carefully avoiding the pitfalls of premature or overblown expectations of interoperability. The experience, profits, and good publicity that come from these scaled-down BACnet projects will contribute to the day when full scale, interoperating BACnet installations are the norm.


  1. ANSI/ASHRAE Standard 135-1995: BACnet--A Data Communication Protocol for Building Automation and Control Networks.
  2. Applebaum, Martin A. and Bushby, Steven T. "BACnet'sTM First Large-Scale Test," ASHRAE Journal, July 1998, pp. 23-30.
  3. Gahran, Amy. "BACnet on Duty: New BAS Frontiers for End Users," Energy User News, March 1998, pp 16-20.
  4. Mullin, Richard. "Standardizing EMS Protocols: An EUN Panel Discussion," Energy User News, February 23, 1987, pp. 4, 5 and 7.
  5. Racanelli, Vito. "ASHRAE Forms Group to Seek Standard EMS Protocol," Energy User News, January 26, 1987, pp. 1 and 7.
  6. Bushby, Steven T. "Communication Gateways: Friend or Foe?" ASHRAE Journal, April, 1998, pp. 50-53.


Ira Goldschmidt is a Senior Engineer at RNL Design, one of the largest architectural/engineering firms in the Rocky Mountain region. He has over 20 years experience in the building HVAC and controls industry and developed some of the first commercial DDC applications. Ira is well known throughout the industry for his expertise in building automation systems and their application for energy management; integration with fire, security, and lighting systems; and use over LANs and other communications systems.

He is a co-author of the ASHRAE BACnetTM standard and the ASHRAE Guideline to Specifying DDC systems, and is a seminar instructor for the AEE seminar "DDC Open Systems.". He is a registered professional engineer and has masters' degrees in mechanical engineering and in computer systems.

Note: The biographical information above is from 1998, when this article was published. Ira's contact information as of 05/2012 follows:

Mr. Ira Goldschmidt, P.E., LEED-AP
Goldschmidt Engineering Solutions
3210 Wolff Street
Denver, Colorado 80212-1641
Phone: 303-561-2011