One of the big selling points of integrated building systems is ease of use. No more jumping back and forth between different PCs. Less training. Simpler ways to save energy, to make occupants comfortable and to keep up with changes in the way a facility is used. No wonder facility-staff friendliness often has often topped the list of benefits of integrated systems.
Building systems integration, facility executives were often told, would soon be “plug and play” thanks to the introduction of BACnet and LonWorks.
So why then is the process of actually integrating systems often still anything but easy?
That question amounts to what might be called the bad news about systems integration, as extensive interviews with facility executives, vendors and system integrators make clear.
But there’s a good news side as well: Most facility executives are satisfied with the integrated systems they have, even if they’re unhappy with some aspects of the process of integration, according to a survey of Building Operating Management readers.
What’s more, although the move to interoperable systems has been slower than facility executives might like, progress has been steady. One industry observer sums it up this way: “I would not say it’s the kind of plug and play we have with computers. But there are standards that make it a lot easier to integrate than it was in the past.”
Given that facility executives are generally pleased, does it really matter how that result is achieved? There are good reasons to think it does. For one thing, a system can be satisfactory without being the best option for a facility. More and more, facility executives have a choice between open and closed systems. But that doesn’t mean it’s easy to make the right choice. Systems have different strengths and weaknesses; even when they seem to offer the same functionality, they may implement features in different ways.
Then there’s the question of avoiding headaches. Facility executives who go into a systems integration project with their eyes wide open — armed with a solid sense of the challenges and choices ahead of them — are far less likely to be hit with unpleasant surprises, like finding out that the budget isn’t adequate to achieve the initial goals of a project or that a supposedly interoperable system is not nearly as open as it seemed.
It’s impossible to grasp the dynamics of system integration without understanding the varying backgrounds, skills and motives of people involved in the process of linking systems. That’s the topic of this article, the first in a three-part series on system integration. The second part will examine misconceptions that surround BACnet and LonWorks. Part three will describe key choices that should be weighed in the early stages of planning for systems integration.
System integration is an umbrella term that, at the most basic level, refers to links between elements of the HVAC system — still far and away the most common form of integration. The next step up is connectivity between HVAC and other systems, like security or fire safety. At a still higher level, an integrated system may tie together building control systems and facility management software packages like CAFM (computer-aided facility management) or CMMS (computerized maintenance management systems). The newest approach entails hooking building systems into company-wide business applications like enterprise resource planning, or ERP.
Despite the sloppiness of the term, the appeal of integration is easy to see. When systems aren’t linked, there are separate workstations for different building systems, each with its own screens and commands to learn. Worse, someone on the facility staff may have to run out to an individual piece of equipment to investigate a problem or change the way the unit is operating.
Looking at disparate systems from a single workstation is the biggest benefit of integrated systems, say respondents to a survey of Building Operating Management readers. Setpoints can be changed and problems diagnosed and even solved with a few clicks of a mouse.
A single graphical user interface makes life simpler; more important, it saves time and money. “I can spend 15 minutes with you and you’ll know how to get around the system,” says one facility executive in the process of integrating systems on a large campus. “With seven systems, it’s 15 minutes times seven — at least.”
That’s far from the only benefit. Integration can bring lower labor costs, smoother operations and better information. An integrated system may provide sophisticated controls to manage energy-hungry building systems. Even if control capabilities are limited, simply having the ability to monitor chillers, boilers and other equipment can bring significant energy savings.
Integration can reduce the time it takes to respond to problems. At higher levels, integration may offer information-sharing and control options that improve maintenance, enable facilities to tap utility incentives or beneficial rates, provide building users with some control over operating parameters for building systems or feed facility performance data to top executives.
If there are complaints about integrated systems, they’re generally not related to performance. The survey of Building Operating Management readers shows that most respondents ultimately get what they expect from integrated systems. What’s more, they’re generally pleased with the technology itself and to a lesser extent the service they receive.
But those survey results mask an underlying frustration that comes up again and again in conversations with facility executives. One common concern is being locked in to an unsatisfactory service provider. Because it is difficult to switch from a provider when problems arise, those problems loom large for facility executives. Even when facility executives are largely satisfied with service, they’re uncomfortable being locked into a service provider.
Another major source of frustration is the cost of service and upgrades. Historically, controls vendors have counted on a steady stream of revenue from lucrative service contracts and upgrade projects. When systems didn’t communicate with one another, facility executives had little choice but to go back to the original vendor for upgrades — and to pay what the vendor charged. One facility executive who has extensive experience with control systems estimates that he pays 35 percent more than he would if he could solicit competitive bids.
No wonder facility executives looked forward to the day when they could solicit competitive bids from multiple vendors. That’s why facility executives pushed to have vendors make their products interoperable — able to share information and control functions directly with one another without the need for a device to translate from one system to another. If all devices were interoperable, facility executives could purchase products from different vendors based strictly on price and performance, then connect those products to a common network regardless of who made the products.
But facility executives see many obstacles on the path to interoperability. One hurdle is what facility executives consider to be strong-arm tactics on the part of some vendors.
As part of a major expansion, one organization hired contractors that could integrate equipment into a pair of existing proprietary systems without going through the vendors of those systems. Each time, the vendors were “furious,” says the facility executive involved. “We told them to go pound sand in both cases. It really gets on your nerves.” But those experiences haven’t poisoned the relationship between vendor and customer: The facility executive is considering an outsourcing arrangement under which the vendor would integrate, upgrade and operate building systems; the two organizations would share the savings.
The move to interoperability will likely increase the friction between facility executives and incumbent vendors, especially when there are many buildings at stake. On one campus, the incumbent vendor “went berserk” when it lost a major controls project, says the facility executive involved. The vendor tried to get the facility executive’s boss to reverse the decision. The boss wavered, nervous about the risk of something going wrong, then decided to support the facility executive. Had the decision gone the other way, a campus-wide open-systems initiative might have been jeopardized. “But we got through it,” says the facility executive. “Now we’re on the way to success.”
In cases like those, vendors will argue that their goal is to protect the customer’s organization from having a major investment put at risk by an ill-advised attempt to save a few dollars. But facility executives don’t see it that way. “They’ll swear up and down that we’ll limit ourselves on functionality,” says one facility executive who has had to deal with the situation. “But the real message is, ‘You have to deal only with us.’ ”
Stories like those fuel a widespread belief that some control system vendors are dragging their feet on interoperability. Another indication of resistance: Vendors who bid an interoperable system to meet the spec on a project, then offer a lower price if their proprietary system is installed instead. That way, the vendor virtually locks in service contracts and upgrades for years to come.
The reason for resistance to interoperability, says one mid-sized vendor, is simple: “The economic value of offering interoperable systems has not been quantified for many control system companies.” Facility executives want to reduce costs and improve performance; vendors want bigger markets and higher margins. Today, those sets of objectives are “completely incompatible,” he says. Although some smaller vendors have used interoperability as a point of differentiation, the business models of major vendors have been built around proprietary systems.
But even vendors in the forefront of the move to interoperability have sometimes played competitive hardball. For years, there were what one industry observer calls “widget wars” between companies that build systems on BACnet and those that use LonTalk, with each side taking shots at the other. Today, most vendors agree there’s a place for both protocols, but the years of sniping created confusion in the market that undoubtedly slowed progress on interoperability.
Another complaint by facility executives is that equipment manufacturers “hide” points. Facility executives aren’t happy about the idea of paying thousands of dollars for a gateway to get access to points that are already available on the control panel of a piece of equipment.
In response, manufacturers say that some points aren’t available at all for safety reasons. “You don’t want anyone mucking with the setting for internal pressure,” says one controls vendor. What’s more, there may be engineering costs involved for the manufacturer to make points available to other systems. “It costs a lot more to be open than to be proprietary,” says one equipment manufacturer. “I don’t know if there’s much difference in price for customers, but there is a difference in cost for us.”
The question of how much information should be made available plays out in meetings of the committees that flesh out the nuts and bolts requirements of BACnet and LonMark. “There’s a mountain of data in there,” says one equipment manufacturer. “And practically no one knows what to do with it. So why would you want to share it?” But the fewer points that are open, the more difficult it may be to integrate systems to achieve a facility executive’s goals. And goals are the essence of the matter, says the manufacturer. “What information is a customer willing to pay for? What are they going to do with that information?”
Facility executives should remember that, despite obstacles, substantial progress has been made on the path to interoperability. The result is that, today, facility executives can choose from a range of interoperable devices and systems. And that range is growing. After all, even with the best of intentions, it’s impossible to convert a proprietary product line to a standard protocol overnight. The bigger the product line, the longer the transformation will take. What’s important is to ascertain whether the vendor is moving to use standard protocols, and how those protocols are being implemented.
If vendor reluctance to open their systems is one impediment to system integration, other obstacles can be traced directly to facility executives. One common problem, say many vendors, is a lack of knowledge about what it takes to integrate systems, especially legacy systems.
Exactly how difficult it is to link existing systems depends on a range of factors — including the architecture of the old system, the hardware involved and the goals of the integration project. Sometimes integration is impossible, and even when it is possible to connect systems, functionality is often lost and gateways are almost always required. All of that can lead to unpleasant surprises when facility executives start receiving bids. “What they want and what they realistically can do are far apart,” one vendor says.
The only way to know what the integrated system will deliver — and what it will cost — is to lay out a very precise specification. But the news isn’t good when it comes to specifications.
“How often do we see a good spec?” one vendor asks. “Between 0 and 1 percent of the time.”
In some cases, vendors say, the facility executive can’t even provide a sufficiently detailed description of the objective of the project — the basis of a good spec. “They don’t know what they want or can’t articulate what they want,” one vendor says.
Ideally, consultants would work with facility executives to develop integration programs based on business goals. “You have to start there,” one facility executive says. “But consultants don’t get the money to go that deep.”
In-house staff may come up short in another area, many facility executives acknowledge: operating expertise.
An integrated system requires a good deal of tweaking to optimize its performance for a specific building, one facility executive says. “But in many cases, the staff doesn’t have the time, the expertise or the interest to do that.”
The operating staff often has a far better handle on the mechanical equipment than on the software that runs the system. If they can’t get the system to respond the way they want it to, they may solve the immediate concern in a way that unleashes a cascade of other problems. For example, if a comfort call comes in, a mechanic may disconnect a damper actuator and rig the damper into a fixed position instead of letting it modulate according to system commands. Because the system isn’t modulating properly, temperatures start to make radical swings.
“You see work order tickets rising, energy costs increasing and customer satisfaction declining,” says one facility executive. “It just becomes a black eye.”
If some operating personnel are in over their heads with sophisticated systems, others have built up a wealth of practical knowledge about the way the building performs. But organizations don’t always mine this valuable in-house resource.
That problem can arise when the group responsible for design and construction doesn’t get input from the people who will operate the facility. One facility executive describes a major technology company that has a sophisticated building automation system but monitors only one point of a major server room. The reason: The server room was left out of the design of the building automation system.
“The biggest flaw out there today is that the operations group isn’t integrated into the project management team,” another facility executive says. “And in my observation it’s getting worse, not better.” That problem is compounded when responsibility for operations is assigned to one outsourcing firm, while another handles construction project management.
Overcoming the divide between operations and design and construction takes time and patience. One approach is demonstrating the cost of not having well-designed controls — for example, by describing the problems poorly designed control systems have caused on other projects in the company. In some cases, that may mean going to the business unit that will ultimately pay for the facility and finding someone with enough clout to force the design and construction group to listen to operational concerns. “You have to find the right champion,” says one facility executive who has fought battles like that. “It isn’t always easy.”
There are other ways internal politics complicate systems integration. Consider the case of a facility executive deciding whether the integrated system should ride on the company network. Friction between facility management and IT could lead the facility executive to install dedicated cabling for the integrated system to avoid being dependent on the IT department. Or a company’s internal chargebacks could actually make it less expensive — at least on paper — to install new cabling dedicated to the integrated system than to use the existing company network.
It’s no surprise that vendors and customers see things differently or that stretched-thin facility staffs may lack the resources to develop expertise on systems integration. So why do most facility executives who integrate systems end up essentially pleased with the results? Sometimes the process itself can provide a form of on-the-job training that, while difficult, enables the facility executive to muddle through. More importantly, the new integrated system may well offer so many capabilities that it’s worth the investment — even if an alternative might have been a better choice.
The distinction between good and better approaches to system integration is especially important when a facility executive is deciding whether to specify an interoperable system. With interoperability, complex technology has given rise to a sometimes baffling jargon that has made it much harder for facility executives to get what they want. The second part of this series will look at what it takes for facility executives to talk the talk about interoperability — and why that’s become a crucial part of the process of integrating systems.
Mark Behar, Brian Stowell Alerton • Jay Pitcher Althoff Industries • Steve Gavlek American Auto-Matrix • Rick Focke, Don Lemenanger, Jon Williamson, Rainer Wischinski Andover • Steve Tom Automated Logic • Ron Caffrey BCS Partners • Jonathan Fulton Building Control Integrators • Kirk McElwain CABA • Mark Tozzi Carrier • James Lee Cimetrics • Mike DeNamur Comfort Systems • Brian Crimmins Crozer Keystone Health System • Raymond Rae, Brian Dutt Delta • Steve Nguyen Echelon • Jim Shulkin Essention • Marty Emmick, Bill True Fidelity • Stephen Ferree FieldServer Technologies • Sanjiv Bhaskar Frost & Sullivan • Dean McCauley, Steve White GSA • Robert de Grasse Grubb & Ellis • Tom Gormley, Byron Hall HCA • John Hatcher HMA Consulting • David Robinson, Thomas Bay Hines • Simon James Honeywell • Ralph Box, David Gill, Kevin Strohman Invensys • Terry Hoffman Johnson Controls • Thomas Plating Jones Lang LaSalle • Don King Kaiser Permanente • Barry Haaser, Jeremy Roberts LonMark Interoperability Association • Jonathan Buckley McData • Mark Bergman McQuay • Lenny Jachimowicz Marriott • Steven Bushby NIST • Ron Sharpe The Ohio State University • Jim Damico Osceola District Schools • Jay Hendrix, Christopher Hollinger Siemens • Mark Rehwald Staefa • Dean Meyer TAC • Pat Jastroch T. Wall Properties Management • Roger Schenck Technical Solutions & Services • Charles Beach Team Engineering • Andy McMillen Teletrol • Jay Althof, Randy Amborn Trane • Dennis Tuft Tridium • Carl Ruther University of Cincinnati • Victor Atherton University of Miami • John Vucci University of Maryland • Kurtis Johnson University of Wisconsin • Hank Marier Wells Fargo • Jack Gornik York
