“There is no doubt that BACnet is an excellent and versatile protocol for building automation. Its strength is in its flexibility to interconnect different equipment but, to make the most of an open system, it’s important to consider the infrastructure and the functionality that’s actually needed”, says Dave Kitching of Siemens Building Technologies.
In specifications for building automation systems, BACnet (Building Automation and Control Network) is making an increasingly frequent appearance, and the reasons for this are not hard to find. BACnet is an open protocol which means that specifiers can mix and match products from many suppliers, thereby allowing them to choose the most appropriate and cost-effective item for their application.

BACnet was developed specifically for building automation by ASHRAE – the American Society of Heating, Refrigeration and Air-Conditioning Engineers. It is now an internationally recognised standard (EN ISO 16484-5) and a European CEN standard, all of which is an important comfort factor for many specifiers and building owners. BACnet is also being extended to encompass security, access control and even fire safety systems.

When specifying a project, the first issue that needs to be considered is whether the devices to be used are native BACnet or whether they require a gateway to convert from another, possibly proprietary, protocol. Native BACnet means that open communication is a built-in property of the system and requires no additional hardware, software or services.

Native also means that all objects and services referred to in the standard (and their functional profiles) are fully supported, and compliance with the standard is verified. Declarations of conformity should be provided by manufacturers in the form of PICS/BIBBS (discussed later) on request. With non-native systems connected via gateways and interface modules, only interactions that are mutually supported by both systems can be executed.

BACnet can operate with a number of transport media, including RS232, MS/TP, LonTalk, ARCNET and Ethernet. These various media also allow for further variations, such as fibre optic and wireless communications. When designing a system, therefore, consideration must be given to the type of communications each device will use and to the performance, resilience and distances required.

The common denominator for most BACnet devices is either built-in Ethernet or the connection of Ethernet routers. This means that a typical Open BACnet project would use an Ethernet backbone to allow interconnection of the BACnet devices.

The benefit of BACnet’s support for Ethernet is that it can be used on a building owner’s existing IT infrastructure. However, in practice, even the most liberal-minded of IT departments are cautious of sharing their network with the BMS, and there are sometimes good reasons for this. The BMS devices are an unknown quantity to the IT staff and they have to consider the performance, resilience, security, and capacity of the IT system.

With respect to performance, IT departments are often concerned that BACnet devices will swamp the network with communications, thus slowing down the critical business processes. BACnet is, however, designed to send only small ‘packets’ and it only transmits data if there has been a significant change of value. It is possible, therefore, to show that it will have a negligible impact.

Resilience works both ways. The connection of BACnet devices on the network should not have any detrimental affect, but the implications for the BACnet building controls of the network being shut down for maintenance etc must also be considered.

Particularly in large organisations, it’s not unusual for maintenance and modifications to mean that the IT network is regularly shut down for long periods outside normal working hours. This is, however, not acceptable if the network is also being used to support any or all of the BMS, access control and fire protection installations.

Security is again a two-way issue. The IT department will want to be certain that outside infiltration of the IT network is not possible through the BACnet devices. Equally (especially in open IT networks such as a university campus) there needs to be firewall or other protection for the BACnet equipment on the network.

Lastly there is the issue of the capacity of the IT network. This involves a number of factors, such as the availability of network points, hubs etc to support the connection of additional equipment. The allocation of IP (Internet Protocol) addresses to allow the devices to be seen also needs to be considered. The more BACnet devices that are connected directly to the IT network, the more these issues need detailed consideration.

An alternative scenario is an installation made up of IP islands. These are essentially separate sub-networks, using forms of communication other than Ethernet, where local BACnet devices are grouped together. These groups or islands are then connected through a single BACnet Ethernet router to the IT network.

A good example would be a hospital site where BACnet devices within a building are networked separately from the IT network and then the group of BACnet devices is connected through a single link to the IT network. This arrangement allows the separate buildings on the site to communicate via the IT network.

The objective of most users is to have an integrated system where all of the installations can be monitored and controlled from the same user terminal. This is where BACnet shows particular strengths, as it provides an excellent way of linking the individual IP islands. Also, because BACnet is optimised for building control, it supports the user interface functions which are needed for effective building monitoring and management.

With the issue of device communication covered, we can now turn to the functionality to be expected from BACnet devices. The design of BACnet includes elements that allow consultants etc to specify what they need from the BACnet device. The detailed definitions of the BACnet device properties and functionality are described in a Protocol Implementation Conformance Statement or PICS.

The PICS describes the classification of the BACnet device. Examples of classifications are:

1. B-OWS – Operator Workstation

2. B-BC – Building Controller: free programmable controller, providing all BIBBs

3. B-AAC – Advanced Application Controller: free programmable controller, providing all important BIBBs

4. B-ASC – Application Specific Controller: fix programmed, configurable controller

5. B-SA – Smart Actuator, BACnet compatible actuator

6. B-SS – Smart Sensor, BACnet compatible sensor

Each classification is made up of a number of relevant BIBBs (BACnet Interoperability Building Blocks) which provide detailed but manageable information on the BACnet functionality of a product; for example, whether the device has data logging capability, time schedules etc.

Manufacturers have to publish their conformance to the BACnet standard and provide documentation as described above, but how is it possible to be completely certain that a BACnet device will be fully interoperable with other BACnet devices? The answer is provided by the BACnet Manufacturers Association (BMA) and its BACnet Testing Laboratory (BTL) which provide the means and rules for worldwide conformance testing and certification.

This means that manufacturers can have their devices independently assessed for conformance to the standard. Devices that have been tested carry the BTL logo which should give specifiers etc more peace of mind. Unfortunately, however, the BTL scheme does not yet have testing processes for all types of device. Therefore, although a piece of equipment is fully compliant with the BACnet standard, it may still not be able to carry the BTL logo.

We have covered the hardware communications and the functionality defined for a BACnet Open System and now we want all of the devices to interact to provide building wide functionality. Unlike other protocols, BACnet does not need a central network design tool to bind devices together. This gives more flexibility in the approach to designing and installing the network, but it does mean that the installers of BACnet devices need to share with each other the BACnet addresses they have used.

There is no doubt that BACnet is gaining a great deal of interest and, in practice, there is no premium involved in installing BACnet devices, even when open functionality is not required.

Where an open system is required, the best advice is to work closely with suppliers which, like Siemens and its partners, enthusiastically embrace the opportunities offered by BACnet, but are expert enough to evaluate every application impartially, and to apply BACnet in the most appropriate form for the job in hand.