Turning back the calendar to the 1980s, our industry was struggling with the need for one or more open standard protocols to support cost-effective building integration needs. Many control companies and device manufacturers, of all sizes and motivations, were struggling to agree on the details of a network communication protocol(s) - and, how to provide component interoperability. Today, open standard protocols are widely used and third party testing bodies such as LonMark® International and BACnet® Testing Laboratories help to facilitate successful communications between certified system components.

Problem solved, right? We can see that today we're reaping the full benefits of open standard protocols... well, not necessarily. This article will review the reasons open standard protocols were, and still are, desirable, as well as the benefits we had hoped to realize from their successful application. Most importantly this article will describe how you can assist the building owner in attaining many of the expected benefits from an open standard protocol and how to help the owner maximize those benefits for the expected life cycle of the integrated building components.

Twenty years ago, open standard protocols were widely regarded as the solution to the expensive, frustrating problem of being locked into a long-term relationship with one, and only one, building automation system (BAS) supplier who used a proprietary protocol. Have open standard protocols delivered that solution? The answer is yes and maybe. The good news is that you can move your system from the maybe column into the yes column by properly specifying and qualifying the system.

Although open standard communication protocols are widely available today, you may or may not be getting an open communication network just because your system is using an open standard protocol. Can that happen? Yes it can, and it does happen because most open standard protocols including BACnet and LonTalk® can transmit data using proprietary objects or variables. Examples of objects or variables include supply temperatures or operating modes.

If your LonTalk or BACnet network is passing proprietary objects that are not documented, your system is not open; rather it is proprietary. If the proprietary information is documented, your system is more open but may be cumbersome and costly for another BAS supplier to support. In short, you may be locked into your original system integrator for any changes or maintenance you desire. You're back to the same problem you had before open standard protocols.

Why does this happen? When using a proprietary object or network variable, only the necessary attributes are bundled in a single proprietary object for data transmission. Therefore, more data can be passed using a single proprietary object, whereas multiple standard objects would be required for open standard communications. So does this happen? Yes. This practice happens because the overhead cost of transmitting fewer objects can reduce the first cost of the system. But what you may gain in first cost savings can increase your long-term cost of integration because allowing proprietary objects to be used can create the proprietary implementation you were trying to avoid in the first place.

An Open Standard Network Can Be Used as a Proprietary Network


If an open standard communications network passes data using proprietary objects, then it becomes a proprietary system. This can happen when the data is passed using proprietary objects (an encrypted format) instead of using standard objects.

As shown in the illustration at right, using standard objects is easily understandable. Using proprietary/encrypted objects saves on first cost but becomes difficult for other BAS suppliers to support.

Example: How Using Proprietary Objects Cuts Corners
and Turns Your Open Network Into a Proprietary Network
For any standard object (or network variable), the standardized protocol defines all of the properties of the standard object being passed inclusive of the range of data and its accuracy or resolution. The following is a simplified example of how using a proprietary object can reduce processing overhead.

Data takes up space. For communications to occur efficiently, properties of objects define what to expect from each type of object (data carrier). This practice requires that space be reserved for the expected data.

Creating standard objects facilitates communications between devices from different vendors by defining what to expect from each different standard object (or variable) type. In order for the various types of standard objects to be a manageable number, the properties or characteristics of each type of standard object are set up in order to cover most objects of that type. For example, an analog input standard object for a temperature sensor would be set up to cover the accuracy and temperature range for most sensors used in the industry.

If a standard temperature object is expected to be from –100°F to 200°F and its resolution is to be 0.1°F, then space for 3,000 values must be reserved. If on the other hand, a proprietary temperature is limited to be between 25°F and 100°F and its resolution is to be 0.1°F, then it reserves 700 values of space. Thus the proprietary temperature sensor uses 75 percent less space for the temperature being passed.

WHAT DOES THE BUILDING OWNER WANT?

The key question is - what does the building owner want: the least expensive, first cost integrated system; one that only one supplier understands? Or does your owner want a truly open integrated system, one that allows many suppliers to be able to support the building's integration needs as the building changes and requires maintenance and system updates?

To help answer those questions, let's first review the original benefits we wanted from an open standard communication network.

  • Choices for support of your BAS system.

  • Choices for BAS system adds and modifications.

  • Choices for equipment and system service support.

  • Ability to add or replace and integrate equipment cost effectively.

  • Minimization or elimination of proprietary gateways and the costs to maintain them.

    These benefits are as valid today as they were 20 years ago. In fact, it may be even more important today for you to help the owner obtain an open standard communication network. And that as much as possible the integration is implemented in an open standard method. That said, how do you help owners select and obtain a building automation system that facilitates effective integrated control as their facility needs change? A good place to start is a clear understanding of the full scope of what might be integrated in the building. Where does the building automation system begin and where does it end?

    BUILDING AUTOMATION SYSTEM COMPONENTS

    The components of an integrated building automation system today are not all supplied by the building automation system provider. Anything that communicates on the building automation system network should be considered part of the integrated system. These connected components typically include:

  • Mechanical equipment with integral unit controllers: As large energy users such as HVAC equipment become more sophisticated, many units come standard with their own microprocessor-based controllers.

  • Lighting system: Lighting control is often handled by a dedicated lighting control panel.

  • Security system: Building security is a unique expertise and may be handled by a separate panel.

  • Fire, smoke evacuation system: Fire and smoke control panels follow specific fire code requirements, have unique agency listings, and are often separate control panels.

  • People: On a basic level the BAS is simply a tool for the facility staff who use the system to automate their control, monitoring, and troubleshooting tasks. Therefore ease of use, documentation, and training all impact the ability of the operator to maximize integrated system benefits.

    The integral equipment controllers and applications specific panels listed above should be required to communicate using an open standard protocol. This is particularly important because some of these integrated components may outlive your BAS.

    An open standard communication network helps ensure interoperability and supplier independence for changes, maintenance, and additions to integrated equipment and sub-systems.

    BENEFITS OF AN EFFECTIVE BAS

    Now that we have a picture of the scope of the system, what benefits can the owner expect from his/her BAS investment?

  • Improved energy efficiency from automated, coordinated equipment operation.

  • Integration of various building systems such as occupancy, lighting, security, and fire to minimize system redundancy.

  • Ability to view and manage the building systems from a single screen, either on-site and/or from a remote location. This includes viewing equipment and system operation, automatic alarm notification, and trending of operating conditions.

  • Documentation of how the facility works or is designed to work.

  • Logging and trending of important maintenance information and comfort conditions which may include recording contaminant levels for documentation of your indoor air quality control.

  • Enhanced productivity of the building management staff because of automated monitoring, control, and troubleshooting functions.

    DO I STILL NEED AN OPEN STANDARD
    COMMUNICATIONS NETWORK?

    If a BAS network was like a home furnace, you wouldn't need an open standard communications protocol. But a BAS is not something you rarely need to change or almost never need to maintain. In fact, quite the opposite is true. As a building's needs change, the needs of its BAS change as well. In addition, the BAS touches many subordinate building systems and large, expensive pieces of equipment. Each of these systems or components has varying life cycles ranging from 5 to 50 years. The more expensive the equipment and the longer its useable life cycle, the more important it is to have these components communicate using open standard protocols. This difference in the expected life of the components that communicate in a BAS network is perhaps the most important reason to insist on open standard protocols for the communication network and all connected devices.

    SPECIFYING OPEN STANDARD COMMUNICATIONS

    As a specifier, you can start the process of achieving the owner's intent by specifying an open standard communications network. Specifying the building automation system for truly open standard communications will positively impact the cost of owning and operating the building for as long as the integrated components are required. Be sure to consider the following:

  • Include your specification requirements in the Facility Services Subgroup under multiple sections. For example, if the HVAC equipment comes with a factory-integrated unit controller, include the specifications for how it needs to communicate with the BAS in both the HVAC equipment unit controller section and the BAS in the Communications section.

  • Specify that the BAS supplier is responsible for all integration: addressing integrated components; mapping points for system sequences, graphics, and trend logs; and passing component alarms as described in the specification.

  • Specify that all devices communicating on the network must have a third party certification for interoperability such as LonMark certification or BTL (BACnet Testing Laboratory) Listing if available. (Many products are LonMark certified, but few are BTL listed at this time.)

  • Specify that any vendor-specific tools required to start up, commission, or integrate equipment be included as an option in the bid. This allows the owner the option of owning these tools, which can provide more vendor flexibility in the future.

  • For all LonTalk devices, require that the eXternal Interface File (XIF) be submitted along with the equipment or control panel unit submittals when the bids are submitted. For BACnet devices,

    require the BACnet Protocol Implementation Conformance Statement (PICS) be provided.

  • Include a points list. This list must cover all the data required for:

    – The BAS to integrate the control sequences you have specified for the building.

    – All desired graphical displays of how the equipment, system, and building are operating.

    – All monitoring, trending, and alarming data necessary for effective service, maintenance, air quality, etc.

  • For LonTalk devices, specify that all data must be transmitted as standard network variables per the applicable functional profile and cite the appropriate profile (chiller, space comfort controller, discharge air controller, etc.).

  • For BACnet devices, specify that all data must be transmitted using standard BACnet objects as listed in the points list.

    For reasons discussed earlier in this article, it's critical to specify standard rather than proprietary objects or variables to maintain open standard communications and avoid proprietary communications.

    SELECTING A SYSTEMS INTEGRATOR

    Perhaps the most important way to assist owners is by helping them select a systems integrator with a proven track record for sustained support of open standard protocol networks.

  • Help the owner select potential suppliers to interview.

    – How do they support open standard protocols? How do they maintain support?

    – Are vendor-specific software or hardware service tools required to add equipment, or can this be done using off-the-shelf service tools? Are these tools available for the owner to purchase?

    – Can another supplier access the BAS system should the original supplier go out of business, fall out of favor, or simply to allow a competitive bid for support, additions, or modifications?

    – How do they document the BAS operating sequences?

    – How do they minimize backward compatibility issues?

    – How long will parts, including controllers, be available at an affordable price?

    – How do they maintain the ability to add open standard devices to the network? Are upgrades required? How frequently and how much do they cost?

  • The owner should visit facilities installed with the proposed type of building management system to observe its operation and to interview the building operator. Viewing a system similar to the one proposed for your building may be the most important step of the evaluation. The topics listed above should be discussed with the building operator. Systems that have been installed for at least two years may be your best references.

  • Consider including system commissioning for the project. Include in the commissioning process a review of all the points in the point list. Ensure that all points are standard objects (or network variables). Require demonstration of the ability to add open standard protocol devices to the system using tools provided to the owner.

    MAINTAINING AN OPEN STANDARD
    COMMUNICATION NETWORK

    You can help the building owner minimize the cost of maintaining an open standard communication network by choosing a protocol that is being updated and maintained. Help owners recognize that a BAS is not static and that they should discuss keeping it up to date with the selected systems supplier.

    In addition, be sure to evaluate the open standard protocol you may specify for a history of being backward compatible with earlier versions of the same protocol. This means that if the owner needs to change parts of the BAS in the future, the interface to other existing integrated open standard devices should remain viable.

    CONCLUSION

    Open standard protocols deliver real, cost-effective solutions for your BAS, but it is important to avoid misapplying them as proprietary networks. Your ability to help the owner procure a sustainable, open standard building automation system will reduce their cost of integration and simplify system integration for years to come. This capability will increase the value of your firm to your current clients and to potential clients.

    Reprinted with permission from McQuay's "Engineering System Solutions" newsletter, No. 24. For more information, call 800-432-1342 or visit www.mcquay.com.

    Publication date: 08/07/2006