Column - Additions to Existing BASs – There’s more to it than you might think!

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 reason for considering BAS-to-BAS integration is when adding on to an existing BAS (e.g., for tenant finish purposes or building additions). The simplest approach is to use the same manufacturer, though the client may prefer that the new work is 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 BASs and the objects to be shared--to assure that the integration will works as specified. For BAS-to-BAS integration, these issues involve some additional challenges and there’s also some additional issues to consider.

The number of objects (e.g., points, setpoints, alarms, etc.) 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 BASs 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 that for 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.”

[an error occurred while processing this directive]Why is this a 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 to-be-installed BAS components. This research is probably not excessive for an existing BAS. However, it’s probably unreasonable to expect a designer to research this for all possible new controller choices if they are to be bid out to multiple 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., that for the existing BAS and that for 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 (i.e., 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(s)? Unless you are willing to research and specify all of the above issues, there’s probably only two good approaches to the expansion of an existing BAS. First, only use DDC controllers made by the same manufacturer as that for the original BAS. Otherwise, be accommodating concerning the existing BAS contractor’s integration costs (i.e., don’t expect a fixed price on bid day)!

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources