Interoperability has been widely promoted as an effective tool to improve the performance of facilities while reducing operating costs. And to a large extent, that’s true. A well-designed interoperable system that is matched to the requirements of the facility can improve performance and reduce operating costs. Interoperable systems have lower lifecycle costs as a result of more competition between system and component vendors. The use of a single user interface lowers training costs while increasing data accessibility. Greater access to data allows better management of resources and facilities. Integrating what once were independent functions into a single, interoperable system makes operations more flexible and efficient.
Although interoperable systems offer tremendous benefits to facility executives, they have sometimes been overpromoted, resulting in unrealistic expectations as to what the systems can do and the level of support needed to make them perform. These unrealistic expectations have led to disappointment for facility executives who expected too much or did not stay fully engaged in the selection and installation process. It is essential that facility executives understand what the systems can and cannot do and what is required to get a fully functioning system that meets the needs of the facility.
For example, along with their benefits, interoperable systems do have one significant drawback: complexity. Proprietary systems are fairly simple in their installation, at least for the facility executive. The facility executive and the system designer simply select the system that best meets their needs. With open system designs used in interoperable applications, there are more choices available. These choices mean flexibility, but also complexity. As a result, facility executives must be more involved in the entire process if an interoperable system is to be successful.
Unfortunately, facility executives entering into an interoperability project often underestimate the time and effort they need to invest in the process. They try to take the same approach that they do with other facility projects: either hire a design professional or develop the project specifications in-house, put the project out to bid, monitor construction, then take over operations once the completed project has been turned over. This process will not work well with projects involving interoperable systems. Facility executives must take a much more active role.
Start by defining interoperability expectations. What is it that the system should do? What currently independent systems are to be interconnected in the new system? What information generated within the system will be made available to the enterprise? Carefully spell out these expectations, as they will be the basis for the system design. But in developing these expectations, be careful. While interoperable systems are powerful and very capable, they are not unlimited. Expectations must be balanced against reality and practicality.
Most facility executives will use an outside engineering firm to assist on the project from development of the specifications for the system, through installation oversight, to the system testing and performance verification.
These are essentially the same steps all facilities go through when implementing a construction or major renovation project. But unlike those other projects, facility executives cannot start the process, turn over responsibility to the engineering firm and wait for the project to be finished. There are too many issues that require the input of facility executives. Control points to be connected; the location and type of sensors to be installed; how the controls should interact with the installed building systems; how system data is to be integrated with the enterprise: Facility executives must participate in deciding issues like these.
One of the most important questions that facility executives must answer early is whether the project is to be bid based on specifications, or if RFPs are to be solicited from qualified firms. There are advantages and disadvantages to both approaches.
Traditionally, the bid and specification approach has been the preferred method. An engineering firm is selected. The engineer works with the facility executive to develop a list of points to be included in the system, the architecture of the system and how various software components should function. The engineer oversees the construction and the post-construction inspections. Once the engineer is satisfied that the project has been completed as specified, it is turned over to the facility executive.
While the specification and bid process works well for most facility projects, it is not particularly well suited for installation of interoperable systems. One of the most significant problems with the process is the time required. The time from when the engineering firm is selected until the project is awarded can be up to two years. In conventional construction projects, this time delay has little impact on what is installed. While building systems and components are evolving, the rate of change is relatively slow. In the controls and building automation fields, the rate of change is much faster. In the time that it takes to develop and bid the specifications, the technology will have changed significantly. Using the spec and bid process can mean that the system’s technology may be dated by the time the project is awarded.
Another problem with the spec and bid process is that it forces bidders to be highly competitive. While competition may seem to reduce first costs, it also creates a situation where it is to each bidder’s advantage to bid the lowest cost system that meets the design specifications rather than the most advanced system or the one best suited to the facility. Selection is driven by cost, not technical merit.
An alternative to the spec and bid process that can work well with the installation of interoperable systems is the RFP. An engineering firm, working with the facility executive, would be used to develop the RFP. The RFP would include the list of points to be connected to the system. But the RFP would not specify the details of how the system is to be configured. Instead, it would focus on the desired outcomes of the system: what is connected and its capabilities, for example.
RFPs allow facility executives to purchase a leading-edge system based on technical factors as well as cost. Since they do not lock bidders into a technology that may already be two or more years old, it gives facility executives the ability to take advantage of developments and new technology in a rapidly evolving field.
The RFP process is not without drawbacks. Because the “how” is not spelled out in a detailed specification, vendors may be submitting proposals that are based on widely differing technologies. Evaluating these proposals is not an easy task. It will require a detailed analysis along with site visits by the engineer, facility executive and system managers. Requiring that vendors be prequalified will help ensure that only reputable companies are allowed to submit proposals.
No matter which route is used, the facility executive will have to be highly involved throughout the entire process.
It is widely accepted that, over the life of the system, an interoperable system will have a lower lifecycle cost than a proprietary system. On the other hand, it is generally believed that interoperable systems are more expensive to install, typically 10 to 15 percent more expensive than proprietary systems. But are interoperable systems always more expensive to install? It depends on the particulars of the application.
For example, in existing buildings, the interoperable system is usually able to use existing cabling infrastructure. In new construction, new cabling infrastructure is part of the construction project. The interoperable system in almost all cases can be piggy-backed onto this cabling infrastructure. This capability eliminates the need to install dedicated cabling, a frequent requirement of proprietary systems. Even when the systems are being installed in existing buildings, chances are that there is an existing communications backbone that can be used by the system.
The use of a common user interface in interoperable systems also saves on first costs. Less central equipment is needed to support the operation of the system. Less space is required to house the central equipment.
Proprietary systems may not be able to piggy-back on an existing communications backbone. If not, the cost of installing a dedicated cabling system may actually make the proprietary system more expensive than the interoperable one.
One of the most critical and yet most frequently overlooked steps in the system installation process is commissioning. Many facility executives think of commissioning as a means of ensuring that a newly installed HVAC system performs as originally envisioned. A thorough commissioning process can improve operating efficiency by 10 to 30 percent. Further, the more sophisticated the installed system, the greater the need for commissioning.
While commissioning is important in HVAC system installations, it is critical in the installation of an interoperable system. Interoperable systems are very complex. And with the sharing of data across functions, errors in system operation that might not be detected without commissioning can produce unreliable results that are then used by other functions in the system. Commissioning helps to ensure that the data being transmitted back and forth within the system is accurate.
The commissioning process starts in the project’s design phase. In this phase, project requirements are defined. Commissioning establishes what procedures must be completed to verify that design requirements have been met. For example, tracking and recording of utility use data and making that data available for billing operations is a common function of interoperable systems. The design of the interoperable system must include a procedure to verify that metered data are being collected and recorded accurately and are being accessed by the billing portion of the system’s software.
During installation, the commissioning process ensures that all components, devices and software meet the requirements of the design and specifications. This requires that the facility executive closely monitor the installation process and review all submittals from the system installer and the vendors. Waiting until the project has been completed is impractical because of the large number of items involved and the complexity of the operation of the system.
Once the system has been installed, point-to-point verification must be completed for each sensor, controller and communication signal in the system. All must be tested and verified to determine operation as required by the system design. The calibration of all sensors and control functions must be tested and verified. Depending on the size and complexity of the system, this step in the commissioning process can take weeks or months to complete. That is one reason why it is often overlooked. But failing to complete this labor- and time-intensive step may result in undetected operational errors that continue to occur throughout the life of the system.
A comprehensive and thorough commissioning process is the only way to ensure that the final product can perform as specified in the design documents. Time spent on commissioning is well spent.
The most widely held misconception about interoperable systems is that they are plug-and-play. While part of this belief may be the result of oversimplified explanations by system vendors, much of it is a direct result of the evolution that has taken place in the personal computer field.
When personal computers were introduced, it was not always easy to upgrade system hardware or software. Hardware conflicts often arose, causing some applications to quit functioning. Frequently, the entire system crashed. Eventually, the operating systems became more sophisticated and eliminated practically all hardware and software conflicts. New hardware and software could then be easily installed without fear of system crashes. Personal computers had become plug-and-play.
Unfortunately, some facility executives have assumed that plug-and-play is the state of the art in building automation and interoperability. It is not. Even with the development of standards, there remain too many differences between controllers, components and software from different vendors to be able to call the systems plug-and-play.
James Piper, PhD, PE, is a writer and consultant who has more than 25 years of experience in facilities management. He is a contributing editor to Building Operating Management.