Reports From the Field: Open Controls

Well over a decade ago, concern about the proprietary communications methods for building control systems led the industry to ponder a change. At the time, many building owners—and system designers—felt that they were at the mercy of particular vendors for the installation, maintenance and upgrade of building automation systems.

By Jeromie Winsor, Web Editor June 1, 2002

Well over a decade ago, concern about the proprietary communications methods for building control systems led the industry to ponder a change. At the time, many building owners—and system designers—felt that they were at the mercy of particular vendors for the installation, maintenance and upgrade of building automation systems.

And while the development process of interoperable control systems has sometimes left much to be desired (see “Diagnosing the State of Interoperability,” p. 42), there have nevertheless been a number of projects capitalizing on the “openness” established by products using standard protocols like BACnet and LonWorks.

Two recent projects illustrate how modern controls equipment has the ability to be more open and interactive, and allow facilities options for future system upgrades. The first, a new corporate headquarters for Echelon—the developers of the LonWorks standard—displays a single, sophisticated control system that is comprised of interactive components from a variety of manufacturers. The other project, a retrofit, offers the example of an entire city—Tucson, Ariz.—breaking away from the grips of a proprietary control system and converting to a system that uses a BACnet-based control backbone and also integrates existing proprietary controls into the system. In both cases, “going open” was the only option.

Echelon Headquarters

San Jose, Calif.—the cradle of modern computing technology—is now home to another technological marvel of sorts: the new Echelon Corporation headquarters.

Admittedly, it is a showcase for the LonWorks platform of open, interoperable device networks, but that was not the only factor driving the creation of this facility. Echelon was also trying to display how modern controls can minimize energy usage in an expensive energy market, as well as provide comfort for employees.

“We have to work in the building every day, so we wanted it to be a great environment for us,” says Steven Nguyen, director of corporate marketing for Echelon. “And we wanted employees to be involved in the energy management program for the building.”

As a result, each space within this three-story, 77,000-sq.-ft. building has a programmable room manager controller to personalize light and temperature setpoints for occupied , standby and unoccupied modes. This setup fits Echelon’s travel-and-telecommute business style, where approximately 25% of the building occupants are away from the office at any given time.

While the level of control is certainly a key feature of the building control system, the most distinctive facet is the amount of “interoperability” in the design. The facility’s building-management network integrates monitoring and controls for HVAC, lighting, security, elevators and many other functions (see Table, p. 43), as well as control components from nearly 20 manufacturers—a project stipulation from Echelon.

Due to the complexity of the project, Teng & Associates, Chicago, was selected as the lead system integrator on the project—a role they fit into naturally considering the firm has been a member of the LonMark Interoperability Association since its inception in 1994. On this particular project, Teng designed the control system, and worked with the contractors on its installation.

According to Tom Lohner, P.E., vice president with Teng, the project did entail a significant amount of time and cooperation.

“For a typical building, the consultant would spend maybe a week to put together a basic performance specification,” Lohner asserts. “We went beyond that and designed the physical infrastructure of all the Lon products.”

In keeping with the project goals of energy management and interoperability, Teng conducted a detailed analysis using the U.S. Department of Energy’s DOE-2 energy simulation software to compare the costs and benefits of a conventional control system to integrated, interoperable controls. By analysis, it was found that the extra money needed to tie the systems together could be paid back through energy cost savings in less than 10 years. And this analysis did even not take into account the cost benefits of competitive bidding for service, maintenance and upgrades.

Because this was a “demonstration” project, many items in the system could have been done more cost effectively. The individual level of control, with over 1,000 governing devices, increased first cost, and the robust control software—although it allows for impressive system displays and maneuverability—was actually more than a similar project would have required. But Lohner agrees that, overall, the new facility can serve as an example of open-control system interoperability and savings for a variety of buildings.

“There is really a lot of standard equipment in the building,” he maintains. “Maybe 75% of the equipment is fairly standard. The thing that is unusual is the sheer number of items being monitored and controlled in the system.”

The total project has not ended either. According to Nguyen, Echelon has plans for a “twin” facility to be built on a site adjoining their new building. When it is finished, the control system for the new facility will be integrated with the existing facility’s system.

City of Tucson

In suit with Echelon, many new facilities, learning from the past, are choosing open-protocol control systems. However, there is also a growing number of existing proprietary control systems that are being replaced rather than upgraded. One recent example occurred in Tucson.

During the late ’90s, the centralized control system that had managed HVAC for a number of city-operated buildings was reaching obsolescence. As malfunctions occurred within the proprietary control system, city administrators realized that they were losing money with each upgrade by basically being locked into a noncompetitive service contract.

Thus, when the city set out to create their new energy management and control system (EMCS), one of the stipulations was to create a system that had the BACnet protocol coming out of each of their buildings. In addition, the city wanted their building controls to tie into their wide-area network.

The existing control system managed 40 buildings on 20 different sites—which added up to over 7,000 control points. As this control system grew over the years, newer technology was integrated with original controls. As a result, a good number of these buildings were still working on control panels from the 1970s, especially the older buildings in the downtown area.

Palmer Engineers, Tucson, was chosen to design the system in cooperation with ESS Engineering of Tempe, Ariz. Jim Palmer, P.E., principal of Palmer, was involved from the beginning of the process, and helped choose the particular control system and contractor.

“The four proposals [from controls contractors] were reviewed to see how they complied with the spec, as well as the dollar amount,” he explains. “Of the two lowest in price, only one offered a completely BACnet solution.”

The chosen contractor, Climatec of Tucson, came in with a proposal that allowed the city to keep much of its newer control hardware in place, while still having a “single seat” BACnet interface for all network communications.

So far, the first phase of the project has been finished, with roughly half of the city buildings converted to the new, BACnet-based system. The overall plan for the upgrade involves removing almost all of the old control hardware from the downtown buildings and replacing it with BACnet-enabled hardware, with all of these buildings then connected via a WAN. This was fairly straightforward, with the design reusing as much of the existing cable, wire and conduit as possible.

At the same time, the facilities with more modern, PC-based controls are being converted, via gateways, to a BACnet communications protocol. Using a brand new type of field controller which, according to Palmer, was only introduced during the project’s design stage, the new BACnet system is able to communicate over the WAN with the existing proprietary hardware.

The result is a control system that has accomplished the stated goal of freeing the city from the proprietary system.

“The system has gone from 100% sole source to 95% competitive—at least for those that can provide a BACnet solution,” says Palmer. “[The control-system vendor] would need to be involved in about 5% of any upgrade project, basically to integrate the points to their front-end [interface].”

Besides being more open for future upgrades and installations, Palmer says that the control system gives system operators a much quicker, cleaner user interface than before, with more specific alarm signals as well. The rest of the city buildings are scheduled to be completed in the next year.

Table – Echelon HQ Control System

Subsystems Making up Single Control System

Interior Lighting

Door Access
Intrusion Detection

Elevator Monitoring
Power Monitoring

Fire Alarm


Domestic Water
Natural Gas Monitoring

Exterior Lighting

Product Vendors used in Control System


Continental Control Systems
Control By Light


Douglas Lighting

Engenuity Systems


Neurologic Research

Sierra Monitor

Thyssen Dover


Diagnosing the State of Interoperability

Over the last decade, efforts have been made by a variety of industry organizations to create an open, universal protocol for digital communication between building-control components. While a great deal of progress has been made, most would agree that the development of interoperable control systems has not been as smooth as anticipated.

“Ten years ago, we thought that by this time everything would be ‘plug and play,'” says Kim Shinn, P.E., division director, Tilden Lobnitz Cooper, Jacksonville, Fla. “For example, when you buy a home computer system, all of the accessories—printer, scanner, etc.—can be pulled out of the box and connected with cables. Even though they may come from a variety of manufacturers, there is not a problem with these components interacting because they can recognize each other. This is still not the case in the environmental control world.”

Shinn, who is TLC’s self-professed “in-house interoperability guru,” has been intimately involved in the development of BACnet, the standard protocol maintained by ASHRAE. According to Shinn, one of the biggest problems has been the difficulty of keeping up with technology in a computing environment that reinvents itself every one or two years.

And in addition to the challenge of keeping up with technology, the most widely used communications protocols for environmental control—BACnet, LonWorks and, to a lesser degree, Modbus—have also had the challenge of keeping up with one another, as various industry organizations and manufacturers have devoted a lot of money to one protocol or another—”placing their bets,” so to speak.

“The big standards all have a vested interest in continuing to hold on to their technology, hoping it will become equivalent to an industry standard,” Shinn says. “In fact, it might be time for all three [sides] to stop and look at what the wider IT world has been doing [in terms of interoperability].”

At the same time, there are those that claim that the lack of a single, standard protocol is only a small obstacle in the larger quest for true interoperability. For example, Tom Hartman, P.E., principal of The Hartman Company, Marysville, Wash., actually considers it possible that “gateways”—the translators necessary to connect devices using different protocols—offer a more realistic path to interoperability than focusing on a single protocol. Instead, Hartman points out the networking and software issues facing control products, and predicts that a major shift needs to happen before interoperability can occur.

“The endpoint will be different than many expect because it will involve an integration into the mainstream of computer network communications and programming,” he states. “The road ahead will force a complete restructuring of the building controls industry. The natural path requires that controls transform from the hardware-based industry that it is now to a software-based one where hardware is a cost of doing business instead of the primary product.”

Industry adoption

Despite the lack of a de facto standard—and the networking and software issues still to be sorted out—many building-control experts see interoperable projects becoming the norm, and benefits being reaped.

“It is becoming rare that you are going to see a new project done without some kind of open protocols,” says Ira Goldschmidt, P.E., with RNL Design. “Most projects are going to use one or the other [BACnet or LonWorks].”

The reason, according to Goldschmidt, is that control manufacturers have pretty much been forced to adopt some level of interoperability with either BACnet or LonWorks—or both—even if there are gateways involved.

“You can even try to spec something proprietary,” he continues, “but most likely, it will end up being an open system in the end.”

In addition, building owners and operators—especially those who have had unfavorable experiences with proprietary systems—are becoming more aware of the benefits of open control systems, to the point where they are stipulated on many projects.

Even if an open-protocol system is not chosen, owners may still reap benefits from the competition they bring to the market. Shinn cites projects that he has been involved with where the availability of an open-protocol competitor drove down the bid price for proprietary vendors. On a couple of projects, even though the owner decided upon a “closed” spec, the vendor acquiesced to providing a long-term, fixed rate maintenance contract rather than allow the facility to go “open.”