April 2017 |
[an error occurred while processing this directive] |
BAS Integration For Factory Mounted Controls It’s time to revisit the design challenges that continue to plague a successful controls merger. |
Ira Goldschmidt, P.E., LEEDŽAP April Issue -
BAS Column
|
Articles |
Interviews |
Releases |
New Products |
Reviews |
[an error occurred while processing this directive] |
Editorial |
Events |
Sponsors |
Site Search |
Newsletters |
[an error occurred while processing this directive] |
Archives |
Past Issues |
Home |
Editors |
eDucation |
[an error occurred while processing this directive] |
Training |
Links |
Software |
Subscribe |
[an error occurred while processing this directive] |
BAS
integration to other BASs or to controls provided with
mechanical/electrical equipment (“Factory Mounted Controls” or “FMCs”)
was a driving force behind the development of BACnet. Nevertheless,
with few exceptions, integration continues to be a challenge for both
designers and contractors. Paul Ehrlich’s column a year ago covered
this subject, but I think it’s worth revisiting with some other/further
insights into the issue. This month I will cover the issue of
integration to FMCs.
What’s Involved?
The designer needs to research various issues to assure that the integration will work as specified.
First, is the
protocol support. The FMC needs to communicate using a protocol
supported by BAS. BACnet has increasingly become a given though Modbus
is more typical for electrical equipment. It is important to specify
which of these are to be used and it is best to use BACnet if it
supported by the FMC since Modbus is a costly integration solution.
Also, the protocol’s technology used to transport its messages needs to
be specified. The choices are essentially limited to IP vs. EIA-485,
with the latter referred to as “MS/TP” for BACnet and “RTU” for Modbus.
Next, the objects
(i.e., data, points…) to be integrated from the FMC need to be
selected. This usually involves a review of and selection from the
FMC’s listing of the available objects. Lastly, how the sequence of
operation is divided between the BAS and FMC needs to be determined.
This is not very challenging for equipment that is mostly meant to
operate on its own, such as VFDs and chillers. However, other
equipment, such as RTUs, may need the BAS to perform sequences such as
optimum start, day/night operation, duct/space pressure control, etc.
Why the Challenge?
All the above choices have to be made based on the actual capabilities
of the FMCs available for a given equipment type. The designer can base
these choices on their selected “basis of design,” but there is no
guarantee that the basis will be installed. So what happens if the
installed FMC cannot meet the specified integration requirements? In my
experience, this problem is not determined until the contractor
attempts to implement the integration which too late in the project to
deal with the issue efficiently.
[an error occurred while processing this directive]There
are other design challenges to deal with. First, the FMC’s object list
is often hundreds of items long and is generally not very clearly
documented. This often leads to specifying that “all data be
integrated” which seems like a simple solution but can easily result in
overloaded communications bandwidth. Further, the FMC’s sequence of
operation is not usually described in a clear, narrative fashion if it
is documented at all. Clearly, this makes it difficult to write a BAS
sequence that properly supports the FMC.
And then there are
several other seemingly minor issues like determining which objects
need to be “writable” and if the FMC supports writing to these objects
(e.g., if an FMC’s start/stop object is not writable then the BAS can’t
start/stop the equipment), does the FMC support BACnet Alarm/Event
services (which only allows changes of value/state to be communicated
when they occur so that communications bandwidth won’t be eaten up by
reading the data on a regular basis), and unfortunately others.
What’s the Solution?
The approach I’ve
been using and advocating works well but still involves a lot of work.
As hinted above the equipment’s integration capabilities should be
based on that equipment’s basis of design. This, of course, does not
free the designer from having to research and specify all of the above
issues for that equipment (though you would expect that the equipment’s
rep would help with this effort). More importantly, additional language
should be added to the spec to address an alternate equipment selection
that does not meet the “integration” requirements (e.g., the contractor
must, at their cost, modify the BAS design to make up for these
shortcomings which might include a protocol gateway, additional
programming efforts, etc.). Finally, the designer needs to review the
equipment submittal for compliance with the integration requirements
and enforce them in the same manner as the mechanical requirements!
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]