- 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-2001" and now 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 ANSI and ASHRAE, and is currently being
considered for adoption internationally, 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
- 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
- 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
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
- How are consulting engineers going to be affected by the introduction 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 the developer of the BACnet protocol, ASHRAE is the definitive source for BACnet
educational materials. 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 will be 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 new 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
- 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 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)
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
- 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
- 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
- Where can I get formal education about BACnet?
There are currently four venues for BACnet education:
- I don't see my question here...send your question to PolarSoft