Use of open protocols to connect BAS’s to mechanical equipment, VFD’s, fire alarm systems, lighting controls, etc. has become fairly commonplace.   We have even started to see designs that seem to be requiring all systems/equipment be integrated and with all data being shared.  Putting aside the dangerous legal ramifications of the word “all”, the question is is this a good idea?  We view the answer to this much like the use of motor oil – too much can be almost as bad as too little, and you need to use the correct oil.  Similarly, the equipment or systems integrated to a BAS and how they are integrated is a project-by-project decision based on the needs of the client and the design.

[an error occurred while processing this directive]

[an error occurred while processing this directive]

The first step in making these decisions is to learn about each integrated equipment/system’s specific interface, including:

• Is the interface integral to the equipment or is an outboard gateway required?  The former is implementation is sometimes referred to as “native”; while the latter is often more expensive, less reliable and less capable.

• Is the interface BACnet, LonTalk or Modbus.  If BACnet, is it BTL listed, and/or does it support the ability to automatically generate alarm/status messages (called “Alarm and Event Services”)?

• Is the communications via IP or some slower method (i.e., BACnet’s MS/TP, LonTalk’s FTT-10, etc.)?

• What equipment/system data is available for viewing from the BAS and, in some cases even more important, modification by the BAS?

Note that many of the above answers may vary between manufacturers of the same product type (i.e., some chillers may communicate via IP while others only MS/TP), so a decision about the basis of design then has to be made.

So what does one then do with the above information to make an integration approach decision?  Here are some examples that provide insight into this question:

FIRE ALARM SYSTEMS – This system’s integration choices and details are usually fairly straightforward .  Most systems offer BACnet/IP communications via a single gateway that isn’t BTL-listed, essentially all system data is available, and communications can only involve viewing the data (you can’t change the operation of a fire alarm system via a BAS gateway).  Since the entire system’s data is available via a single gateway the cost is fairly low, and, since it uses IP communications, viewing a lot of data probably won’t hog the communications bandwidth if applied properly.  However, these gateways generally don’t support automatic generation of alarm or change of status messages so if the BAS is set up to read this data too often (i.e., every second) it could bog down the communications.  Finally, unless BAS operators need to view fire alarm system data then it isn’t worth it at any cost.  Note that the above does not apply to the integration involved in fire alarm shutdown of HVAC equipment or smoke control operation – these applications are usually best handled by direct hard-wired interlocks.

[an error occurred while processing this directive] CHILLERS – Integration to a chiller via digital communications has pretty much become a given.  There’s a lot of useful data available for little extra cost even though the interfaces generally do not use IP communications or are, if BACnet, BTL-listed.  The real issues with designing the chiller interface concerns:

• Is all data needed is available?  For example, does the chiller provide accurate load (tonnage) calculations or is an outboard BTU meter needed? 

• In a critical facility starting and stopping the chiller via a digital link alone may be risky, so consider adding a directly wired start/stop point.

VARIABLE FREQUENCY DRIVES – If all that is needed is start/stop and speed control, along with operating status information then is the extra cost of the interface (vs. hard-wired points) worth it?  Possibly not, though this depends on the implementation (which varies greatly between manufacturers).  If the operator wants to see “all” data from the VFD then maybe cost is not a concern.  Either way, also consider how reliable the VFD’s status reporting capability is vs. that from an outboard current switch or sensor.

Using the above background information and examples should help you to see that fully integrating all equipment/systems to the BAS via the exclusive use of digital communications is not an engineered approach.

About the Authors

Paul and Ira first worked together on a series of ASHRAE projects including the BACnet committee and Guideline 13 – Specifying DDC Controls. The formation of Building Intelligence Group provided them the ability to work together professionally providing assistance to owners with the planning, design and development of Intelligent Building Systems. Building Intelligence Group provides services for clients worldwide including leading Universities, Corporations, and Developers. More information can be found at www.buildingintelligencegroup.com  We also invite you to contact us directly at Paul@buildingintelligencegroup.com or ira@buildingintelligencegroup.com

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

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