Frequently Asked Questions

  • What is BACnet?
    BACnet stands for Building Automation Control network. A data communication protocol developed by ASHRAE, BACnet is known as "ANSI/ASHRAE standard 135-2012" (presently) and also as the international standard "ISO 16484-5." Its purpose is to standardize communications between building automation devices from different manufacturers, allowing data to be shared and equipment to work together easily.
  • Why was the BACnet protocol developed?
    ASHRAE realized that automation systems for buildings needed a protocol standard. Because of the proprietary nature of this industry, existing systems for the most part do not permit interconnection between different manufacturers' equipment.

    In 1987, ASHRAE undertook the challenge to develop and put forth a standard set of rules (BACnet) governing communication between various devices used in building control systems. Now that BACnet is the accepted standard by ISO, ANSI and ASHRAE, the foundation has been laid for further industry cooperation.
  • What do BACnet products look like?
    BACnet devices physically resemble other standard control devices you may have seen, but their physical form isn't important. Because BACnet is simply a set of rules for communicating between building automation devices, the microprocessors of these devices are programmed so they will understand the same language and conform to BACnet requirements. The physical nature of the device itself remains unchanged.
  • Do BACnet systems provide anything special that any given DDC system does not?
    Absolutely. BACnet gives you options to choose the right piece of equipment for the right job, from any manufacturer you want, instead of being stuck with the brand of system that's already in place. An increased set of choices permits finer tuning of the installation for better operation. For new installations and retrofits, BACnet offers a future of easy expansions and modifications. When carefully selected, new devices will interface seamlessly with the BACnet system already in place.

    As a wider variety of BACnet devices are developed, heavier system integration of services such as access control, security, fire-life-safety and direct utility company cooperation will become commonplace and easier to implement.
  • Is a BACnet system easily expandable?
    System expansion was the major guiding force when the BACnet protocol was developed. As a result, BACnet is very open-ended:
    • It allows you a larger range of devices to choose from. By selecting the right equipment, not only may a system be expanded, it becomes even more efficient.
    • The building automation industry can easily develop and integrate new products into today's BACnet systems, while providing the means to accommodate tomorrow's needs.
  • What type and size of buildings are best suited for BACnet product installation?
    As with standard DDC systems, buildings of all sizes are capable of being controlled by BACnet systems. BACnet control systems may be simple with very few devices or very complex. The BACnet standard is open-ended, yet has a stringent criteria for device conformance. Thus, it is economically viable for even small facilities to adopt BACnet control systems. As manufacturers develop products to fill all corners of the BACnet industry, more and more devices will appear to satisfy all building requirements and sizes, from the simplest to the most complex.
  • Does a BACnet system provide better building HVAC control than conventional DDC systems?
    Not necessarily. Because BACnet is basically a system of communication rules for building automation equipment, it will not automatically provide better control. However, what makes the difference in how well any given system performs is how carefully, accurately and to what sophistication data is acquired, manipulated and distributed to the controlling devices. The BACnet standard is designed to be open for future expansions, even to the point of allowing devices to contain exclusive proprietary functions, yet overall, retain their BACnet conformance.

    For example, manufacturer A can provide a complete BACnet system fully capable of accepting and integrating devices from manufacturers B-Z; however, manufacturer A's system may also include a few exclusive enhancements that would only be accessible by other manufacturer A products. This by no means excludes manufacturers' B-Z equipment from working on manufacturer A's BACnet system. It simply means that manufacturer A has added some additional features to further promote the company's products. You'll want to carefully study what extra proprietary features a BACnet system includes before making a purchasing decision.
  • What's the upside for the building owner if a BACnet system is used?
    If an owner becomes unhappy with product availability, service, replacement cost, or any other aspect of a specific vendor's installed BACnet compatible product, chances are there's a suitable replacement readily available from another company. The owner can be comforted by knowing that matched BACnet products will perform in the system regardless of the manufacturer. Additionally, if a BACnet product is no longer manufactured, the owner won't have to replace the entire system or keep repairing old devices.

    Here's some of the other benefits owners can look forward to:
    • Choice of adding more sophisticated devices to their system as they become available.
    • Potential savings through reduced equipment cost.
    • Simple integration of BACnet controllers pre-installed on purchased equipment like boilers and chillers.
  • Will a property management company see any benefits from having BACnet controls in buildings they manage?
    Yes. BACnet will make the industry more competitive, allow more choices and provide capability for future expansion. It enables the property management company not to be dependent on a single vendor. As with standard DDC systems, the BACnet protocol allows for the capability of remote monitoring. For smaller installations, this off-site service results in cost savings because they can monitor many sites from one or more central property management locations. One operator interface can be used for many systems.

    An additional benefit will allow you to choose one operator interface for multiple vendors' equipment. Your choice may be based upon graphics capabilities, after-hours data collection or other features.
  • Are there cost benefits to using BACnet vs. conventional DDC controls?
    Absolutely. As smoother integration of various building services comes to pass, facility monitoring and operation costs will fall. Here's what you can expect:
    • Higher quantity and quality of building operational data.
    • Tighter evaluations and analysis.
    • Better fiscal planning and operation of the facility.
    As closer ties with utility providers are forged, more accurate energy provision and consumption data will be available to all. As an end result, there will be more cost-effective energy management and better utility and consumer cooperation.
  • Can BACnet products be used for building retrofits?
    Yes. One of BACnet's strongest points is open-ended, multiple interfaces. As more manufacturers embrace BACnet, an increasing array of products are emerging on the marketplace to take advantage of this. Some of the current devices allow existing non-BACnet systems to interface with BACnet devices. Once the proper interface has been selected, other BACnet compliant products may be matched, selected and used in conjunction with existing facility components.

    Previously, total system remodel was often the only choice if a meaningful upgrade was to be accomplished. With the introduction of the BACnet protocol, that may never happen again.
  • How have consulting engineers been affected by the acceptance of the BACnet protocol?
    There is a strong need for professionals who can thoughtfully recommend products that can integrate seamlessly into BACnet systems. Engineers need to further educate themselves regarding BACnet, BACnet products and networks. It is important to follow BACnet prerequisite when specifying a BACnet system. It's not enough to say "system should be BACnet compliant."

    As facility environmental controls are further integrated with access/security, transport systems, fire and others, engineers will be called upon for their knowledge of BACnet.

    Because the same protocol qualifications must be met by each manufacturer, pricing for BACnet devices is competitive. This bodes well for any engineer desiring to bring together a complete system, with as many features as possible, for the lowest price.

    BACnet systems are by design flexible and expandable. Fewer proprietary systems will be seen as these ideas are further accepted by the industry.

    Because of BACnet's inherent nature of communications, many BACnet devices are being designed with extensive remote access capabilities. Computer dial-up to a building's control systems from the engineer's office is already commonplace. This access to supervising BACnet installations translates into saved time and money for the consultant in charge of monitoring installations.
  • Will the system operator require retraining in order to efficiently monitor and control a BACnet equipped system?
    Probably not. If an operator is familiar with a company's front-end products, there should be little retraining when moving up to a BACnet conforming system.

    The communications part of a BACnet installation will be nearly transparent to the system operator. The system will display at the front-end just as it does now for any given manufacturer. Typically, monitoring and control points with corresponding values will be displayed along with some identifying nomenclature. Also, a given manufacturer's operator terminal may communicate with other manufacturers' control systems. This means once an operator is familiar with one front end, he can continue to use it even if controllers from other manufacturers are used.

    However, as various products reach the market for any given BACnet manufacturer, an operator may need more in-depth training since installation and programming requirements may differ. Of course, this would be true of any new control system.
  • Does BACnet provide a means for networking more than one building?
    Yes, internetworking has been designed into current BACnet products. Campus buildings on a site may be networked with existing or new LAN systems. Buildings not directly connected by LANs may be remotely monitored and controlled through the Internet and by dial-up capabilities of a front-end, modems and phone lines.
  • Is there an independent testing agency to certify BACnet products?
    Yes. There is an organization called the BACnet Testing Laboratory (BTL) for testing and certifying BACnet products. This organization was created by the BACnet Manufacturer's Association (BMA) which has since become BACnet International (BI) www.bacnetinternational.org to have an independent testing agency for BACnet. In February of 2001, BTL began accepting applications for product testing based on the draft standard ASHRAE 135.1P. This testing process is explained in more detail here.
  • Do prorietary extensions to BACnet make devices incompatible?
    Not necessarily. There are essentially three areas where BACnet can be extended: Object Properties, Services and certain Enumerated Values. If a device implements any of these extensions, it is still interoperable with other BACnet devices that share the standard objects, properties and services that it implements.

    If a device implements non-standard objects, or non-standard properties of standard objects, it may still be possible to interoperate effectively with those objects and properties. BACnet object properties have values that are said to be of a particular "datatype." BACnet defines 12 so-called "primitive" or "application" datatypes including real (floating point) numbers, signed and unsigned integers, character strings, bit strings and so forth. BACnet also allows "constructed" datatypes that are collections of primitive and other constructed types. If an object property uses on primitive datatypes, then it is possible to interoperate with the device without special understanding of the context that the values appear in. In simple terms, this means that those objects that have these simple (primitive) datatypes for their properties are more universally interoperable than those that do not. Sticking to this rule still gives vendors tremendous flexibility in implementation, without creating interoperability issues.

    Non-standard services that are implemented in a device generally require special software to take advantage of, and so these usually represent areas where interoperability won't be possible without prior agreement. If a BACnet device depends heavily on non-standard services, then it will have limited interoperability.

    Extended enumerations can appear in several places in BACnet communications. A common area is in the reporting of Alarm and Event notifications. Devices may be designed to report extended "event types" that are not defined in BACnet using so-called proprietary event types. This doesn't necessarily inhibit interoperability but it may be less than optimal in some instances. For example, an operator workstation might receive and report an alarm that is "Event Type 456" if it does not know what the "human readable" interpretation of that event type should be.
  • Are standard objects preferable to proprietary objects?
    Generally no. Standard objects have the advantage that they exhibit behavior that is already documented in the BACnet standard. Proprietary (we prefer to call them "non-standard") objects can't be used unless you know of their existance, and you have a description of their behavior as well. Assuming that you know what a non-standard object's properties are and what they are intended to do, there is no reason not to take advantage of them.

    The mechanism of non-standard objects and/or properties is one of the single most important features of BACnet. It is generally no harder or easier to read and write properties of standard objects, than non-standard ones. The caveat is that for non-standard object properties to be most easily interoperable, they must restrict their implementations to so-called "primitive" datatypes. Otherwise, the objects properties that do not follow this restriction cannot be interpreted out of context and therefore require special software that "understands" the specifics of the non-standard datatype. As a rule, BACnet devices won't have this kind of intimate knowledge of non-standard datatypes unless one becomes "popular" and imitated by many vendors.

    Having said all this, it is important to keep in mind that if a vendor has designed their non-standard object with interoperability in mind, then it may in many cases be easier and more efficient to use than standard objects. Consider, for example, a special type of controller that contains 50 parameters that might be of interest. One way to implement BACnet in this controller might be to represent each parameter value as the Present_Value property of a BACnet Binary or Analog Value object. This has the advantage that everyone knows how to use BV and AV objects. However, even with the minimum set of required properties, BV and AV objects have a lot of additional overhead in terms of memory and required functionality. In contrast those 50 parameters might be more efficiently represented as 50 properties of a non-standard object (or 5 objects with 10 properties, or 2 with 25 and so on). In this case, there is no overhead, and the explanation of how these parameters work might be greatly simplified.
  • Why shouldn't I use OPC instead of BACnet?
    OPC is, by definition, a centralized gateway solution. OPC defines a software interface so that application software such as Operator Workstation can use a common interface to any number of "drivers" which have detailed knowledge about specific communications and protocols. So everything in OPC is in terms of an OPC client software talking (on the same PC) to OPC server software. This has some bad side effects:
    • The only interoperation between system components must occur within centralized workstation software. This is slow, limits scalability, and is unreliable.
    • Because of the centralization, you would have none of the benefits of system expansion, replacement, or bidding flexibility at the subsystem and component level.
    • This architecture places a huge amount of dependence on the reliability of a PC and Windows. This combination is not known for reliable long term operation.
    • If more than a small number of different vendors are involved, there is a big potential maintenance (and reliability) issue as individual vendor components change and are upgraded. Their corresponding OPC servers must also track these changes so there is basically a continuous maintenance commitment. This is not good news for the customer.
    The OPC interface is completely "process control oriented", which is to say very biased toward "memory array" architecture for data, and centralization for control and monitoring. That is extremely limiting compared to BACnet which is highly distributed and object-oriented by design. There is a high tax in terms of maintenance when you rigidly cast every data object into a fixed structure. As this structure changes over time, all instances of tagged access to it must be hunted down and changed. That problem doesn't exist with BACnet objects.

    While OPC may be open in the sense that anyone is free to implement it, you can't get any more open than an International Standard like BACnet. OPC in contrast is permanently jailed in Windows prison.

    The cost of workstation software is the same, whether it uses OPC or something else. The bigger issue is what kind of interfacing is most widely supported within the community of equipment to be automated? Mostly every vendor of building automation equipment can provide BACnet interface at many levels. Why constrain the entire system design to OPC?

    Many third party workstation software can access both OPC and BACnet at the same time through several choices of driver software.

    So don't let the tail wag the dog. BACnet has a very broad range of capabilities and vendor choices available and that range is growing very quickly now that BACnet is an International Standard. By taking a system-centric view, instead of a workstation-centric view, the customer will have a huge amount of additional flexibility in choosing components at every level, creating true interoperation in a distributed manner, and enhanced bidding flexibility. At the same time, none of his workstation options will be reduced in any way!

    By confining the entire system to OPC-only, none of these benefits can be realized and he will face potentially costly barriers to expansion and maintenance going forward.
  • Where can I get formal education about BACnet?
    There are currently three venues for BACnet education:
  • I don't see my question here...send your question to PolarSoft