The 450 Golden Gate Project:
The World's First Large-Scale Use of BACnetTM

Martin A. Applebaum, P.E., Member ASHRAE
Steven T. Bushby, Member ASHRAE

Published in ASHRAE Journal Vol.40, No. 4, April, 1998, pp. 50-53


The energy management system (EMS) industry has advanced rapidly over the past 10 to 15 years. Today, EMS technology provides building owners and designers with incredible design and operational flexibility. State-of-the-art EMS systems are characterized by powerful PC workstations and intelligent field panels that can process complex control algorithms quickly and efficiently. In spite of these advances building owners have been frustrated by the inability to bid projects competitively and to integrate innovative products from different manufacturers in ways that best suit the unique needs of their facility. Adoption of BACnet [1] as the standard protocol for integrating building control products has forever changed the industry and opened the door to new innovation in building control technology.

Today, thousands of BACnet systems are installed and can be found in at least fourteen countries [2]. Many of these BACnet jobs are small-scale projects where BACnet was used to integrate new HVAC equipment with an existing proprietary building automation system. Others are complete BACnet systems, but use products from only a single vendor. One job, the 450 Golden Gate Project, stands apart because of its size, the fact that multiple vendors are involved, it includes more than HVAC control, and will have significant impact on how the largest landlord in the world - the U.S. General Services Administration (GSA) - will manage its buildings in the future.

This article provides an overview of the project design, the demonstration team's experiences to date, and recommendations for engineers and building owners considering BACnet in their future automation projects.


The GSA owns and operates most buildings used by the civilian branches of the Federal Government. This amounts to about 8% of all office space in the United States. GSA is committed to improving the safety and comfort of the building occupants while simultaneously reducing energy and operating costs. Modern building control technology is a key tool for achieving these goals. As a government agency, open and competitive procurement is also a prime concern. GSA thus became interested in BACnet because it provides the common communication infrastructure necessary to achieve these goals.

In 1996, the Phillip Burton Federal Building and U.S. Courthouse located at 450 Golden Gate Avenue in San Francisco was selected as the site for the world's first large-scale commercial demonstration of the BACnet standard. The site, a 22-story 130,000 m2 (1.4 million ft2) office building, is the second largest office building in San Francisco and the largest Federal office building west of the Mississippi River. It was selected for this demonstration, in part, because it had little pre-existing EMS controls and recent renovations have made it comparable to typical commercial office buildings. The EMS retrofit also represented a significant energy-efficiency opportunity for the building with projected annual utility savings of over US$500,000. The project tests multiple EMS-manufacturers' equipment in one facility and their ability to cooperatively monitor and control building systems by utilizing the BACnet standard. In addition, extensive energy monitoring instrumentation, an operator workstation network, and communications equipment were incorporated into the EMS design to facilitate future energy assessment and research activity within the building.

Contract awards for the first two BACnet compliant vendors were made in August 1996. Associated construction activities were completed in January 1998, and the project remained on schedule and on budget since award. Follow-up phases of work will include BACnet-based gateways to an existing lighting control system installed on the building's GSA floors, a pre-BACnet-generation EMS installed on the FBI floors, and to provide direct communication with the local utility company. An extensive central plant renovation is also currently being designed for the building. In addition, discussions have begun with a fire system manufacturer that may result in integrating the building fire alarm system using BACnet.


One of the objectives of this project was to demonstrate the viability of integrating products from different manufacturers. For that reason the project specifications were prepared with the explicit intention of awarding portions of the work to different EMS vendors. The building is comprised of several agencies and HVAC types that present a natural distribution of vendor responsibilities. The overall design defined six scopes of work that could potentially be awarded to different vendors. These scopes of work were defined as follows:

Scope A: Provides a complete EMS installation for the main HVAC systems. These include 8 dual-duct VAV air handlers, more than 1000 terminal units, miscellaneous packaged and computer-room units, and selected central plant equipment (see Figure 1). This scope also included extensive end-use monitoring instrumentation so that the building's utility consumption can be tracked by end-use categories (e.g. cooling, heating, ventilation, etc.).

Scope B: Provides a complete EMS installation for the courtroom HVAC systems serving floors 17 through 20. These include 13 single-zone and one multi-zone air handler, all served by a dedicated chiller system (see Figure 2).

Scope C: Provides BACnet interfaces to control systems previously installed at the building. These include a pre-BACnet generation EMS serving the FBI offices on two floors of the building and an extensive lighting control system serving GSA offices on floors 3 through 5.

Scope D: Provides a complete EMS installation for all "zone-level" HVAC systems of the GSA offices located on floors 3 through 5.

Scope E: This future work assignment will provide a complete EMS installation for monitoring and control of central heating and cooling plant equipment. Alternate central plant configurations are presently being evaluated.

Scope F: Provides the Operator Workstation Network (OWN) for the EMS. The OWN provides building operators all routine access needs for interface to all vendor systems installed. This work included configuration and installation of a file server, operator workstations, mobile workstations, primary EMS interface software, and all cabling required for the project's BACnet "backbone" and interconnection hubs to each of the "A through E" installation areas.

Figure 1: Eight large dual-duct air handlers serve more than 70% of the building and were included in Scope A. The figure also depicts the manual and pneumatic controls that were decommissioned as part of the project.


Figure 2: Dedicated HVAC systems for distinct areas of the building facilitated the definition of a multi-vendor scope of work. Scope B included control of 14 penthouse unit air handlers and dedicated chillers that serve courtroom spaces.

A simplified schematic representation of the overall EMS concept is provided in Figure 3. It is important to note that there was never any commitment or desire to award each of the "A through F" scopes of work to a different vendor. Each manufacturer was encouraged to bid on multiple parts of the project. The selection process was based on the strength of the proposals and a combination of specific scopes of work that would best serve the objectives of the project while addressing the goals of GSA in a cost-effective manner.

Figure 3: EMS Schematic. With all critical zone level information exchanged using BACnet messages, building operators can view HVAC information from multiple vendors' systems through a common color graphic interface.

Communication Network Design

BACnet provides a number of options for using local area network (LAN) technology to design the control system and also ways to interconnect multiple kinds of networks within the same control system. This flexibility is a great strength for the standard because it makes BACnet application practical under many different circumstances. In a particular facility this flexibility can be a liability if not properly handled during the system design. Routers, devices used to connected separate BACnet networks, and gateways, devices used to connect BACnet networks to non-BACnet networks can be important tools for designing the control system. If used appropriately they provide the technology to bridge any common networking obstacle. If misused they can also complicate the system, make maintenance and troubleshooting problems more difficult, and provide bottlenecks to information flow. More detailed information about routers and gateways may be found elsewhere [3].

For this project, a single logical BACnet network using Ethernet technology was specified as the common communication backbone. All of the components of the operator workstation network and all of the primary field panel controllers were required to reside on this Ethernet network. Vendors had the option of using either BACnet or proprietary LAN technologies for their sub-networks of unitary and application-specific controllers. However, any non-BACnet speaking devices or networks were required to be supervised by a BACnet-based field controller residing on the Ethernet backbone and all of the system information must be accessible as BACnet objects. Figure 4 illustrates this configuration for a typical dual-duct air-handler system (which is the most common at 450 Golden Gate). Installed mixing-box VAV controllers are depicted in Figure 5.


Figure 4: Example EMS controller distribution for a dual-duct air-handler system.


Figure 5: The retrofit included DDC conversion of nearly 1200 VAV boxes of which both BACnet and non-BACnet speaking controllers were installed. Zone information from the non-BACnet controllers is translated to BACnet messages by supervising field controllers.

Operator Workstation Network Configuration

One of the most unique aspects of this project involves the operator workstation environment. Due to the multi-vendor configuration, ensuring effective operator training and a consistent operator interface were major concerns for GSA. To optimize operator efficiency and provide a uniform interface to the EMS, one vendor's workstation software (as per Scope F) was selected as the basis for common Operator Workstation Network (OWN) access. All other EMS vendors were responsible for coordinating with the workstation vendor to ensure that consistent color graphics, data presentation, and control parameters were established for all systems. Figure 3 illustrates a simplified view of the OWN configuration.

Subsequent to award, and as each individual vendor's system was tested and accepted, the Scope-F vendor was required to integrate each other vendor's EMS installation into its BACnet-compatible workstation software. As completed, this one workstation package became the primary multi-vendor access tool for the entire building. The result is a common and consistent method of presentation and access to all EMS information from any workstation, regardless of which vendor's EMS is being examined.

A primary design issue for the workstations and the OWN was the database organization and distribution. The 450 Golden Gate EMS is a large and complex system. The resulting network needs to maintain a consistent and up-to-date EMS database (e.g., controller configuration, programming, trending, operator color graphics, etc.) for the complete EMS installation. This is accomplished by storing EMS data on the OWN file server, thus supporting a centralized repository for trend data, third party and vendor-specific application software, and future research.

The File Server also regulates communications among workstations on the OWN as well as shared resources, such as files and printers. In addition to LAN management, the file server hosts the archiving and back-up services for the OWN. The OWN/EMS configuration also provides remote operator access to the EMS and automatic remote alarm reporting via telephone connections using the BACnet Point-To-Point (PTP) protocol. This dial-up access to the EMS provides the same interface and functionality as the directly connected workstations.

Utility End-Use Monitoring

The EMS design included extensive utility monitoring instrumentation to provide both GSA and the local utility access to building energy information for each primary end-use category (e.g., space cooling and heating, domestic hot water, ventilation, lighting, vertical transportation, plug loads). Instrumentation was provided for monitoring of both site energy consumption (e.g., electricity and natural gas) and delivered thermal energy (e.g., cooling and heating Btu's). This data is available in real-time and stored for historical record.

Conventional EMS sensors are used in conjunction with more specialized end-use instrumentation to provide a cost-effective monitoring design. For example, current switches and other status indications used by the EMS for start/stop "proof" of constant load devices (e.g., pumps, fans, etc.) are also used to track power consumption of these same loads. This is accomplished by defining pseudo (software) points based on "spot" kW measurements of the loads during system installation. These individual software points are then summed by end-use category into totalized values within the EMS.


The procurement process for the 450 Golden Gate project began shortly after ASHRAE's release of the BACnet standard in late 1995. The first step involved a detailed Request for Qualifications (RFQ) in which information was requested on numerous vendor's product lines, current and future plans for incorporation of BACnet communications, operator workstation environment, as well as more traditional information on local resources and Federal building experience. This review process led to the release of a more rigorous Request for Proposal (RFP) to six vendors in early 1996. It is important to note that the RFP release occurred shortly after ANSI adoption of BACnet. Thus, the project team was well aware that the 450 Golden Gate project was going to be a very early test of the "BACnet marketplace."

It takes several years for companies to develop a new product line. At the time proposals were solicited for this project there was a concern that there may not be a competitive bidding environment. Therefore, specifications indicated that BACnet communication was mandatory only for workstations and primary field panels. For communication between field panels and unitary controllers, proprietary communication options were acceptable. This could include a primary control panel serving as a BACnet gateway. Both all-BACnet and mixed-protocol designs were proposed by various vendors.

An evaluation committee comprised of representatives from GSA, the local utility, the engineering design firm, and NIST reviewed all vendor information submitted. The committee selected two vendors for the project. Scopes A, B, and F were awarded to one vendor and scope D was awarded to the other vendor. Funding was not yet in hand for the central plant retrofit defined in Scope E and no acceptable solution to integrating the existing control systems of Scope C was available at time of bid. However, the work of Scope C and E are currently being incorporated into a design package for a 1998/1999-construction phase. Thus, once the subsequent "C and E Scopes" are completed, the entire EMS will be comprised of control products from up to five different vendors.

Of the two vendors selected for the current construction phase, one system utilizes proprietary communications at the unitary controller level (e.g., VAV box controllers) with primary field panels serving as both controllers and gateways communicating via BACnet over the system's Ethernet backbone. The other system uses BACnet communication exclusively.


There is much that has already been learned from the 450 Golden Gate Project. In successfully demonstrating BACnet communications within a very large-scale project, some street mythology about BACnet has been clearly disproved. Consider four pearls of conventional wisdom about BACnet in light of actual project experience.

Myth 1: BACnet is not real, or at least not ready. It is true that it takes time for companies to develop new BACnet products. In general, the larger the company the more difficult it is to change quickly. It is also true that companies in the industry are still developing their BACnet product line. In spite of these facts there are real BACnet products available from multiple companies today. It is possible to find vendors who can meet stringent BACnet specification requirements even for a project the size of 450 Golden Gate. In some cases the participating vendors modified their planned product enhancement schedule to accommodate the requirements of this project, but all of the products installed are now readily available in the open marketplace.

Myth 2: BACnet is too complicated and expensive for low level controllers. There is no evidence from this project that BACnet products cost more than comparable proprietary products. There are over 1,000 BACnet unitary controllers operating in this system. Through a competitive bid process, there was no cost premium paid at any level for using BACnet.

Myth 3: BACnet messages are too big and inefficient. This may be the only EMS installation in the world that has actually been instrumented to examine issues such as network traffic patterns and message size distribution. The data collected includes continuous sampling of backbone traffic during even the heaviest traffic periods of system testing and configuration. Under these conditions, active workstation use and extensive trending were employed to verify correct system operation. Table 1 summarizes the data from two such samples. The first sample consisted of about 46 million messages collected over 30 days and the second sample consisted of 62 million messages collected over 41 days.

Table 1
Sample BACnet Message Sizes During Commissioning

Sample 1
(46 million messages)

Sample 2
(62 million messages)


% of Sample


% of Sample

60 bytes


60 bytes


61 128 bytes


61 128 bytes


> 128 bytes


> 128 bytes


Almost all of the messages are exactly 60 bytes long. Ethernet requires that message be at least 60 bytes long in order to be able to detect collisions. The fact that these messages are exactly 60 bytes long means that they have been padded to make them big enough to transmit over the Ethernet LAN. The implication of this is that BACnet messaging is so efficient that most messages are less than 60 bytes. This data clearly contradicts any claims that BACnet was optimized for large systems and is not practical for small devices.

Myth 4: Cooperation between vendors to solve problems will never happen. As with any large-scale construction project, there were some issues that came up while the system was being installed and commissioned. Partially configured controllers and missing or misunderstood information caused a few glitches along the way. However, at no time was there any difficulty isolating the cause of a problem, defining its remedy, and assigning responsibilities amongst the vendors. Thanks to careful planning, including inter-vendor submittal exchanges and productive progress meetings, the multiple vendors involved acted as a cohesive team throughout the construction period. In fact, the vendors on this project have indicated that such cooperation is typical of their other multi-vendor / multi-contractor projects - BACnet-based or otherwise.


There were some issues that arose during this project that are important considerations for others designing or specifying BACnet systems. It was mentioned that one of the vendors chosen for the project uses field panels that simultaneously act as a controller as well as a gateway to their unitary (non-BACnet speaking) controllers. The project specification clearly indicated exactly what information must be accessible through the gateway (a very important point for specifying engineers). However, when it came time to configure those field panels, concerns arose about having sufficient memory resources and processor time to perform both functions if all of the proprietary points were made accessible through the gateway. In the end some compromises were made to achieve a workable solution. Any system that has a gateway can have this kind of problem especially when an expansion takes place. Gateways are sometimes necessary but they always come with a cost.

BACnet does not define how to configure controllers (e.g., programming of sequences, addition or deletion of physical points to a controller's database, etc.). Therefore, it was clearly understood by all parties at the start of the project that proprietary vendor-specific tools would be needed for configuration of the installed systems. The intent of the specifications was to be able to install "stand-alone" versions of these configuration tools on the network file server, thus permitting access to these vendor-specific applications from any workstation. Unfortunately, this did not turn out to be possible. Even though stand-alone configuration tools would be very practical from the perspective of the user, it appears that most EMS vendors bundle these tools as part of their workstation software as a complete package. And, because not all vendors support the same PC operating systems, a separate PC may be required just for configuration of one vendor's installation. Pressure from users may cause this to change over time.

Although BACnet defines a file object and application services to read and write files, it does not define a file format for trend logging. Trending is important in most systems. At 450 Golden Gate trending was extremely important because of the need to collect data for the research aspects of the project. In order to make this work in a multi-vendor environment it was necessary to specify exact details of how trend data was to be collected and what file formats would be used for archive functions. The final methodology employed for trending is being reviewed by ASHRAE SSPC 135 and may be incorporated into the standard.

Finally, there is no industry certification program for BACnet products at this time. Finalization of specific testing procedures is a high priority of the SSPC 135 committee and many people are working toward a formal certification process. Fortunately, GSA was able to turn to the National Institute of Standards and Technology (NIST), one of the key players in the efforts to develop BACnet testing tools and procedures, for assistance in verifying that products on this job correctly implemented BACnet protocols. This kind of assistance is obviously not generally available. Companies in the industry have been working together to test products. It would be wise for consumers to ask for some evidence that a company has done thorough testing and has some kind of field experience in multi-vendor environments until a certification program is in place.


The BACnet implementation at 450 Golden Gate has been overwhelmingly successful. The timing of the project pushed the envelope of the controls industry and the marketplace. Within less than a year from ASHRAE/ANSI adoption of BACnet, a competitive procurement process was launched to demonstrate the viability of the technology and assess the EMS industry's acceptance of interoperability. Though the timing of the project limited the number of vendors available to participate, nearly every major player in the industry enthusiastically responded to the initial RFQ.

The project has proved that BACnet works as intended. In a real building and under real-world construction conditions, EMS products of multiple vendors were installed, networked over a single Ethernet backbone, and configured as part of a network of workstations running a common operator interface package. The result is a fully integrated building-wide EMS comprised of multiple manufacturers systems, but operating as a single system in terms of an operator's daily interaction with the entire EMS.

The cooperative spirit amongst the vendors led to a valuable exchange of information and a continued evolution and improvement of respective product lines. This in turn has strengthened the understanding of the BACnet standard amongst not only project participants, but also the industry at large. Continued penetration of BACnet into the marketplace is inevitable. The challenges remaining are education of owners as to the benefits of interoperability, improving the understanding of EMS and BACnet technology amongst the design community, and an eventual "re-tooling" of the controls contracting industry for delivery of truly integrated building automation solutions.


1. ANSI/ASHRAE Standard 135-1995: BACnet - A Data Communication Protocol for Building Automation and Control Networks, Atlanta, Georgia: American Society of Heating, Refrigerating, and Air-Conditioning Engineers.1995.

2. Bushby, S.T., Personal communication with representatives of the 21 members of the NIST BACnet Interoperability Testing Consortium.

3. Bushby, S. T., Communication Gateways: Friend or Foe?, ASHRAE Journal Vol. 40, No. 4, April 1998.

About the Authors:

Martin A. Applebaum, P. E., is a Senior Vice President of ESS, a consulting engineering firm specializing in energy-efficient building design and analysis, building automation, and energy information systems. Mr. Applebaum is the Engineer of Record for the 450 Golden Gate Project.

Steven T. Bushby is an engineer in the Building and Fire Research Laboratory, National Institute of Standards and Technology, Gaithersburg, Md. He is vice-chairman of ASHRAE Standing Standard Project Committee 135, BACnet A Data Communication Protocol for Building Automation and Control Networks. He also manages the NIST BACnet Interoperability Testing Consortium.