• Articles about BACnet
• FAQs
• History of BACnet
• Fundamentals of BACnet

• How does BACnet work?
  
• BACnet's Collapsed Architecture
  
• BACnet Transport Options
  
• Internetworking
  
• Gateways
  
• Objects
  
• Services
  
• Conformance to BACnet
  
• Testing and Certification
  

Other than new buildings or total retrofits, most facilities which embrace BACnet will have the problem of older systems which are already in place. How can these older systems migrate or integrate with BACnet?

The answer is to use a special device called a gateway. Unlike a router, which sends and receives BACnet messages over different LANs, a gateway must potentially not only deal with different LAN technology, but also different concepts and approaches in the application side of the message. With BACnet routers, only the LAN technology changes, but the messages themselves are the same: they always use the BACnet Application Layer and its concepts.

So the gateway must potentially do a very difficult job. Some of the ideas and concepts in the proprietary system, may have no straightforward equivalent in BACnet, and of course the reverse is also true. The gateway is not just a LAN translator, but it is also a concept translator.

One common approach to gateways is that each proprietary system is viewed as an "island" with the gateway being the only bridge to that island.

With BACnet, it is also possible, and quite normal, to have gateways which interface to proprietary systems at lower levels. For example, a BACnet gateway which interfaces directly to field panels on a peer-to-peer network. Or a gateway to unitary controllers at a very low level.

The ability to provide BACnet gateways at every level is a unique and robust feature of BACnet.

Over the next few years, as BACnet systems and specifications become more common, many vendors will choose to offer these types of gateways to their existing proprietary systems. This approach can be a cost effective solution to wholesale replacement of existing devices with BACnet counterparts.

One of the easiest ways to integrate older systems with newer BACnet-based systems is to use a gateway. The gateway communicates with the older system in its proprietary protocol, and performs the usually complex job of mapping BACnet concepts into equivalent concepts in the older system.

Mapping means creating objects inside the gateway which make the points on the older system appear to be BACnet objects, and behave as standard BACnet objects behave. In some cases, gateways might implement new object types which more closely represent the existing system, rather than try to behave as BACnet standard objects. Other gateway designers may choose to emulate those features required in BACnet objects which are not present in the older system.

A similar variation on this approach is to have a host PC capable of communicating both in BACnet, and in the proprietary communications of the older system. In this case, the host PC software acts as the gateway. You should be wary of this approach and be sure you know what you're getting. In some cases, vendors may implement this scheme so that the host graphics software on the PC is able to look at the old system as well as the BACnet side. But the question is: can the other BACnet devices interoperate with the old system?

This may not be a requirement in your facility. However, if you expect BACnet devices to be able to interoperate with older devices, for example reading temperatures or other sensor values, or adjusting setpoints in the old system, then it is important that the gateway software in this arrangement supports those capabilities.

You can readily tell this by examining the PICS for the gateway.

Of course, it isn't always necessary to have a gateway to the entire existing system. In some cases it may be desirable to only have gateways into selected portions of the old system, for example to a central plant control system.

When specifying or buying a BACnet gateway, it is important to keep several points in mind. As with most things, you won't get anything you don't ask for.

In the case of a gateway to an existing system, the most important question is how much of the old system is visible through the gateway? You may not require complete access to every point in the existing system from the BACnet side. However, a typical new BACnet owner wants to replace the existing system front end with a BACnet one, for forward expansion in the future. As such, it may be important to be able to operate all or most of the existing system from the BACnet front end. If the gateway implementation is incomplete, this may be difficult or impossible.

How closely does the gateway model existing points and functions as BACnet objects? Does the gateway emulate BACnet behaviors, or simply provide proprietary objects equivalent to the existing system? Does the gateway allow you to control and change properties on the old system? Are all the changes stored only in the gateway, or do they propagate all the way into the existing system's controllers. This could be important in a distributed system, if the gateway fails, do the new changes continue to operate?

How much can the old system be expanded after the gateway is installed? If you add a new field panel, for example, to the old system does the gateway allow you to access it? Some vendors may require you to pay substantial upgrade fees for this type of expansion, so it is best to ask in advance!