This planning is required to take advantage of the continuing standardization and acceptance of certain BAS “open protocols.” As these open protocols hold out the promise of simpler and more efficient BAS operation, they also require some decisions. Although it is too early to make all the decisions, it is not too early to form the basis for an enterprise migration to an open protocol BAS.
What is an Open Protocol?An open protocol is a publicly available plan of data communication labels and procedures that defines the way a data network transmits and processes information. The universal acceptance of an open protocol promises to greatly simplify the purchasing, installation, operation, and repair of modern digital BAS systems. Instead of different terms for the same item or action, there would be only one, simplifying training and operation. Different vendors could bid on components for a new project knowing that the components would work together. Likewise, repair parts could be purchased from a variety of competing manufacturers. Finally, any new system would communicate with existing systems like a new telephone plugs into an existing wall jack.
The advantages of an open protocol can be summarized in terms of interoperability, integration, and interchangeability.
Interoperability and integration are terms easily confused. The key to understanding these terms is in defining the performance associated with them. Regardless of other definitions, for our purposes interoperability refers to the ability of a BAS system to utilize components of different manufacture at the system level (as opposed to the component or unit controller level). Interoperability allows complete monitoring and control of a distributed, multivendor EMCS from a single workstation with uniform commands, monitoring, and graphics. This quality allows the O&M staff to use a consistent graphical user interface (GUI) without retraining for each new system installed. It also allows new BAS systems to communicate with existing systems.
Proprietary systems that would normally not be interoperable may become interoperable by using gateways to communicate with each other and the GUI. Gateways are digital information translators that change one communication protocol into another. In this way, dissimilar protocols can be combined into a common system communicating with a GUI.
Unfortunately, gateways are not a perfect solution because they nearly always lose some information in one or both directions through the device. This might result in inaccurate control or incomplete monitoring, or both. Gateways add cost and complexity to a system and are a possible maintenance problem. When possible, it’s better to use a BAS that has native interoperability and does not need gateways to communicate with the local area network and/or GUI.
Interchangeability refers to the ability of a BAS system to utilize components of different manufacture at the component level. It’s the ability to replace a BAS component with another from a different manufacturer and retain the comprehensive monitoring and control of that component. This quality allows the owner to purchase components in an open, competitive market and thereby reduce cost. It also reduces inventory by eliminating the duplication of devices for different control systems. Finally, interchangeability allows comprehensive monitoring and control without gateways.
Integration refers to the combining of several functional systems into one. An integrated system could combine security, metering, lighting, hvac, and fire alarm signals over the same digital network and control these systems from the same workstation with uniform commands and graphics. Integration reduces installed cost by eliminating duplication of network wiring, equipment, and programming. It also allows a reduction in components and improved effectiveness of operation by linking components from one system with equipment from another. For instance, a door keycard reader could be used to activate hvac and lighting systems when an employee enters during unoccupied hours.
Integration may be accomplished with gateways. If this is done, components may not be interchangeable. For example, an occupancy sensor used for a proprietary security system may not be interchangeable with an occupancy sensor from a different vendor’s lighting control system.
An hvac system may use different manufacturers’ interchangeable components while not being integrated with security, fire alarm, or other systems. An integrated system may provide seamless control of hvac, fire alarm, and security systems, but may communicate via a proprietary protocol and not allow the use of another manufacturer’s equipment or communicate with other building’s control systems.
An Easy Approach to InteroperabilityThe simplest and most reliable approach to interoperability is to use only one BAS supplier. This avoids the problem of communication protocol by making it the in-house problem of the manufacturer. Unfortunately, most facility owners have found that too much purchasing power is lost when control equipment is sole-sourced. Prices increase, and no variety of long-term contracts, service agreements, labor scales, unit prices, or other purchasing instruments seem to be able to take the place of competitive bidding. Laws may make single-source procurement difficult or impossible for public agencies (which own and operate most of the largest BAS systems).
And even single-source implementation does not protect against the weak spots of that particular vendor, which may include inherent system flaws, peripheral component compatibility, LAN/WAN compatibility, and Internet server support.
Thus, there is a push for a uniform “open protocol” system that allows competition and unites all companies in providing solutions to common EMCS problems.
The Two-Standard DilemmaAlthough many open protocols have been developed, most facilities managers see the struggle for the standard boiling down to two options: the LonWorks control network developed by the Echelon Corporation (Palo Alto, CA), and the BACnet/ANSI voluntary consensus standard. The former is, essentially, a self-proclaimed standard that is backed by a certification program. The standard is constantly reviewed by an association whose members produce LonWorks compatible components or otherwise have a stake in the standard. The latter is a publicly reviewed consensus standard; it requires voluntary certification by manufacturers, but it has no enforced certification program. The BACnet development process uses a standard ISO model and follows rigorous international review standards in its development and design.
Each standard is supported by a group of manufacturers whose products have satisfied the requirements of the standard. Unfortunately, a component’s conformance to the requirements of the standard does not mean that the component is interoperable, interchangeable, or able to be integrated with other components that also conform. As described above, gateways may provide interoperable systems of components that, by themselves, are not interchangeable.
More information is available on the LonMark system at their website, www.Lon Mark.org. Use the “Buildings” heading to get to commercial and institutional facility applications. The website contains a number of case histories of buildings using LonMark interoperable systems and lists dozens of manufacturers who offer LonMark interoperable products. But remember the key is not just interoperability, but interchangeability. In the final analysis, interchangeability must be specified and verified. Certification alone is not enough.
More information is available on BACnet at the ASHRAE website, www.ashrae.org. The best approach at the ASHRAE website is to take advantage of the “search the site” function. Typing the word “bacnet” into the space yields over 50 matches that include articles, vendor lists and training information on BACnet. The BACnet annotation is strong in the interoperability area, but there is even less evidence of actual component interchangeability than at the LonMark site. Further research is required if the enduser expects component interchangeability.
Either standard will eventually succeed or fail based on the number of control component manufacturers that sell components based on the standard. It is too early to tell what the outcome will be.
Which Way to Go?So, does this mean that facility operators should just throw up their hands, continue to install building controls by the low bidder and give up on master planning the BAS? Modern facility managers cannot afford that option. They need to begin to develop a BAS master plan that makes use of the information and capabilities available now and provides for increased benefits in the future as the controls industry works through the open protocol process.
The Master PlanGiven the desirability and developing nature of the open protocol, the BAS master plan should allow a systematic migration to an open protocol as one develops. Reviewing the above, the basis for the development of the plan is as follows:
The plan must work toward single-point monitoring and control for the building, campus, and national infrastructure. The GUI should be the first item selected for the new master plan and should be selected by the O&M staff based on its adherence to an open protocol, superior graphics, intuitive operation, and conformance to the requirements of the local area network (LAN). As new BAS systems are installed, they must communicate with, and be controlled by, the central GUI (see below). The GUI itself should be capable of distribution and replication on a national scale.
New systems must be interoperable and should provide for competitive procurement to the greatest extent possible at the time. As new BAS systems are installed, they are specified to be compatible with the chosen GUI. With luck, the GUI can be provided as part of the construction of a new, large BAS somewhere in the enterprise (for instance, a new building on a college campus). This streamlines financing and also ensures interoperability for this major first component of the overall system. Subsequent new systems are specified to be compatible with the chosen GUI, preferably without gateways (although allowing gateways may be necessary to preserve competitive bidding). If desired, existing systems may be migrated to the new GUI with gateways until they are replaced with new, interoperable systems.
Interchangeable components must be utilized wherever possible so as to continually improve competitive procurement. Eventually, replacement BAS components should be obtainable from several vendors on the basis of an accepted standard specification. The components should be easily installed and connected in place of a similar device of another manufacturer and should communicate the same information to the central control and monitoring work station. The owner needs to confirm that this requirement does pose an unacceptable threat to competition.
The plan must allow system integration to the greatest extent possible at this time. As new buildings are built and existing buildings renovated, new BAS systems (hvac, lighting, security, metering, etc.) should be integrated to minimize components and labor, improve the effectiveness of the workplace, and allow single-point monitoring and control. These integrated systems must be interoperable with the main GUI and employ interchangeable components.
A Pathway to MigrationFigures 1 through 5 show a possible migration to a completely interoperative, Internet-connected BAS monitoring and control plan, using interchangeable components, from an existing standalone building arrangement.
Figure 1 shows three buildings with standalone systems (bottom of diagram). Shown above them are symbolic representations of local area networks at a hypothetical campus/complex facilities office and a state/national/international headquarters office. At this stage, the buildings have three different proprietary protocols and are equipped with a variety of peripherals.
One of the systems (perhaps the largest) may be wired to the facilities office. But as a rule, access to each is available only at the building. These buildings may be on the same campus or complex. Maintenance and operations staff personnel need to visit each building in person to review the building operation via the BAS.
Figure 2 shows the three buildings at the first stage of remote monitoring and control using modems. Each building needs a modem at its main control panel and/or user interface computer. Each proprietary system will probably have different modem speeds, and other requirements and may also require proprietary communications software. Individual site licenses for this software may have to be purchased. At the campus/complex level (and higher levels), each building will have to be separately dialed and the host computer will have to have all required communication packages on its hard drive. Communication speeds will be slow over the modems compared to commercial Internet connections, but virtually all information on the system will be available over the modem.
Figure 3 shows the first stage of migration to an open protocol. In this example, open protocols “A” and “B” and proprietary protocol “C” are not compatible. Therefore, the owner is required to choose one or the other. As described above, the best approach is to start with the GUI. The O&M staff should choose the GUI that works best for them and combine it with a major new project if possible. For instance, if the new GUI employed open protocol A, then protocol A would also have been chosen for the major new project. The local campus/complex office and national office both have identical GUIs linked by modem. All systems not of protocol A need to be retrofitted with gateways to allow their communication over the LAN. If this is not practical, their modems can be retained and used to communicate with the GUI computer. Subsequent new systems must be of protocol A. Also, interchangeability of components of different manufacture is desirable for protocol A.
On complexes that had existing wiring networks for the BAS system, those networks can be removed. The connection of new buildings’ BAS systems to the LAN can be coincidental with the installation of the overall LAN infrastructure in the building.
Figure 4 shows the continuing migration to a completely open protocol arrangement. Gateways have been completely eliminated from the BAS architecture, as they are no longer required. All components of the three buildings are interoperable within protocol A and are interchangeable with each other in any building and any system. Finally, as new buildings have been brought on-line, their different subsystems have been integrated into one interoperable system.
Figure 5 shows the final conversion to complete Internet connection, eliminating the slower modems altogether. The elimination of modems in favor of the Internet eliminates multiple communications packages in favor of one fast and easy Internet address that is accessible using any web browser from any Internet connection worldwide. If desired, each individual building can be connected separately to the Internet.
In ConclusionAlthough this plan can be used to help pave the way for an open-protocol, Internet-connected system, the question still remains: Which protocol to use, and how to use it? As described above, BACnet and LonWorks are leading the way. The choice between these two should be based on the following factors: What is the best GUI for the facility? The facility needs to come to a consensus about the look and feel of the graphical user interface. Lists of possible candidates can be obtained through the BACnet and LonMark websites described above. These vendors should then be contacted for in-person demonstrations so that a thoroughly informed decision can be made. The local LAN network management group should also be involved in this decision since the GUI will eventually, if not immediately, be connected to the LAN.
Which protocol is most compatible with the existing LAN? All BAS systems will eventually be connected to the local area network. Vendors offering BACnet and Lonmark equipment will be connecting their equipment to the LAN. Get the vendors together with the in-house information technology group, and make sure that the IT group has complete confidence in the hardware and software proposed.
Is interchangeability required as well as interoperability? If the answer is yes, some hard questions need to be asked of component manufacturers. Demand samples, prototype demonstrations, mock-ups, or other tangible evidence that equipment of differing manufacturers can be interchanged in a building system. The open protocol offering the widest selection of quality interchangeable components, along with an acceptable GUI, is the best choice.
When is the best opportunity to jump in? Try to kick off the long-term integration with a big project that demonstrates interoperability, interchangeability, and integration with the new protocol. Work with consultants to include these considerations in the early phases of design. Fund the GUI as a part of the first project, and make the first project a model for the future. Evaluate the need to change over existing buildings to the open protocol, and take advantage of interoperability and interchangeability as time goes on (and thus, as the open protocol proves itself). If complete control changeouts are not feasible, consider gateways as interim solutions.
Even if the full migration takes many years to complete, the advantages of interoperability, interchangeability, and integration will accrue with every new system installed. ES