|♦ What is BACnet?
♦ Why was the BACnet protocol developed?
♦ What do BACnet products look like?
♦ Do BACnet systems provide anything special that any given DDC system does not?
♦ Is a BACnet system easily expandable?
♦ What type and size of buildings are best suited for BACnet product installation?
♦ Does a BACnet system provide better building HVAC control than conventional DDC systems?
♦ What's the upside for the building owner if a BACnet system is used?
♦ Will a property management company see any benefits from having BACnet controls in buildings they manage?
♦ Are there cost benefits to using BACnet vs. conventional DDC controls?
♦ Can BACnet products be used for building retrofits?
♦ How have consulting engineers been affected by the introduction of the BACnet protocol?
♦ Will the system operator require retraining in order to efficiently monitor and control a BACnet equipped system?
♦ Does BACnet provide a means for networking more than one building?
♦ Is there an independent testing agency to certify BACnet products?
♦ Do prorietary extensions to BACnet make devices incompatible?
♦ Are standard objects preferable to proprietary objects?
♦ Why shouldn't I use OPC instead of BACnet?
♦ Are there any advantages or drawbacks to combining BACnet & Lonworks in a single system?
♦ Why should we use BACnet and not other protocols like Lonworks or MODBUS?
♦ Are we going to be seeing more native BACnet on equipment or is the industry trending toward BACnet Gateways?
♦ There seems to be a lack of vendor and third party trained resources to support device, functional and application integration for BACnet. How is this being addressed by the industry?
♦ Why is there not higher compatibility between different manufacturers doing BACNet? Sometimes a point is read only, not read/write. Should not "BACnet compliant" mean that everything is read/write?
♦ Considering the current state of the controls market and BACnet, what are the odds of getting a control loop with equipment made by 6 different manufacturers (chosen at random) to work properly?
♦ Is it possible to create Fire/Lifesafety systems with BACnet?
♦ Is Lonworks backed by ASHRAE?
♦ I work for a government agency and therefore must go out for bids for any new product. Who are your nearest competitors and what should I know when producing bid specs? Do you have many government entities as customers? Is compliance an issue regarding your standard?
♦ I have experienced mechanical technicians that are not always familiar with BACnet infrastructure and are quick to blame the technology as the main point of failure and put the responsibility back on us to contact a vendor.
♦ What is the difference between the terms "BACnet" and "true BACnet?" Do some devices offer only limited BACnet?
♦ Is there a BACnet Interest Group in the US?
♦ Over time we've designed several different BAS systems into our stores. Does BACnet allow us the option to operate them and to talk to them all?
♦ Is BACnet plug & Play?
♦ In a BAS can my Automated Logic technician program a Delta Controls VAV controller or vice versa?
♦ How vulnerable is BACnet to hacking into a system?
♦ What's the difference between BACnet and Ethernet?
♦ When multiple vendors supply equipment, who determines what information is available to the owner and the BACnet console? Is all the information available by the BACnet console without reprogramming each vendor interface if changes are needed?
♦ Is BACnet involved in the Smart Grid standardization work?
♦ Who makes up "the BACnet council?" DDC vendors? How can I contact them?
What is BACnet?
BACnet stands for Building Automation Control network. BACnet is a data communication protocol developed by ASHRAE, BACnet is known as "ANSI/ASHRAE standard 135-2008" 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 standard method of communications. 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 easily 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 stringent criteria for device interoperation. 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:
Will a property management company see any benefits from having BACnet controls in buildings they manage?
- 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.
Yes. BACnet continues to 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:
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.
- Higher quantity and quality of building operational data.
- Tighter evaluations and analysis.
- Better fiscal planning and operation of the facility.
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 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 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 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 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 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 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 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.
- 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.
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.
Are there any advantages or drawbacks to combining BACnet & Lonworks in a single system?
The short answer is that there are no advantages and many drawbacks.
A mixed system with both BACnet and Lonworks components would have many issues with commissioning, maintenance, training and degree of interoperability. Each of these ought to be reason enough in itself not to try to mix systems but taken together they represent a significant set of obstacles. Trying to mix BACnet and Lonworks systems, unless there is some exceedingly compelling reason to do so, is just not a good idea and will almost inevitably lead to problems that a single homogeneous system, whether BACnet or Lonworks, would not have.
Why should we use BACnet and not other protocols like Lonworks or MODBUS?
There are some companies, historically, that have used MODBUS because their markets overlap with industrial controls where MODBUS is more common. These systems (industrial, boiler control, etc.) tend to be smaller with highly centralized control. This is quite different from modern decentralized DDC systems. So the centralized master/slave approach of MODBUS is at a significant disadvantage in typical BAS applications. The other problem with MODBUS is that its concept for data access is “memory file” oriented which places the burden of understanding and structuring information on the controller that is asking for data. In a centralized system, where the big brain is in one location, that is less of an issue. For decentralized BAS systems that is a design and maintenance disaster.
Lonworks-based products have been applied to many kinds of automation problems. In fact,worldwide deployment of Lonworks-based systems applied to BAS is extensive, particularly in terms of systems that have limited size, scope and interoperability requirements.
By comparison, since its introduction in 1995, deployment of BACnet-based systems has grown substantially both in terms of number of vendors and products, as well as number of installed devices. This trend has picked up a lot of momentum since BACnet became an international standard in 2003. Perhaps we can explain the increasing popularity of BACnet by pointing to some of its principal benefits:
- Practical interoperability between building automation and controls systems from multiple vendors
- Real choices for scalability between cost, performance and size
- Systems based on a single unified ANSI and international standard and Testing standard
- Endorsement and adoption by nearly every major building automation and controls vendor in North America and in many other countries
- Capability for integration with and use of existing LANs and LAN infrastructureHighest performance and Lowest cost
- Robust internetworking including multiple LAN types and dial-upEasy and robust scalability from very small to enormous system sizes
- Unrestricted growth and the ability to add new innovations and new features anytime
- An open, transparent, no fee, consensus process for ongoing use and maintenance of the standard where every interested party has a voice
Are we going to be seeing more native BACnet on equipment or is the industry trending toward BACnet Gateways?
As a general statement, BACnet gateways are not popular and there has been a distinct bias against this approach for a long time. The trend for at least the past ten years has been to implement native BACnet capabilities directly in devices. Some kinds of devices have chosen to imbed what is essentially a gateway directly into the device itself as a kind of coprocessor. This isn’t really a gateway and isn’t necessarily something bad. In this instance, because the functionality is imbedded within the device itself, it should be considered integral to it.
The traditional concern about gateways is when the device(s) that are being represented to BACnet are physically remote or separated from the BACnet device itself. The gray area is how one defines “remote” and “physical separation.” Is a device that is 36 inches away, in the same enclosure, physically remote? How about 6 inches away? The consensus has been not to make such fine distinctions about native BACnet devices. The spirit of the idea of native BACnet devices is that the components of the device are all within a very close physical sphere, such as the same enclosure. If you can’t put your arms around it, then it’s “remote.” A key point being that a native BACnet device represents one logical piece of equipment and not multiple separated pieces as a subsystem.
There seems to be a lack of vendor and third party trained resources to support device, functional and application integration for BACnet. How is this being addressed by the industry?
Unlike proprietary technology, which by definition can really only be supported by the vendor’s own employees or factory-trained representatives, BACnet has created a market for third parties who can offer support, training and hardware/software resoruces on a par with or even surpassing traditional vendor-sourced services. There are a growing number of sources for third party BACnet applications, and support. Just Google “third party bacnet products” as an example. This creates some pressure on vendors to improve their own offerings and/or take advantage of these products/services for their customers.
The BACnet standard itself is under continuous improvement to help simplify some of these issues, and a good share of the active proposals before the SSPC have ease of understanding/use/clarification as their motivation. BACnet International has formed the Education Committee whose charter is to address a lot of these kinds of concerns and to develop education materials, seminars and programs for the industry.
Why is there not higher compatibility between different manufacturers doing BACnet? Sometimes a point is read only, not read/write. Should not "BACnet compliant" mean that everything is read/write?
BACnet uses the term "conformant" and generally it means "to conform to what the standard says is required , or if optional to behave as the standard says when you choose to implement it." I suspect what you mean to ask is: why don't more devices implement more optional features of BACnet? The answer, sadly, is that the standard doesn't require it and many features come down to more cost. During the long process of creating BACnet and achieving consensus, there were many disagreements between vendors or end-users and vendors, about what should and should not be a required capability. Invariably many of these arguments came to the vendor asking the question "will you pay more if it does that?" and the end-user or consulting engineer saying "no." So there are lots of options in BACnet and that is a good and a bad thing.
Vendors tend to fall into two camps. One camp wants to keep costs to the barest minimum, or is catering to a market where cost is the dominant consideration (let’s call this Plan A). The other camp is feature-driven and either caters to a less cost-sensitive customer, or tries to buy market position with a richer featureset and uses the increased volume to reduce the cost of providing those features (Plan B). For the buyer or specifier, if you want less variability you can specify features that YOU require. This may limit the choice of vendors though and obviously skews the decisions to the camp that favors Plan B.
Speaking directly to the read/write question, not all properties are meaningful to write to, and besides requiring a LOT more costly non-volatile storage, make actually make the system harder to use or easier to compromise. After a long time (23 years) there is nothing approaching a consensus that everything should be writable, and in fact I would characterize the consensus as the opposite of that. Having said this, there are lots of common properties such as Description, Object_Name and so forth that should be writable in all but the most extreme cases, but to date this idea never seems to get the votes. If buyers really want those features, they have to speak with their money and demand them and vendors will follow suit. But not for free because these things have a tangible cost.
Considering the current state of the controls market and BACnet, what are the odds of getting a control loop with equipment made by 6 different manufacturers (chosen at random) to work properly?
This is a question that can't be answered for BACnet or any other popular interoperability method without a very large database of hard data. Sadly, no such database exists. It's also somewhat tangential to BACnet. With or without BACnet the "odds" are mostly the same as this has more to do with the usability of device, than whether one device can interoperate with another. Designers of control devices make choices about the degree of assumptions they are willing to design for. For example, some control loops only accept hard-wired inputs, while others can be configured to "get" their input data from other devices that actually have sensors. Some devices don't "get" this data but presume that it is proactively "pushed" to them. The same is true of outputs; some devices containing control loops only have hard-wired outputs while some other can provide the loop calculation for the output to another device, by pushing or getting. Some protocols, such as BACnet, are very flexible and allow combinations of these techniques, while other protocols, such as Lonworks, use only one fixed technique.
Given the tendency among current BACnet products on the market to use mostly BACnet standard object types and common BACnet services, it is highly likely that all 6 randomly selected devices would be interoperable and able to work properly. Thanks to BACnet's flexibility, BACnet International-sponsored "plug fests", and a growing initiative in BACnet Application Interfaces, the kind of problem that is the subtext of this question is rare in BACnet.
Is it possible to create Fire/Lifesafety systems with BACnet?
BACnet was designed from the very beginning to make this possible. However there are some aspects of existing testing and certification of Fire/Lifesafety systems that have so far prevented the use of native BACnet as the foundation for signaling in such cases. However, there are numerous examples of UL listed Fire and Lifesafety systems that can provide BACnet interfaces, either natively or through gateways. This not only greatly simplifies integration, but can provide direct interoperability as well.
Is Lonworks backed by ASHRAE?
No. Lonworks was developed by Echelon Corporation. The LonTalk protocol was proposed as an IEEE standard and is now ANSI/IEEE 709.1. It should be noted that 709.1 does not incorporate some aspects of Lonworks, or any of LonMark, or any of the ANSI/CEA-852 tunneling protocol for IP. Repeated attempts to introduce support for Lonworks into ASHRAE GPC-13 have been defeated through an open consensus process.
I work for a government agency and therefore must go out for bids for any new product. Who are your nearest competitors and what should I know when producing bid specs? Do you have many government entities as customers? Is compliance an issue regarding your standard?
BACnet is an international standard (ISO-16848-5) as well as an ANSI standard (ANSI/ASHRAE 135-2008). As a standard, it is not a product with "competitors." One of the key motivators behind the creation of BACnet, which has been a standard since 1995, was to assist government and municipal entities in specifying and procuring equipment that was able to interoperate in standardized ways. BACnet has been very successful in this regard, and today there are literally millions of BACnet devices in use worldwide, many of them in government facilities. Producing interoperability specifications requires some consideration though because the whole point of interoperability is being able to perform specific interoperations. Just like pressures, diameters, lengths and sequences of operation, interoperability must be specified in some detail. You MUST NOT just say "shall be BACnet" as this is really not a meaningful amount of detail.
Since BACnet allows devices to implement only portions of the standard, conformance is an issue. You must decide, based on the degree and type of interoperability you want in each portion of a system, how much conformance is require by each device. Again it would not be meaningful to require conformance to the whole standard for everything. Many specifiers have realized that it pays to become educated about BACnet and how to specify and apply it successfully. There are in fact some consulting engineers who specialize only in BACnet.
I have experienced mechanical technicians that are not always familiar with BACnet infrastructure and are quick to blame the technology as the main point of failure and put the responsibility back on us to contact a vendor.
This situation is not BACnet's fault or unique to BACnet. There are some important things to consider that this question brings to mind. In our own experience handling technical support for our BACnet products, and assisting other manufacturers of BACnet products, I can tell you that 99% of the time problems are caused by human error and not faulty BACnet products. The best solution is better education and that's one of the reason's why BACnet International has organized its Education Committee to help create and distribute materials, advice and resources for end-users and vendors alike. One of the best things about BACnet is that it is an international standard and therefore creates a market for third parties that can offer services and tools and education that formerly were only available in proprietary form direct from vendors.
What is the difference between the terms "BACnet" and "true BACnet?" Do some devices offer only limited BACnet?
The BACnet standard does not define any such term as "true BACnet." By design and intent, BACnet is a collection of possibilities, and a particular BACnet device may only implement some of the possibilities. A device that implements A, B and C isn't "inferior to" or "less true" than a device that implements A, B, C and D. The point is to define a standard definition of the kinds of capabilities needed in various building automation interoperations, then a device designer can choose which capabilities are appropriate for their device. Of course alll of these choices will be filtered by the usual concerns for cost, reliability, complexity etc. Some devices will be "better" than others, but probably not because they use BACnet, but because of how flexible, costly, reliable, serviceable and so forth they turn out to be.
Trueness in this context can be a subjective measurement. For example, some people might say that a BACnet standard analog input (AI) should implement ALL of the optional properties of the object, otherwise it's not a "true BACnet" device. That position is not what the standard says, nor what the intent of the standard's writers was. By their measure a "true BACnet" device would implement whatever required properties of the AI are, and whatever optional ones it needed, and a "true BACnet" client device would be able to talk to that one and deal with present or missing properties gracefully.
The short answer is, YES nearly all BACnet devices implement an intentionally limited subset of the whole standard, and that's OK and expected.
Is there a BACnet Interest Group in the US?
Yes. BACnet International now fills that role.
Over time we've designed several different BAS systems into our stores. Does BACnet allow us the option to operate them and to talk to them all?
If the stores use controllers based on BACnet, then YES. You could use a wide area network (WAN), the public Internet, or even dialed telephone access to connect a central workstation or management center to each remote store. You can separate operation into alarm handling and operational monitoring and changing of setpoints etc. Or combine those features together. The central monitoring station could generally be supplied by a vendor not necessarily the same as the vendor of controller in each store, and from store to store you could conceivably have different vendors as well.
Is BACnet Plug & Play?
No. In fact there is no plug and play standard for building automation for some very good reasons.
When you buy a DVD player and take it home there is nearly 100% certainty that you can plug it into your TV and it will work. This is because the interoperation that needs to take place is restricted to one operation (sending a TV signal) and the plugs, cable and signal format are rigidly defined, with only one sender (the DVD player). This is a "plug & play" system. You'll note however that the DVD player doesn't automatically turn on your TV when you press play, or automatically change from 4:3 to 16:9 aspect ratio, or automatically select the right input, or automatically reprogram your remote control to know how to talk to the DVD player either! These, and dozens more parameters and options, are a "local matter" meaning that some human has to read the manual and figure these things out, usually using a proprietary method to configure the remote controls and settings. And that's just one basic interoperation.
A large building automation system contains hundreds, if not thousands or tens of thousands of these kinds of unique interoperations. The number of combinations alone is in the millions. So how can it ever be made to work? The answer, for BACnet anyway, is that the standard defines fairly robust methods for making these kinds of connections, but not all of them are automatic. One of the reasons for this is that humans sometimes have to be involved in the decision making because the individual controllers don't (and can't) see the big picture.
Having said all of this, for fundamental operations like reading and writing object properties and various other common interoperations, BACnet can sometimes seem to be plug & play. That's good because it simplifies creation of larger and more complex building systems, but the bad part is that humans still need to be involved in some of the decisions.
In a BAS can my Automated Logic technician program a Delta Controls VAV controller or vice versa?
Generally no. Although BACnet defines many kinds of interoperations between devices, it does not yet have any standardized programming capability. Part of the reason for this is a lack of consensus between vendors that such a thing is even a good idea, let alone the technical details of how it should be standardized. Until such time as this kind of thing becomes part of the standard, program creation and maintenance will continue to be performed by proprietary tools from each vendor, which may or may not be available to or understood by competitors technicians.
How vulnerable is BACnet to hacking into a system?
This is an easy question to be misleading and to some extent it depends on what you mean by "hacking into." In general, and this applies to all BAS communications, not just BACnet, the first issue with "hacking" is whether the hacker has physical access to the communication network. If I can stand in front of an MS/TP controller and unscrew it's 2 wire network connection, that's physical access. If I can plug into an Ethernet switch that is being used for BACnet/IP, that's physical access. If one has physical access to the network, then the only defense against hacking-to-discover is for the messaging to be encrypted in a way that can't realistically be deciphered at least very quickly. Normal BACnet systems and controllers do not provide this kind of protection. The new Addendum g to the 2008 standard defines an alternative Secure Network Layer with a heavy duty approach for these types of use cases where physical access is possible. At the moment, there are no device on the market that implement this new part of the standard.
If only BACnet/IP devices are used, then one alternative is to use managed switches that provide virtual private network (VPN) features. These types of switches are managed from a secure central workstation that can communicate to each switch and configure it as part of a virtual network. Switch ports on the virtual network appear to have their own dedicated wire and so tapping onto the network at any other point even an expert would be unable to decipher traffic to a given port. However, if you have physical access to the actual Ethernet cable and actual controller, you could easily defeat this kind of security. Despite the seemingly attractive use of such managed switches to solve the security problem, they are still physically vulnerable.
If a system wants to use the public internet, or a public portion of an otherwise private network, then there are several alternatives in addition to the Addendum g and managed switch approach. A security appliance can be used to provide secure tunneling from outside into the private network. As long as the appliance is itself physically secure, this can be a much more cost-effective (and simpler) alternative that is available already. Generally speaking, such BACnet networks that use tunneling appliances and/or firewalls may need to have BACnet routers that are specially aware of the firewall and can adjust their forwarding policies accordingly. The BACnet standard does not yet address this capability despite a commonly used technique that makes this work.
What's the difference between BACnet and Ethernet?
Ethernet is a particular kind of electronic technology for transporting messages from place to place across a network. Think of it like an envelope, or a picnic basket with a "please deliver to Margret" card on it. BACnet is a particular set of ideas for representing interoperations between automation devices and some rules for how to move messages from place to place. Think of it as a picnic lunch with many optional types of food.
One thing we can do is to transport BACnet picnics in an Ethernet basket. When we do that, BACnet requires that we organize the basket into particular compartments, so the plates go here, the wine goes there etc. Other kinds of non-BACnet picnics could be put into an Ethernet basket, but they would be organized differently. When BACnet uses Ethernet it uses an international standard (two actually) called ISO-8802-3 and ISO-8802-2. This is a specific kind of compartmentalization that is standardized.
There is another, quite different, kind of compartment standard that is called Internet Protocol (IP). You can also use IP with Ethernet baskets. It has various other schemes for subcompartments and additional rules. One of these schemes is called Transmission Control Protocol (TCP/IP) which is used for lots of things. One of these is yet another set of rules (a language really) called Hypertext Transfer Protocol (HTTP) that is used for communicating to websites. However there is a much simpler scheme called User Datagram Protocol (UDP/IP). UDP is another really simple kind of subcompartment scheme. We can send BACnet picnics also using UDP. This is called BACnet/IP but the name is misleading because a BACnet/IP message contains a BACnet picnic, in a BVLL wrapper, in a UDP datagram, in an IP compartment in an Ethernet basket. Why go through all this trouble? Because the UDP/IP framework allows the BACnet picnic to ride around on multiple networks and get transported many places where the simple Ethernet basket on its own can't go.
Regardless of the basket and the wrappings, the same BACnet picnic arrives in each case.
When multiple vendors supply equipment, who determines what information is available to the owner and the BACnet console? Is all the information available by the BACnet console without reprogramming each vendor interface if changes are needed?
As a rule, the specifier specifies what information is to be made available through BACnet according to their perception of what information is needed for each portion of a system. Left unspecified, vendors can't be expected to provide something they haven't been asked for. In some cases, innocent mistakes are made and you only realize after the fact that a certain piece of information is needed that you didn't ask for. It may or may not be easy for the vendor to provide access to this information, depending on their system design. In some instances, for example for BACnet standard object types, the standard is clear about required vs. optional information. However, if the specifier says something like "provide BACnet standard analog input for lobby space temperature" but does NOT specify that the normally optional property Description be provided, then don't count on the vendor being able to add that after the fact, as some devices don't support this optional property. So it's possible that unspecified information is available, or can be made available with some programming change, of can't be made available. This is one reason why it is important to specify the interoperable information thoroughly and clearly up front.
Is BACnet involved in the Smart Grid standardization work?
Yes. BACnet has been identified as a Smart Grid standard important in the customer domain. Members of the BACnet committee are active in the NIST standards coordination effort in the Smart Grid Interoperability Panel and specifically within the Building-to-Grid (B2G) domain expert working group. These members are serving in other standards efforts beside BACnet, including in the OASIS Energy Interoperation TC that is addressing a DR messaging standard at the customer-grid interface, in the OASIS Energy Market Information Exchange TC focused on definition of price and product, within the EIS Alliance effort to define energy information requirements within the facility domain and now a new ASHRAE committee to standardize an information model to address these energy application communications across the customer (RCI) domain. Also, within BACnet, the SG-WG is working to take these external activities and translate them to BACnet constructs for effective smart grid integration of the facility.
Who makes up "the BACnet council?" DDC vendors? How can I contact them?
There is no "council." There is a Standing Standards Project Committee (SSPC-135) that is organized by ASHRAE and has 13 voting and 13 non-voting members. Each member is limited to 4 years and members rotate off and may rejoin again after 4 more years. The selection of committee members represents a balance of vendors, end-users, consulting engineers, government and interested third parties. Voting is by a consensus process not simple majority. This committee began as a Standards Project Committee (SPC-135) and became SSPC when the standard was released in 1995. Not counting the name change this body has been in continuous operation for over 23 years. The SSPC has a number of Working Groups that deliberate and propose new additions and changes to the standard, each with its own convener. The SSPC has a Chairman, Vice Chair and Secretary who serve typically four year terms.
The SSPC and Working Groups meet four times per year; twice in conjunction with ASHRAE Summer and Winter meetings, and two Spring/Fall interim meetings. All four meetings are open to anyone who wishes to attend. Although formal votes are restricted to voting members, many votes are informal "straw polls" and discussion is open. You can have a voice by coming to a meeting.
There are various ways to contact the SSPC. You can join the general email discussion list BACnet-L. You can contact any committee member, or BACnet International. You can find this kind of information at the www.bacnet.org website.
In addition to the SSPC, BACnet International has a BTL Working Group composed of BI members that meet separately from the SSPC and set the agenda for BACnet Testing Laboratory (BTL) test procedures which are closely aligned with, but not always the same as the SSPC's test standard 135.1. BTL-WG has formal liaison with the SSPC.