Wireless communications has been on the fringes of BAS for quite a while but over the last few years has gained significant popularity.  The emergence of ZigBee as recognized standard gave wireless communications a huge boost in our industry.  On a technical level it solved a number of wireless installation and operations problems.  On a marketing level it provided users with confidence that they were buying a solution with a future.  In fact, it was such a dramatic step forward that some over-eager marketing folks claimed the wireless future had finally arrived.  I, for one, was not among them. 

Standard VERSUS Interoperable

While many people proclaimed the virtues of wireless over the last few years and predicted its rapid adoption in building automation, I ruffled more than a few feathers by quietly suggesting that wireless wasn’t quite ready for prime time … not that it wasn’t coming, mind you – just that it wasn’t there yet.  On occasion, this position was puzzling to users who could see widespread use of wireless in homes and offices.  It was also a bit annoying to suppliers who were selling wireless components and systems.  But my reservations about wireless in building automation had nothing to do with wireless technology itself, but only with the lack of an interoperable, standards-based wireless solution that could deliver the value of open systems to users.

Nowadays most people understand and appreciate the value of interoperable networks.  However, far fewer people understand the concept of layered protocols and the need for standards at each layer in order to achieve interoperability.  So, when building automation users hear that a wireless system uses ZigBee they frequently think it’s “standard” and presume it’s interoperable with other (third-party) ZigBee devices.  Unfortunately, that’s not the case because ZigBee specifies unique profiles intended for different applications and are thus not interoperable.  Until now, manufacturers had to choose between using a profile designed for something other than BAS or creating their own. As a result, “ZigBee” BAS products were not generally interoperable.  In applications where wireless connectivity was essential or wiring was prohibitively expensive, they were still useful solutions.  But, they were merely a brief stop on the path to a bright wireless future for the BAS industry.  To complete the journey toward fully interoperable products we needed a set of layered protocols that standardize wireless data transfer as well as data representations and device interactions.

Standard AND Interoperable

Fortunately, the need for a layered set of protocols has been addressed by a joint technical effort of the ZigBee and BACnet communities.  They worked hard to align the two specifications so that compliant products can be designed that benefit from ZigBee’s low-power, mesh wireless networking technology as well as BACnet’s BAS data model and communications protocol. The result of the work is a ZigBee Commercial Building Automation application profile and Addendum Q for the BACnet specification.  The resulting BACnet ZigBee Wireless products provide (at last) a standard, interoperable wireless solution for building automation. 

In my opinion, interoperable BACnet-ZigBee devices will dramatically accelerate wireless adoption.  However, that does not mean that every application will suddenly move to wireless.  At Philips Teletrol we have been looking at wireless sensor and controller solutions for a long time.  We have been (and continue to be) engaged with suppliers of wireless components and devices and we have installed applications using a variety of wireless technologies.  Our experience with wireless leads me to believe there are a couple of areas beyond interoperability that will impact the pace of wireless adoption, including:

System Architecture 

System architecture can make wireless solutions more or less attractive.  Wireless is most attractive when all wiring to a device can be eliminated.  For example, a battery operated or energy scavenging wireless space sensor is great because it eliminates all need for wiring related to the sensor.  However, in the case where a space sensor with wireless communication requires external power the value of wireless is diminished (in that the sensor cannot be readily relocated and the task of wiring it is not fully eliminated).  In the same way, a wall-mounted RTU controller allows for lower system cost by eliminating the need for a factory-mounted proprietary controller in the RTU, but making the communications for it wireless does not eliminate all of the wiring effort since the controller still needs to be wired to the RTU.  (Of course, when RTUs have standard, built-in wireless things will get more interesting.) 

Batteries

Battery-operated wireless devices can create a new maintenance task which is objectionable to some users.  This issue will be minimized by the long battery life (up to 10 years) and automatic notification of low-battery status provided by most ZigBee devices.  Still, in some applications and for some users it will remain an issue.  And, even where it is not an issue, over the life of the system battery replacement costs may reduce the net savings gained through elimination of wiring. 

[an error occurred while processing this directive] Installation and Commissioning

As long as all of the wireless devices on the network are working correctly, installation and commissioning is pretty easy.  Mount them and flip the switch.  However, when it doesn’t “just work,” an electrician or HVAC technician cannot pull out their voltmeter or continuity checker to debug things.  There are wireless commissioning tools but not all of them are “field-ready” and most require knowledge and skill that many contractors today lack.  This challenge can be mitigated in the short term by over-designing the system (more mesh nodes than should be needed) and adopting a "replace parts until it works" strategy rather than a "debug" strategy.  But, these add cost and in the occasional situation where they don’t solve the problem, it may be expensive get someone to the site who can. 

Perceived Risk

There are some perceived risks involved in wireless systems that may or may not be warranted, but can still be obstacles to adoption.  In spite of encryption technology some users are concerned about unauthorized access by someone walking the building or sitting in the parking lot.  This is particularly true where the wireless network is in a retail store and inter-connected with the store's IT backbone network.  As some users have explained to me, the issue is not that security technology is inadequate, but more that human error (router mis-configuration, trivial passwords, etc) will compromise the security.  I have also heard concerns about whether a system that works today will still work when someone builds a cell tower (or WiMAX node) next door.

A Bright Future

Even with these all of these issues still on the table, users with urgent needs or adventurous spirits are already implementing wireless.  As the BACnet/ZigBee community turns from standards development to product development and they actively promote interoperable wireless for BAS, many more users will move forward with implementations.  The remaining issues will get addressed as people engineer system architectures to leverage wireless, further develop installation tools and the base experience grows.  These developments will reinforce each other so I expect to see more suppliers embedding BACnet Wireless capability in their equipment and even more users adopting BACnet Wireless solutions.  So many, in fact, that I think we can actually say we are headed back to the future with interoperable wireless … for real.

If you have wireless BAS implementation experience or ideas you would like to share or just have questions on BACnet Wireless solutions, please send me a note.

As always, the views expressed in this column are mine and do not necessarily reflect the position of BACnet International, Philips Teletrol, ASHRAE, or any other organization.  If you want to send comments to me directly, feel free to email me at andysview@arborcoast.com.

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

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