Use of open protocols to connect BAS 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: not only can too much be as bad as too little, you still need to use the correct type of oil. Similarly, the equipment or systems integrated to a BAS and how they are integrated represent project-by-project decisions based on the needs of the client and the design.
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 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 (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?
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, 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.
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 neither use IP communications nor are (if BACnet) BTL-listed. The real issues with designing the chiller interface:- Is all data needed 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.
VFD's
If all that is needed is start/stop and speed controls, along with operating status information, then is the extra cost of the interface (vs. hard-wired points) worth it? Possibly not, although 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.ES
