Integration Myths, Lies and Misconceptions More and more projects are involving the integration of more systems and/or equipment, many whose function is not for HVAC.

Paul Ehrlich, Ira Goldschmidt & Angela Lewis Building Intelligence Group As published   May Issue - Column

More and more projects are involving the integration of more systems and/or equipment, many whose function is not for HVAC.  This is a good trend, as long as there is value from the integration.  Of course with this trend comes the challenges of learning about new systems, but, more importantly, there is usually a need to educate the system/equipment representatives about the part they need to play in integration (you may even be helping them learn about the integration solution that they didn’t even know existed).  And then there are the many myths, lies and misconceptions that seem to sprout forth whenever the scope of our integration goals grows.

Some of these myths, lies and misconceptions may be seen by some as are debatable truths, some seem to be rooted in a lack of education, while others are driven by marketing hype.  So in no particular order:

• Always Use BACnet^tm – It almost never fails: the first sentence out of a system/equipment provider’s mouth when asked about their product’s integration capabilities is often “We support BACnet”.  Unfortunately, other than most BAS products and commercial HVAC equipment, BACnet is usually not the protocol of choice even if it is supposedly “supported”. Hopefully this will change, but for now most industrial-based products (i.e., electrical equipment, CRAC’s, boilers, anything with a PLC, etc.) generally support Modbus as the native protocol (and rarely BACnet or LonTalk).  When BACnet is offered up it is usually via a Modbus to BACnet gateway which is not a preferred approach (have the BAS perform the Modbus conversion rather than installing gateways scattered all around the facility).  Other systems (mostly at the enterprise level) will probably support Web Services, share information via a database server (i.e., SQL), or possibly some other semi-custom approach.
• Communicate All Data – Some systems/equipment have hundreds of data items available for communication.  Communicating all of this data not only leads to the question of how it can be presented to the user in a useful manner, but, more importantly, if the system architecture is not properly designed (i.e., with many BAS data routers), then communications in some or all of the BAS could grind to a halt.
• [an error occurred while processing this directive]The BAS Contractor Will Take Care of It – BAS integration with another system/equipment is a “client/server” relationship, so both parties must take part in providing “matching” interfaces and setting them up for the integration.  This means that the system/equipment spec must list only one protocol and transport technology (i.e., 485 vs. IP) – listing a choice does not permit the BAS Contractor to properly bid or design their side of the relationship.  Further, some system/equipment interfaces are mounted outboard and therefore the spec needs to clearly define who installs and powers the interface.
• We’ll Communicate Any Data You Want – Be careful if a system/equipment supplier says this.  What it really means is that the interface probably is “vaporware” or, as a minimum, that it may require extensive set up efforts in the field (which, as Murphy’s law dictates, may lead to problems). 
  
• Always Use a Digital Communications Interface – Let’s face it, not all systems/equipment have much of use to say (we’ve seen some equipment with data lists totaling four items).  If so why not just pick up the product’s alarm and/or run status via a contact and some other important analog parameter or two via sensors, both wired to BAS inputs?
• Only Use the Digital Communications Interface – Unfortunately, digital communications is not as reliable a form of integration as that via the old fashioned way – BAS points.  Therefore on major and/or critical equipment (i.e., chillers, VFD’s on critical motors, etc.) use of hard-wired points for start/stop and other important control items (i.e., a VFD’s speed signal) is probably a more failure-proof design.

Keep these in mind on your next ambitious integration project – we do (though the list seems to always grow, morph and/or recycle)!

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]