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 is supported by the FMC since Modbus is a more 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 of 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 is too late in the project to deal with the issue efficiently.

 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 “writeable” and if the FMC supports writing to these objects (e.g., if an FMC’s start/stop object is not writeable then the BAS can’t start/stop the equipment); does the FMC support BACnet alarm/event services (which allows changes of value/state to be communicated only 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 involve 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! ES