It has been wonderful watching the progress of BACnet this past year. The open protocol for Building Automation and Control networking has really captured the attention of manufacturers and specification writers around the globe. The number of international BACnet vendor IDs is growing. China, Japan and Korea have demonstrated increased enthusiasm in the protocol. If all goes according to plan, BACnet will soon become a European and ISO standard. These milestones will greatly facilitate the protocol's use in Europe and ASIA. As these countries gear up their manufacturing and BACnet product offering the competition in the BAS market will go from simmer to boil - great news for building owners.

All this would not have been possible without the hard work of a relatively small number of dedicated volunteers at ASHRAE and the BMA. The BMA has really done a great job in promoting and supporting the protocol with intensive interoperability workshops, informative advertorials and entertaining live plug-fest demonstrations.

The BMA's upcoming acceptance of Advanced Application Controllers for BTL certification in early 2003 should further assist in building confidence in the protocol. This is good news because few consulting engineering firms have the luxury of time and resource to fully appreciate how BACnet works and how to properly specify its implementation. The growing number of BTL certified products will provide a firm foundation of products for specifying engineers to choose from.

The early adopters of the BACnet protocol prudently used the protocol as a marketing tool to distinguish their products from their competitors. As a result, the first generation of BACnet specifications was largely "product- based". These product-based BACnet specifications described the features of products in minute detail and spoke little toward the performance and interoperability of the system. The approach catered to the standard vertical marketing model; a system consisting of BACnet Vendor A's front-end software, their networking and server hardware, their building controllers and their field controllers. Nothing outside of the based-bid could be acceptable. The approach effectively limited competition and with it came all the negative attributes of limited competition. In short this approach was not substantially different than specifying a proprietary system under the veil of being an open system.

The proper approach to specifying BACnet should not be the product-based approached of the past, but rather it should be done using a "performance-based" approach. BACnet Interoperability Building Blocks (BIBBS) makes steps toward the performance-based specification but still leaves the door wide open for "product-based" thinking. True performance-based specifications will lead to a "horizontal" marketing model; a system consisting of any BACnet Vendors front-end, and any BACnet vendors networking and server hardware, and any BACnet vendors building controllers and field controllers, all performing as good or better than a sole-source system. The specification does not concern itself with how many bits the microprocessor or A/D converter uses or how many mega bytes the field controllers have. Instead it focuses on performance. The system shall execute all programs and calculations in no less than 1 second, the temperature measured at an input shall be resolved to 0.1 degree, the controller shall have adequate memory to store 200 samples of every modulating point connected to the controller etc. A classic example is microprocessor technology. Most people intuitively think more power, more performance. In many applications (BAS included) smaller microprocessors are actually better suited for the task. They perform faster, require less overhead, and cost less. But it is common to see product-based specifications prescribing how the controls products should be designed. If Vendor A's 16 bit microprocessor based controller performs the same task faster than Vendor B's 32 bit microprocessor based controller why should the specification disallow the 16 bit product? Performance-based specification writing minimizes such pitfalls.

In today's new-construction projects with BACnet we never see the specification allowing the front-end software and the building controller hardware being supplied from two separate BACnet vendors. Aside from the control language software itself - which is inherently proprietary, there is no technical reason why separate BACnet vendors could not satisfy the supply requirements. By not separating the software vendor and the hardware vendor, we may in fact be sustaining the vertical market approach by allowing proprietary links between the hardware and software, which remain at the discretion of the single-source vendor. In a horizontal market separate sources of supply on software and hardware would be commonplace - as it is in today's personal computer industry. And the benefit to the customer is obvious - more competition, innovation, improved product-to-market turnaround, lower pricing, better service and performance - future-proofing the controls investment with interoperability.

No one said it was going to be easy to change vertical, product-based thinking to horizontal, performance-based thinking. To underscore the degree of how ingrained our product-based specification has become and our unwillingness to make it performance-based, consider the chain of events in these two stories:

The specification was a product-based document written around Vendor-A's BACnet system. After the tender-closed, the low price was found to be Vendor-B's BACnet system (a performance-based approved alternative). Vendor-A, who had historically used BACnet to limit competition, was so taken by the lost bid that they convinced the owner and the engineer to accept Vendor-A's cheaper "proprietary protocol" system. Vendor-A was awarded the contract and the proprietary-based system was installed. BACnet did help the customer obtain a lower price, but the other benefits of the open protocol were thrown out the window.

The specification was a product-based document written around Vendor-A's BACnet system. The spec called for "top-to-bottom BACnet" from the same vendor. After the tender closed, the low price was found to be Vendor-B's BACnet system (a performance-based approved alternative which consisted of a front-end from Vendor-C and controllers from Vendor-B). Upon analysis, the low bid was thrown out because the specification clearly stated the same vendor must manufacture the front-end and the controllers. Too bad for the customer, Vendor C had the superior performing front-end. And Vendor-B had great hardware. So now the customer paid more for an inferior system.

We all know that good things take time. It will take time to change our "vertical, product-based" thinking to "horizontal, performance-based" thinking, just as it did in the personal computer industry years ago. During the transition we should expect to see the barriers-to-entry into the industry lower, and the likely appearance of some new manufacturers with innovative and competitively priced products. In perspective, BACnet has really made some fantastic strides. And the future adoption and integration of the protocol looks great!

The comments and opinions made in this article are entirely of the author and not of ASHRAE or of Reliable Controls Corporation.

[Click Banner To Learn More]

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