Tweet

April 2017
Column
AutomatedBuildings.com

True Analytics™ - Energy Savings, Comfort, and Operational Efficiency
Ecorithm - Cloud-Based Analytics Software

(Click Message to Learn More)



BAS Integration For Factory Mounted Controls

It’s time to revisit the design challenges that continue to plague a successful controls merger.

Ira Goldschmidt

Ira Goldschmidt, P.E., LEEDŽAP
Engineering Consultant,
Goldschmidt Engineering Solutions
ira.goldschmidt@comcast.net

Contributing Editor

As published
Engineered Systems 
April Issue - BAS Column

Articles
Interviews
Releases
New Products
Reviews
Cube
Editorial
Events
Sponsors
Site Search
Newsletters
IBCon2017
Archives
Past Issues
Home
Editors
eDucation
Belimo
Training
Links
Software
Subscribe
KMC Controls

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.

Optergy 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!
footer


Activelogix - Periscope
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources