BACnet has been one of the best things to happen to the building industry and more importantly for building owners as a whole. BACnet has definitely helped to bring more choice in the building environment. Of course there is always the however. While features such as auto-discovery are a step above other options BACnet still has a ways to go.

Coming from a field standpoint we struggle with many items that make it more difficult than it should be to integrate “third party BACnet devices” With that in mind here is a list of items that we would like to share with equipment vendors that supply BACnet controllers

Software
Please make some sort of software (preferably free of charge or low cost) and a communication device available for control companies to be able to fully configure your product. In an ideal world the local equipment rep would send out a start-up person to configure everything. This usually doesn’t happen. The next best thing is to be able to do it ourselves with a little help from the factory.

RS-485 Voltage Reference
Mismatching RS-485 network voltage references are one of the biggest problems in putting two or more different vendor’s products on an MS/TP network. Please build into your product A- / B+ and the reference terminal so that all devices can have the same voltage reference. Ideally it would be great if it was possible to make the reference earth ground. That way all controllers would have the proper reference.

Termination Resistors
If your controller does not have built in termination resistors please tape one to your controller.

Network Speed
It’s 2012. Please have the ability to run up to 76.8 baud.

Addressing:
For the love of Pete (anyone know who Pete is by the way?) please allow full BACnet addressing capability. BACnet Device Instances can go from 0- 4,194,302. Let us have all those values. More than one equipment manufacturer limits the range of the address or how you set the address of their devices. When you have a larger campus and you have a sophisticated addressing scheme this lack of range kills any addressing scheme you may want to use. Allow the device to be configured as any address. Limiting its address range or tying its Instance to its mac address is frustrating at best.

Special Characters in Object Names
Stop using them. Many vendors do not support special characters and as such end up causing network communication errors. Trust me, you can figure out a way to get by without them.

Read Property Multiple
Please, please, please support this in your product. Single reads kill network speed. I know it is not a requirement but across the board this would help all vendors.

BACnet Engineering Units
Use them. Many times we run into devices where the BACnet Objects do not have units associated with them. If the engineering unit is available apply it. I have seen where chiller manufacturers use volts as the engineering units when the actual application is a temperature sensor. 

BACnet Object Names
First, please support 32 characters. Second, can you name them something we might understand? In lieu of that please provide a Table that explains what they are in plain English. See the example below.

OBJECT	NAME	DESCRIPTION
AV1	CHW_STPT	This variable sets the operating chilled water supply temperature. Valid ranges are from 38 – 65 degree F.
AV7	DMND_LMT	Based on the value in this variable, it will inhibit the chiller from exceeding a certain percentage of current. IE. If it is set for 70 the chiller will not be allowed to draw more than 70% of its configured design load amps.
BV6	UNIT_RUN	This point enables and disables operation of the chiller.

For us control guys a bonus would be a supplementary sheet or two that lays out the typical objects that we would be writing to and reading from such as the items above.

BACnet Trends
Memory is cheap these days. Please add some sort of trending ability to your product. Ideally it would be great to have the ability to create BACnet multiple trend logs for objects in that controller. Having to set up a trend on a different network controller chews up network bandwidth.

Product Design
[an error occurred while processing this directive] I have seen some interesting designs of control products over the  past 30 years. Just say no! No to bad design! It doesn’t matter where you are, find a couple of local controls contractors to come in and talk about your proposed design. Controls guys and gals are easy, bring in some good grub and feed them and they will spill their guts. The product should be easy to physical install (standard screws, DIN rail option), would preferably not require an additional enclosure (or provide a cheap enclosure option) and all terminals should be accessible using a voltmeter to allow for proper troubleshooting. Oh and yes we do love the idiot lights. If it can tell us it’s broken without having to find and open a manual this saves us a lot of time in the field. Silk screen the blinking codes on the product.  

Product Documentation
Most of us aren’t’ rocket surgeons. We have a hard enough time figuring out our own product idiosyncrasies let alone trying to figure out how to properly configure your product. I refer back to the item above where you grab a local controls guy or gal. Have them use your documentation and try and set up your product. Furthermore, creating a document that shows how to configure a typical example of what your product does. I.E. Set the baud rate, set the address, configure line termination, configure typical options, etc. would be very helpful.

Interoperability Testing
Find a few non-competing BACnet vendors to exchange your product with and see how they work together. Both companies will learn a lot about how to make a better product all around. Buy or trade with control vendors to get a copy of their software. In an ideal world you should be able to fully configure your product from any BACnet based front end software. If not, why not?

Special thanks to James Puritch of Reliable Controls Corporation and Brian Barnes of Siemens Building Technologies for their help in putting this together.

About the Author

Ken has a graduate degree from Colorado State University and an MBA from the University of Phoenix. He has worked in the HVAC Controls and Equipment industry for 27 years mostly specializing in controls. Before becoming a partner in his current firm he was the critical environment market vertical specialist at Siemens in Colorado. He has a lot of experience in data center, hospital and BSL lab solutions as well as general HVAC solutions. Currently he is running a small controls company as well as providing consulting services to clients. He is also hard at work developing a Building Automation Software Solution.

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

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