By Jeff Crane, P.E., LEED® AP
Published in the September 2006 issue of Today’s Facility Manager
Since the late 1980s and early 1990s, suppliers and trade organizations have been promising facility managers (FM) better building management technology. While desktop computing, the Internet, and business software applications shift into overdrive and scream down the information superhighway (faster than most organizations can keep up), FMs continue waiting for their suppliers to get out of second gear.
While we can acknowledge and appreciate the vast improvements in building technology that have been made over the past 15 years, anyone operating, specifying, or purchasing a controls system for lighting, card access, HVAC, energy management, emergency power, or fire protection equipment knows that the concept of interoperability is a joke. Despite grandstanding from suppliers and trade organizations for creating and complying with “open communications standards” such as LONWORKS® and BACnet, most building controls are extremely proprietary and completely foreign to one another.
There are independent controls vendors who can build a single interface for a variety of equipment vendors. But that can be a fairly expensive approach, especially when it requires major customization (usually from the same controls supplier) each time equipment is added to a building or campus.
Why should we care about this? Because it’s frustrating that building controls interoperability lags about 15 years behind other technology development curves.
Let’s compare a building to a simple desktop PC. When we buy a printer or a scanner, do we make sure it came from the same supplier who sold us the computer? Of course not!
Imagine engaging an “IT integrator” simply because we purchase a larger monitor or a new digital camera. Or think about needing a separate computer for each different type of audio file (.mp3, .avi, .wav, etc.) or digital image (.jpg, .bmp, .tiff, .pdf, etc.) we might wish to open. We can connect a portable projector from practically any manufacturer, and our PC quickly recognizes it and cooperates.
Building controls should be the same way! Multiple buildings and control systems should be capable of networking the way we network computers. We should be able to monitor and diagnose systems through a common operating system. So why can’t we?
Thanks to our suppliers’ collective resistance to cooperation and true open communication protocol (also known as “playing nicely with others”), if we purchase three chillers, 12 air handlers, and an HVAC software controls package from ABC Company this year, odds are very high that all future purchases of HVAC equipment will come from ABC Company. Why? Because we need to continue using our HVAC software, and it usually won’t work with other vendors’ equipment.
If we do wish to buy our next two chillers and our next five air handlers from XYZ Company, it won’t be easy. Options might include the following:
- Invest in a “translation project” that would allow ABC Company’s software to monitor and control XYZ Company’s equipment. (Note: this cost can be comparable to hiring a dozen UN translators from Switzerland at hourly fees plus travel expenses.)
- Standardize on XYZ Company’s equipment and software, and spend a fortune retrofitting all of ABC Company’s equipment accordingly (until the next project, when ABC Company best meets our needs and we need to start the process all over again.)
- Purchase and implement a second HVAC controls software system (from XYZ Company) to monitor and control XYZ Company’s equipment.
- Cave in and buy the new gear from ABC Company, recognizing that as long as we have proprietary controls, we won’t have competition or cost effective options.
This simple example doesn’t even contemplate a more ambitious capital project that might have included integration of a third vendor’s lighting controls package, a fourth vendor’s card access system, a fifth vendor’s generator, and a sixth vendor’s UPS. Because of the proprietary nature of all these systems and the cost prohibition of interoperability, FMs and maintenance departments are typically forced to maintain multiple controls systems (often on separate, dedicated servers to avoid incompatibility and data corruption).
Over the past 15 years, computer hardware manufacturers have continued to improve their products and create many new ones. Meanwhile, building equipment suppliers have spent that time locking up their customers with second rate software that only speaks one language. In considering the PC analogy, it was probably the dominant market position of Microsoft’s Windows operating system that prevented other hardware manufacturers from similar communications competition and caused development delays.
Hopefully, our industry’s technology evolution will pick up momentum and catch up. Perhaps the original equipment manufacturers (OEMs) will recognize that competition makes everyone better. Maybe the more confident suppliers will drive change so they can sell more equipment to their competitors’ imprisoned clients. Or perhaps an enterprising FM turned software developer will create a building controls operating system that is so powerful, affordable, and so universally useful that we’ll all adopt it as an industry standard, and the rest of the OEMs will be forced to cooperate.
Crane is a mechanical engineer and regional property manager with Childress Klein Properties, a leading real estate developer and property management services provider in the Southeast.
