When the Building Automation Control Network (BACnet) committee was formed in 1987, its members had a vision of integrating all elements of building automation with a single protocol. It has been a slow and difficult process, but considerable progress has been made, as evidenced by several proposed extensions to the BACnet standard that strive to integrate more areas of building automation.
The manufacturers represented on the committee that developed BACnet were predominantly HVAC-controls manufacturers. When BACnet was approved in ANSI/ASHRAE/IESNA Standard 135, BACnet — A Data Communication Protocol for Building Automation and Control Networks, it largely met their needs. Soon after, fire/life-safety-system manufacturers became involved, and extensions to meet their requirements were added to the standard in 2001.
At about that time, working groups formed to integrate energy utilities, lighting-control systems, physical-access control, and an updated means of securing BACnet communications. A couple of these groups have produced extensions that have been approved as addenda to the standard. Several others appear to be close to accomplishing their mission.
In 2006, the BACnet Life-Safety and Security Working Group (LSS-WG) released the first of its physical-access-control extensions, the Access Door object, to represent the characteristics of an access-controlled door in BACnet. The Access Door object was approved as Addendum f to Standard 135, but represents just the tip of the iceberg of the group's work.
In March 2007, seven more proposals from the LSS-WG were published for public review and comment by the public, part of the rigorous process new proposals must undergo before approval. These proposals — to add the Access Point, Access Zone, Access User, Access Credential, Access Rights, and Authentication Input objects and the Access Event algorithm — complete the set of extensions needed to fully support physical-access-control systems in BACnet. The proposals were developed jointly by representatives from the building-controls and physical-access-control industries — the latter ensuring that its industry's state-of-the-art practices were incorporated.
By building a physical-access-control application on the BACnet platform, the LSS-WG was able to leverage work already done by the BACnet committee, as well as ongoing complementary work by other BACnet working groups. This allowed the LSS-WG to focus specifically on the physical-access-control elements and, thus, complete its work sooner than would have been possible if the entire networking structure and system had to be defined.
The LSS-WG anticipates another advantage to having physical-access control on the BACnet platform: When these systems are developed and deployed, they can be integrated directly into the many existing BACnet installations worldwide.
One of the complementary extensions necessary for physical-access control is being developed by the Network Security Working Group (NS-WG). The NS-WG is developing a replacement for the mechanisms in Standard 135 for encrypting and authenticating network communications. In March 2007, it published its proposed BACnet Network Security for public review and comment.
BACnet's mechanisms were secure when originally developed using the old Data Encryption Standard (DES), but advances in computer technology have rendered them considerably less secure. The NS-WG has developed replacement mechanisms using the newer Advanced Encryption Standard (AES) adopted by the U.S. government.
AES has the advantage of being fast in hardware and software. It is implemented readily on even relatively small BACnet controllers, which was not the case with DES. Using AES permits secured BACnet communications all the way down to an inexpensive BACnet master-slave/token-passing (MS/TP) RS485 local-area network (LAN).
Work on BACnet Network Security actually began prior to the start of the work on the physical-access-control extensions. Its internal complexity may be inferred from the fact that the method of securing and authenticating BACnet messages requires more than 50 pages to describe (compared with 64 pages for all seven access-controls extensions).
The Utility Integration Working Group (UI-WG) has been working on extensions to connect and integrate buildings and energy utilities.
In 2006, the UI-WG released the first of its extensions to BACnet, the Load Control object, which was approved as Addendum e to Standard 135. Some manufacturers have developed proprietary means of providing control over the load requirements of a building, but the Load Control object provides a standard interoperable means of achieving this control.
The UI-WG continues to work out the details of communicating load-shedding requests and responses and real-time energy pricing between the energy utilities and buildings. This long has been a goal of energy utilities, which, in fact, requested that the UI-WG be formed.
Some interesting interactions between the UI-WG and other BACnet working groups show the value of working to integrate an entire building on a single platform. One proposal submitted to the UI-WG uses BACnet Web Services (published last year by the XML Working Group) and BACnet Network Security for building-utility communications. The response to a request for a particular capability from the utilities industry, published last year as the Structured View object, is helping the Applications Profile Working Group develop standardized BACnet profiles for building elements, such as variable-frequency drives and variable-air-volume controllers.
The Lighting Applications Work Group (LA-WG) has been working toward closer integration between lighting-control systems and other systems integrated into BACnet. In March 2007, it published the first elements of its work for public review.
This work provides direct support for lighting controllers ranging from the simplest on/off controllers — including the ability for BACnet objects representing a control to indicate a tripped circuit breaker and even issue an alarm — to considerably more complex controls with continuous analog-lighting level control, ramping at fixed rates of change, fading over a fixed period of time, incrementally stepping values up and down, and so on.
In the work presented for public review, the LA-WG submitted a generic lighting-output object that meets direct architectural switching and dimming needs. The group crafted the object so it could be mapped through gateways to other lighting networks, such as Digital Addressable Lighting Interface-based systems.
Other proposals from the LA-WG are being prepared for public review and publication. These include extending standard BACnet scheduling to support computed times — including dusk and dawn — and mechanisms for broadcasting multiple control operations allowing lighting commands to be responsive even on slower BACnet LANs, such as MS/TP.
Although BACnet originally was developed largely by building-controls manufacturers, the BACnet committee's vision was to integrate the entire building. That vision is being realized with fire/life-safety, physical-access, lighting, and energy-utilities integration. While work will continue in other areas, such as application profiles, advanced Internet capabilities, and wireless capabilities, completion of current integration efforts likely will not be the end of BACnet's advance through all areas of building automation.
A software engineer for Alerton/Honeywell International, Bill Swan is chair of ASHRAE Standing Standard Project Committee 135, BACnet — A Data Communication Protocol for Building Automation and Control Networks. He also is secretary of International Organization for Standardization (ISO) Technical Committee 205/Working Group 3, Building Control Systems Design. An embedded-systems engineer, he has a master's degree in electronics engineering. He has implemented communications-protocol stacks for BACnet and other protocols and written firmware and designed electronics for devices for the building-automation, test-and-measurement, and radio-frequency-communications industries. He can be reached at bill.swan@honeywell.com.