Babel Buster Network Gateways: Big Features. Small Price.
Additions to Existing BASs
There’s more to it than you might think!
Ira Goldschmidt, P.E., LEEDŽAP
May Issue - BAS Column
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
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)!
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]