Design approaches for integrated systems

Successful design and specification of integrated systems requires knowing the goals, selecting the correct approach, creating a defined design and specification, and working with experienced contractors who can implement the systems to achieve the desired result.

By Jeff Carpenter PE, RCDD, KJWW Engineering Consultants, Des Moines, Iowa December 12, 2011

The term “integrated systems” is commonplace in our industry. It seems easy to define; however, a deeper look at the concept leads to a realization that systems integration in a modern construction project is a complex topic. It is a topic that can have many different meanings depending on the audience. A project that does not tackle this reality will likely suffer from unintended consequences.

As is true in every aspect of engineering, a complete understanding of a concept is a prerequisite to developing its contract documents. The documents, however, are not enough. A successful project involving integrated systems requires the project team to deliberately determine the intended delivery method of the contract documents within the construction process. Variances in delivery methods can include design-bid-build, design-build, or various methods of collaborative team structures.

But even within a design-bid-build model, an understanding of the relationship of the contractors delivering the integrated systems to the construction manager, the general construction team, the MEP contractors, and other trades is very important and should be structured in an intentional way. Contract documents for something as complex as integrated systems cannot accommodate all of these construction methods at once. Doing so risks the documents being so generic as to be ineffective as a construction delivery tool.

What are integrated systems?

An accepted dictionary definition of integration is “to unite with something else.” While this definition is generic, it lacks the specificity to accurately reflect the myriad of technical possibilities a system integration project faces.

Uniting building systems can be approached in multiple ways:

  • Physical wiring of contact closures from one system to another
  • Low-level, direct communication between disparate systems using serial communication protocols
  • High-level, direct communication between disparate systems from multiple manufacturers, using purpose-built, proprietary drivers developed through a corporate partnership between manufacturers
  • High-level, direct communication between systems using industry accepted communication protocols
  • Direct communication between disparate systems from a single manufacturer, using proprietary protocols, delivered to the marketplace as a single solution
  • A unified system from a single manufacturer, designed as a single system to address multiple, disparate functions
  • A network of disparate systems, communicating using standard information technology (IT) protocols.

It should be evident that attempting to write generic contract documents that accommodate any and all of these possibilities is impossible and pointless. A successful system integration specification is one that is targeted to the specific needs of the project after competent consulting with the project stakeholders. As a starting place in this process, I suggest abolishing the term “system integration” from our industrial vocabulary. The phrase has become so generic as to be wholly ineffective.

Consider the following terms as replacements:

  • Point-level interconnection
  • Low-level protocol interconnection
  • Driver-based integration
  • Standards-based integration
  • Unified system
  • Converged system.

Each of the six terms requires a different approach to design, specification creation, and construction delivery in order to ensure a successful project.

Before looking at these six approaches in more detail, let’s look at some of the relevant codes, standards, and listing agency requirements (see Table 1). Each building system type has its own set of relevant requirements that must be considered. The act of integrating systems often presents challenges because it introduces technical capabilities that might be possible, but have come to market before the relevant codes have reacted to their capabilities. As an example, think back to the challenges that were presented when considering using a building’s voice-based fire alarm system for nonemergency overhead paging. Manufacturers were producing products that were Underwriters Laboratories-listed to perform an integrated paging function, but the local codes did not recognize the integration. Building owners were still forced to install two separate systems.

Point-level interconnection

This well-understood method of low-level, hardwired interconnections of discrete points from disparate systems has been dealt with in project specifications for decades. It involves defining the required hardware components for each system, the interconnection requirements between those components, and the responsibility for testing the completed connection.

Key specification requirements:

  • Hardware requirements of contact points
  • Interconnect wiring gauge and type
  • Control sequences to determine when a system activates a contact point and what the receiving system does upon receipt of the activation.

Things to consider:

  • Typically defined within the existing framework of CSI Division 11 and Division 21 – 28 specification sections.
  • Delivered during construction by Division 11 and  Division 21 – 28 contractors without the need for specialized contractors or knowledge
  • Code implications usually limited to distance requirements between a listed system and an external contact point originating outside the listed system
  • Permits best-of-breed solutions to be selected for disparate systems because the interconnection burden is low and nearly any manufacturer’s solution can provide it.

Low-level protocol interconnection

The low-level protocol interconnection solution is a low-level, hardwired interconnection of basic communication ports of disparate systems for the purpose of transferring specific and limited information from one system to another.

Key specification requirements:

  • Interconnect wiring gauge and type
  • Control sequences of the sending system to describe the circumstances by which the sending system should instigate a serial communication
  • Control sequences of the receiving system to describe the circumstances by which it should “listen” for serial communication from the sending system
  • Control sequences of the receiving system to describe what should be done upon receipt of the serial communication
  • Technical definitions of the requirements of the serial communication protocol if necessary.

Things to consider:

  • May require some specialized contractor knowledge when dealing with the programming of serial protocols
  • Permits best-of-breed solutions to be selected for disparate systems because although the interconnection burden is higher than a contact closure, most solutions can provide this functionality; therefore, the pool of available products is not unduly burdensome.

Driver-based integration

A driver-based integration is a high-level integration between disparate systems using proprietary, purpose-built drivers. Integrations of this type begin to increase the challenge of specifying, procurement, and implementing integrated systems on projects. Specifiers must understand and define the reasons for the integration, the data to be integrated, and the method by which that integration takes place. Contractors must have an increased level of technical knowledge in order to properly install and test the result.

Key specification requirements:

  • Specify specific details of the data to be provided through the integration, by the sending system
  • For the receiving system, specify the actions that must be taken upon receipt of that data (Often this is handled through a performance document or a written control sequence.)
  • Identify the physical locations where this intrasystem communication is going to occur and the communication methods required by the integration drivers available
  • Specify the cabling media required by the communication method
  • Determine a testing method to ensure successful implementation of the designed integration.

Things to consider:

  • An understanding of the availability of the integration drivers will lead the project team to a better understanding of how to structure the procurement and implementation.
  • Who provides the labor to implement the interconnection of the systems using the drivers? This requires an understanding of the expertise available in the local marketplace where the project is being built.
  • Specifiers are much more likely to experience code issues involving listed and nonlisted systems with this type of integration.
  • This approach still maintains the ability to select best-of-breed systems solutions but limits the pool of available products to those where corporate relationships have been forged and integration drivers exist. Competitive considerations between manufacturers may limit the specifier to using two favored products because of the lack of available integration drivers.

Standards-based integration

The standards-based integrated solution is a high-level integration between disparate systems using building industry-recognized standards-based communication protocols. This approach is very similar to the driver-based approach. The difference is the change from a proprietary driver to a standards-based driver as the communication method between disparate systems.

Key specification requirements:

  • Specify specific details of the data to be provided through the integration, by the sending system
  • For the receiving system, specify the actions that must be taken upon receipt of that data (Often this is handled through a performance document or a written control sequence.)
  • Identify the physical locations where this intrasystem communication is going to occur and the communication methods required by the standard protocol
  • Specify the cabling media required by the communication method
  • Determine a testing method to ensure successful implementation of the designed integration
  • Specify the specific standard communication protocol to be used.

Things to consider:

  • Standards-based integration is often where project holes can start to develop. Consider a specification that requires a BAS to have BACnet capability and to communicate to the fire alarm system using BACnet. Assume that the fire alarm specification also requires BACnet connectivity to the BAS. To the inexperienced specifier, this may appear to have effectively established an integration between the BAS and the fire alarm system. In reality, this creates a significant project hole.
    • These standards-based protocols established a communication highway between two systems. The specifier must still design the material the highway is made from; the shape and size of the highway; and the requirements for the cars, trucks, and vans that will drive on the highway.
      • If the systems being integrated have a graphical user interface (GUI), these standard protocols do not address how the GUI should deal with the information shared over the protocol interface.
      • The type and quantity of points to be shared for the particular project must be specified as well as the type of point (i.e., analog, digital, binary, etc.)
    • BACnet for example, can communicate over multiple network protocols. The specifier must determine the method and ensure consistency across systems.
  • The use of standard protocols does not alleviate the specifier from understanding the nuances of the interconnection of listed and non-listed systems.
  • Seasoned contractors can deliver this method of integration through a well-written specification and a deliberate and thorough scoping document developed by the prime contractor and its subcontractors. In some cases, a separate integration contractor may provide beneficial service to the project.
  • Best-of-breed systems selections can be made with this method of integration. The pool of available products is limited to those that support these industry standard protocols; however, most do.

Unified system

A unified system solution is a cross-functional system solution brought to market by a single manufacturer, purpose built to handle the needs of multiple building systems. This approach provides the end user with the potential for seamless operation of multiple systems, without the burden of working through the system integration process as part of the implementation process.

Key specification requirements:

  • Require specific language within each individual system specification to indicate that the individual system is part of a single integrated solution by a single manufacturer.
  • Specify the specific requirements for communication by the unified system to other, external systems, if any.
  • If any of the communication methods that occur internally within the unified system between system components is important for the specifier to dictate, indicate these specific requirements.
  • The specifier must precisely define what constitutes a unified system.
    • Often this can be done by specifying the specific requirements for the information that must be displayed on the GUI. For example, the specification can provide specific requirements for display of location, status, and settings/information for each component on the GUI, such as BAS points, fire alarm initiating and signaling devices, controlled doors, and closed-caption TV cameras.
  • Individual specification sections that describe the requirements for each system must be carefully coordinated so that common sections have the same requirements. For example, if each individual specification section (i.e., fire alarm, BAS, security, etc.) contains requirements for the user interface, it is imperative that the specification be refined to ensure that it is clear that what is required is a common interface. Further, it is important that each specification section contains the same requirement, rather than three different sections describing three different GUIs in three different ways.

Things to consider:

  • Careful consideration must be given to how a unified system will be delivered on the project during the construction phase.
    • It is not unusual for building automation to be bid by the mechanical contractor or a separate controls contractor, the fire alarm to be bid by an electrical contractor, and security to be bid by a security contractor that may be a second-tier subcontractor under the electrical contractor. This traditional method of delivery is not conducive to the successful unified system implementation.
    • Knowledge of the local market and the contractors in it is crucial. The project specification should be structured to take these local market conditions into account and design the responsibilities for implementation accordingly. If there is a construction manager involved in the project prior to bidding, often he or she can assist in developing project scoping documents for the trades that further define these responsibilities.
  • Best-of-breed solutions are typically not the key motivation if a unified systems approach is used. A streamlined implementation and single point of responsibility are often the driving factors for this type of system approach, and the client is willing to accept that not every system of the unified solution will be best of breed.

Converged system

A converged system solution opens up a whole set of options to clients and specifiers. Our industry is just beginning to see the potential of this approach. To understand converged system solutions, we need to look at the underlying reasons for desire to integrate systems. One reason is to share data between systems and act on that data to improve something in buildings. Systems are integrated in order to share this data. What if that data could be shared between multiple systems without the systems ever being integrated at all, in the traditional sense of the word? Converged systems look to the IT world and adopt IT principles to facilitate communications between systems. They leverage the investment in IT infrastructure in order to transcend IT, so that the infrastructure can be used by more than traditional IT.

An example of this convergence was the phenomenon of voice-over-Internet protocol (VOIP), when data and telephone became one system. This was a convergence of disparate systems, data and telephone, where the data infrastructure investment was leveraged to provide telephony functionality and permit voice and data systems to share information. It did not take formal integration cooperation between Cisco and Nortel to make that happen. Simply, they each prescribed to accepted IT standards, and that permitted the exchange of information between their products.

Today, we are seeing building systems that are based on total control protocol/Internet protocol (TCP/IP) technology, leveraging the investment in IT infrastructure. This convergence of the physical infrastructure enables the integration of disparate building systems without some of the common integration roadblocks that have presented themselves in the past. The next evolutionary step is the exchange of data between these systems. Again, the industry will look to IT principles to create data repositories, where system data will be stored for other systems to access and use it for the betterment of our buildings. Using standard IT data formats such as XML, data can be exchanged between systems without the disparate systems having to be “integrated” at all (see Figure 1).

Key specification requirements:

  • The specifier of a converged system solution must have a robust knowledge of the IT industry and the project’s IT infrastructure.
  • A specification must move beyond the hardware requirements and dive deep into the software functionality of the system.
  • The data available from and exchanged with each system must be carefully defined.

Things to consider:

  • Some traditional construction mentalities break down when dealing with converged system solutions. IT, in some projects, is often thought of as an owner-provided system and carried in the furniture, fixtures, and equipment budget. Worse, the scope of the construction project and budget is often limited to only conduit rough-in. Converged system solutions will be a challenge, often beyond successful completion, if a construction project is delivered using this outdated model.
  • In the case of converged system solutions, the IT system serves as the core of building systems that are recognized as being part of the construction process. It is a road to failure to decouple the IT infrastructure by moving it outside the construction process, while attempting to deliver the building systems as part of the project.
  • Only the most seasoned construction project managers will have the experience to manage the delivery of a converged system solution and to ensure that the scope of work between trades is well-defined and without holes.
  • Like any project with an IT infrastructure included, yet another contractor is part of the team—the telecommunications contractor. This further complicates the scoping of work and the implementation of these systems.
  • There is no cookie-cutter recipe for the successful specification and implementation of converged system solutions. Success starts with the competent design of the systems, by a professional who understands the converged system holistically, including the IT infrastructure. Success continues through the structure of the construction contracts to ensure a complete and competent delivery of the systems. Success ends with a client’s management structure where IT, facilities, and management work together in a coherent way to effectively use their converged systems for the benefit of their facility.

“Integrated systems” is a buzz phrase without a useful definition. Integrated systems come in many shapes and sizes of drastically varying complexity. Successful design and specification of integrated systems requires knowing what the goals are, selecting an approach that is best suited for those goals, creating a design and specification that clearly defines the requirements, and working with experienced tradespeople who can competently implement the systems to achieve the desired result.

Carpenter is associate principal/project executive for corporate technology at KJWW. He has 18 years of consulting experience, including 12 years as KJWW’s previous manager of the technology department.