November 2009

[an error occurred while processing this directive]
(Click Message to Learn More)

Integrating BASís To Everything All The Time?

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.

Paul Ehrlich & Ira Goldschmidt
Building Intelligence Group

As published

November Issue - Column 

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.

New Products

[an error occurred while processing this directive]

Coming Events
Site Search
Past Issues

[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:

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 IraPaul 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  We also invite you to contact us directly at or



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

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


Want Ads

Our Sponsors