by Scott Ziegenfus, Hubbell Lighting, Inc.; Clay Nesler, Johnson Controls; and Wayne Stoppelmoor, Schneider Electric

Proper specification of a building management system (BMS) with other data-integrated building systems is important to ensure that the end user gets the building performance and user experience they expect. Specification errors happen far too often, causing added project costs, project delays, commissioning nightmares, and disappointed end users. Fortunately, by answering some key questions and following a few guiding principles, many of these integration issues can be avoided.

BMS Specification Using MasterFormat

MasterFormat is a common layout or index for design requirements or specifications of all aspects of building components to be used in the construction of a building. The common layout is composed of divisions. Each division has a set number system that is focused on a construction subgroup, such as the Facilities Services Subgroup, which includes the divisions shown in Table 1.

Table 1 Facility Services Subgroup
Fire Suppression (21) Plumbing (22) HVAC (23) Integrated Automation (25) Electrical (26) Communications (27) Electronic Safety and Security (28)

The American Institute of Architects (AIA) MasterFormat is basically the Dewey Decimal System for locating and indexing the design specification for buildings. However, a complete design specification for a large building can be thousands of pages and includes multiple subsystems whose specifications reside in different divisions. The specifier’s challenge is to make sure the information is clear, complete, and, most of all, easy to find so that it will meet the design team’s Basis

In 2004, there was a major expansion in divisions for the MasterFormat and HVAC was placed in its own Division 23; Division 25 was established specifically for building subsystem integration. It was expected that BMS specifications would migrate to that division but instead most BMS specifications are still listed in HVAC (23) along with HVAC specifications and requirements. Using Division 23 can provide challenges since building management, which includes lighting, elevators, access management, and life safety, is technically not HVAC and many contractors, installers, and manufacturers do not look in Division 23 if their scope is included in other divisions. It can also be difficult for contractors and installers to access Division 23 specifications if their scope of work is included within another division.

Specifying Integration in Divisions 25 and 27

Division 25 provides a specification framework for a BMS that integrates multiple systems from separate divisions:

• Section 25 30 01 covers the items to be monitored or the data to be exchanged from each subsystem
• Section 25 05 01 defines the control functionality of each system
• Section 25 90 01, one of the most important sections, provides for the sequence of operations between the systems and the BMS

Division 27 is where the details of the building’s communication infrastructure are listed. Division 27 equally applies to a common IT infrastructure that can be shared by building technology systems and information technology systems or a dedicated network for the BMS.

Using Division 23 can provide challenges since building management, which includes lighting, elevators, access management, and life safety, is technically not HVAC and many contractors, installers, and manufacturers do not look in Division 23 if their scope is included in other divisions.

Each building system is listed in its own division. For example, the specification for lighting system integration would normally fall under Lighting Controls sections within Electrical Division 26 09 23. If the system consists of a simple panel it would probably be listed under section 26 09 43 Network Lighting Controls or a subsection such as Digital-Network Lighting Controls.

Each division is where the installer will access the information for system requirements and where the requirements for integrating the systems with a BMS should be listed. Even if listed in earlier divisions, the integrated system functionality should also be listed in the traditional division of that system or it may never be known by the system installer.

Specifying Integrated System Functionality

Data flow between systems is a basic function of an integrated BMS. Many parameters need to be specified, including the mechanics of the data flow, what data is stored and/or displayed, what data can be sent, and what data can be received; the format of the data; and who is responsible for configuring and managing the data flow.

One of the most important items in a specification for system integration is the sequence of operations. The sequence of operations is important for a stand-alone system but even more important for data-integrated systems from different manufacturers. The sequence of operations is where the specifier defines “what” each system should do. This part of the specification is often documented as a narrative, flowchart, table, use case, or similar format. The system installers are often unfamiliar with the capabilities and characteristics of the other systems, so both the details of the overall system operation and system implementation need  to be clearly specified. Additionally, listed in both Division 25 and within its own division each system would list the sequence of operations or interaction between the system and the BMS such as detailing each system’s responsibility in implementing command or monitoring actions.

Data exchange is core to systems integration, and its specification answers such questions as:

• Do the systems need to pull the data or will each system push the data?
• How fast does the data need to be transferred?
• What data needs to be transferred and where is it stored?
• Where is the data analyzed?
• What capability does each system have to control devices in other systems?
• Can schedules in multiple systems impact devices and parameters outside their system?
• Can schedules be modified from more than one system?
• What devices or functions can be controlled or overridden from which systems?
  

Specifying Communication Protocols

Each division including networked systems needs to clearly specify the communication protocol or protocols for integration. Many BMS and subsystems can accommodate multiple protocols. BMS protocols have two basic components:

• The message, such as what data needs to be transferred, how fast it needs to be transferred, and where it is analyzed
• The structure to transport the message, which dictates the wiring and physical connections used

Many of the most popular BMS protocols have multiple structures for message transport such as Modbus ASCII and Modbus TCP/IP or BACnet/MSTP vs. BACnet IP. Wired media like RS-232, RS-485, and Ethernet have different connectors, different communication speeds, and different wire types. Wireless media have different frequencies, speeds, and modulation types. Many BMS protocols offer a certification process for devices to ensure a base level of compliance. Some offer only third-party certification while others offer self-certification or both.

Media converters and protocol routers are used to change the transport structure while maintaining the same message. For instance, a BACnet IP to MSTP router communicates the same BACnet  command but changes the wrapper with source and destination information to work between an IP-based message and an RS-485-based message.

Gateways are a translator between protocols. The advantage is that a gateway allows a system that does not support a specific protocol to communicate with a system with another protocol. Because gateways support multiple protocols, both open and proprietary, they often have to be updated when either protocols change or the configuration of the connected systems changes. Some highly integrated BMS employ middleware software running on a separate server that can support multiple standard and proprietary system protocols and convert building system data to  a common format for data storage, analysis, reporting, and compatibility with third-party applications.

Specifying Responsible Parties

A common mistake in specifications of an integrated BMS is to not include who is responsible for making  the system ultimately work. The specific responsibilities of installers of the individual systems and the integrating BMS need to be specified. If there is an  issue and additional equipment is needed to address  the integration between systems, who is responsible for purchasing that equipment? Systems on the same project can individually be tested using third-party BMS testing software all showing that each work adequately but when connected they don’t work together. Each installer needs to stay on the project until the specified functionality is achieved. Sometimes a consultant or master system integrator is hired with the responsibility to sign off that each system has met the integration requirements and that the overall system works and meets user expectations. These responsible parties can also address aspects of network access, cybersecurity, operator training, and life-cycle management, which are critical with integrated systems.

In conclusion, experience has shown that specifiers do not have to be BMS protocol or systems integration experts to achieve project goals. Successful integration involves answering some key questions and following some guiding principles related to system functionality, technical implementation, and the location of integration information in specification documents. ei