There are various situations where integrating BAS products from multiple manufacturers can be useful. The issues involved with specifying BAS-to-BAS integration are somewhat similar to those for factory-mounted controls (as discussed last month) though with some added twists.

Why? The major circumstance for considering BAS-to-BAS integration is when adding on to an existing BAS. The simplest approach is to stick with the same manufacturer, though the client may prefer that the new work be bid out to multiple contractors/manufacturers.

What’s Involved?

As discussed last month, the designer needs to research various issues, such as the availability of a common protocol between the two BAS and the objects to be shared, in order to assure that the integration will work as specified.  For BAS-to-BAS integration these issues involve some additional challenges and there are  some additional issues to consider.

The number of objects (e.g., points, setpoints, alarms) available to an operator on a single-manufacturer BAS can be in the many thousands. This can often include a wide variety of arcane sequence parameters not normally viewed by or adjusted by an operator, such as PID loop gains, time delays, operating differentials, etc. When integrating an existing BAS to new controllers by another manufacturer, many of these parameters may not be readable by the BAS unless explicitly specified as such.

There are also objects that need to be shared between the new and existing BAS components so that they work together as a unified system (i.e., as if it were provided by a single manufacturer). This list of objects requires research into the proprietary operation of the BAS involved (even if a “standard” protocol is used). For example, there is nothing in the BACnet standard that prevents a low-level controller (e.g., a VAV box controller) from having its own scheduling objects, which, along with a time clock, allows the controller to execute its own operating schedule. The other approach is to have the day/night mode (an object) toggled by the BAS. This choice must be properly specified or the new VAV boxes may remain in one of the operating modes at all times. Other similar examples include how trending and alarming is performed within the “system.”

Then there’s the issue of what BACnet communications services should be used for sharing the objects. For example, new VAV box controllers may not be capable of executing alarm logic. Instead they may have been designed to work with a BAS that will regularly read the objects to be alarmed (via the “ReadProperty” service) and execute the alarm logic at a higher level. However, the existing BAS may be expecting each VAV box to execute its own alarm logic and issue alarm messages to the BAS (via “Alarm and Event Services”). This choice must be properly specified or the alarming of the VAV boxes will not work. A similar example involves the use of the service called “COV Reporting.”

Why the Challenge?

For the addition to work with the existing BAS as a “system,” all of the above issues need to be researched and specified for both the existing and new BAS components. This research is probably not excessive for an existing BAS. However, it’s probably unreasonable to research this for all of the possible new manufacturers. Instead, can you specify a “basis of design” for the new controller and expect the contractor to “make it work” if another manufacturer is selected? The answer to this is probably no, given that there are two BAS contractors involved (i.e., the existing BAS and the new controllers). For example, the existing BASs contractor cannot possibly provide a fixed price for their efforts without knowing which brand of new controller will be used.

Then there’s the issue of how the specified BACnet services will be set up by the contractors. For most BAS installations (e.g., using a single manufacturer’s system) this issue is transparent to the installer since the system was designed to “just work” (i.e., the set of BACnet and/or proprietary services are chosen by the manufacturer). So the installer may have no experience with accessing the system’s tools used for manipulating the BACnet services (or, worse still, the manufacturer may not even provide these tools for an installer’s use).

What’s the Solution?

Unless you are willing to research and specify all of the issues, there are probably only two good approaches to the expansion of an existing BAS. First, only use the same manufacturer. Otherwise, be accommodating concerning the existing BAS contractor’s integration costs (i.e., don’t expect a fixed price on bid day)!