Understanding BACnet – Inductive Automation Help Center

Introduction:

The purpose of this article is to explain some of the nuances of the BACnet protocol. This article's focus will mainly be on creating and initializing device connections, and understanding how this relates to networking in general.

What is BACnet?

BACnet is "a data communication protocol for building automation and control networks." A data communication protocol is a set of rules governing the exchange of data over a computer network. Ignition's BACnet driver communicates with remote devices via this protocol in order to get tag data that can be used in Ignition.

Broadcast vs Unicast:

BACnet is unique in that device connections are not necessarily initiated by Ignition communicating directly to the remote device. During initialization, Ignition sends out a general "who-Is" broadcast message to the entire subnet, expecting all BACnet devices on the subnet to identify themselves in response to this message. Simultaneously, Ignition also sends a directed(unicast) message to the IP address specified in the remote device configuration. Its important to note that broadcast messages are generally limited to a single subnet, whereas unicast messages can cross subnets as long as those subnets are reachable via routing.

Subnets:

Since Ignition utilizes broadcasts to initialize device connections, special considerations must be made for subnets. Subnets can be considered a sub-network within a network and are denoted by a range of addresses that belong to that specific subnet. In most cases, the usable IP range for a subnet will span from xxx.yyy.zzz.1-xxx.yyy.zzz.254. Broadcast requests will not travel across subnets, so you will need to make sure that the remote device is on the subnet that the broadcast address is configured for and that Ignition can see broadcasts on that subnet as well. It is also important to know that while you may be able to ping a remote device, if the device does not share a subnet with Ignition, broadcasts will fail to generate a good connection.

Network prefix/Broadcast address:

Specifying the correct broadcast address is vital to creating a good connection. The broadcast address is generally the last IP address on the subnet, and an IP subnet calculator is helpful here for calculating the desired broadcast address if you are uncertain of what the address should be. https://www.calculator.net/ip-subnet-calculator.html.

First, you will need some network information from the computer running Ignition. Running ipconfig in command prompt will give you the requisite information. In specific, you are looking for the subnet mask and the IPv4 address.

After supplying the IP address and subnet mask in their respective fields in the calculator, pressing calculate will generate the broadcast address among some other useful information. The network prefix is the number specified by the CIDR Notation, and can also be calculated by counting the number of leading ones in the binary subnet mask. The IP address for the remote device you are attempting to connect to should fall inside of the address range that is noted in the "Usable Host IP Range", meaning that it is on the same subnet that Ignition is broadcasting to.

BBMD/BACnet Router:

There are situations in which Ignition needs to communicate with devices that do not share a subnet with the computer that Ignition is on. You'll need to know what architecture is in place and what hardware is available in order to properly set up connections across subnets. In the case that remote devices reside on subnets that Ignition does not have direct access to, a BBMD or BACnet router is necessary in order to bridge the two networks so that Ignition can successfully communicate with these remote devices. If you are using a BBMD that is not on the same subnet as Ignition, Ignition's local device must explicitly register with the BBMD as a foreign device and communicate through the BBMD to reach the remote subnet. If a BACnet router is available, it can be configured to listen on the broadcast subnet and and will forward requests between subnets without any extra action required from Ignition.

A highly customized network architecture can circumvent the need for a BBMD, however this increases the risk of broadcast storms and also my contribute to security risks and difficulty in maintaining the network as devices are added and removed.

The variety of BACnet devices:

The BACnet protocol is supported by many kinds of devices that may respond in various ways to Ignition’s Who-Is on the network. Depending on the device you are connecting to, the device may respond:

1. only to ignition’s Broadcast message

2. only to Ignition’s Unicast message.

3. to both the broadcast and unicast.

Also, the device may respond with a Unicast of its own or a Broadcast of its own as an I-Am. Wireshark will be able to show exactly what the device is doing. More details about Wireshark are the the end of this article.

How initialization works:

Scenario 1 (Broadcast and Broadcast):

In this scenario, the Ignition gateway and all remote devices reside on the same subnet. They all have access to the same broadcast channel and thus initialization can happen via broadcast messages.

1. Ignition's BACnet driver utilizes broadcast technology in order to initialize/connect to remote devices. This means that Ignition's local device will send a request out to the entire network looking for remote BACnet devices that exist on the network. On the network, this request for remote devices comes in the form of a "who-Is" request.

2. Devices on the network then make themselves known by responding in kind with an "i-Am device x" message sent to the same broadcast channel.

3. From there, Ignition will attempt to communicate with the device that has the ID specified in the remote device configuration. Note that the remote IP address in the configuration is not necessarily respected. Due to the nature of broadcasting, whichever remote device responds with an "i-AM device x" first - where x is the configured remote device ID - Ignition will attempt to make the connection to, regardless of its IP address.

Scenario 2 (Unicast & Unicast):

This scenario is most similar to other PLC device connections. As long as the remote device is reachable by the gateway, the initialization can complete successfully, regardless of subnet. This assumes that the remote device is able to respond with a unicast "i-Am" back to Ignition. Most devices, however, will respond with a broadcast "i-Am", covered in scenario 3.

Scenario 3 (Unicast & Broadcast):

In this scenario, Ignition can successfully send a unicast message directly to the remote address. However, the remote device follows BACnet standards and responds with a broadcast "i-Am" to the subnet that it resides on. Since Ignition is on a different subnet, and broadcasts do not travel across subnets without a BBMD or BACnet router, Ignition never receives the "i-Am", causing initialization to fail.

Detailed Example:

In this section, we'll go over a detailed example of connecting to a remote device with ID 53 on the 192.168.1.x subnet. Detailed explanations will be provided for each necessary configuration setting as well.

Local Device:

Bind address:

The bind address determines which local network interface the BACnet driver listens on. In most cases, use 0.0.0.0. This allows the driver to listen on all interfaces and reliably receive both unicast and broadcast BACnet traffic. When multiple network interface cards (NICs) are present, you can bind a local device to a specific IP address to isolate traffic to a single subnet.

Broadcast handling differs by operating system:

Windows: Broadcast packets are typically delivered even when bound to a specific IP.
Linux and macOS: Broadcast packets may not be delivered unless bound to 0.0.0.0, depending on OS behavior and the BACnet4j version included with the Gateway. Recent versions may bind to both the specific address and broadcast address automatically.

Because behavior varies by platform and version, 0.0.0.0 is the most reliable configuration when broadcast discovery is required.

Port:

47808 is the default BACnet/IP port (BAC0 in hexadecimal). Use one local device per subnet, or assign each device a unique port.

Each local device must use a unique IP and port combination. Configuring multiple local devices to bind to the same address and port is not supported.

When multiple devices share the same socket (for example, 0.0.0.0:47808), the operating system distributes incoming packets non-deterministically. Messages may be delivered to the wrong device or dropped entirely. Even on small systems, this can cause:

missed responses
retries and timeouts
intermittent initialization failures
inconsistent or lost data

Windows link-local address requirement

When using link-local IP addresses in the 169.254.0.0/16 range on Windows, BACnet traffic may not route correctly by default.

If either the local or remote device uses an address in this range, add the following JVM property to ignition.conf:

-Djava.net.preferIPv4Stack=true

Alternatively, use IP addresses outside of the 169.254.x.x range.

Broadcast address/Network prefix:

See the above section on Network Prefix/broadcast address. It is important that the broadcast address is for the subnet that the device you are trying to connect to is on. Ignition must also be able listen on this subnet. If Ignition has multiple NICs and is connecting to remote devices on separate NICs, multiple local devices will need to be created, each with unique ports and corresponding broadcast addresses.

Device number:

This is an arbitrary number that can be set to anything. The only stipulation is that it should be a unique ID in relation to all other device IDs on the BACnet network.

Network number:

This setting should be fine to leave as default. The only time this setting may need to be changed is if there is an existing BACnet network that is already using network number 1 on the network.

BBMD/Foreign Device registration:

If the BBMD you need to connect to is on a different subnet than Ignition, you will need to enable Foreign Device registration and specify the BBMD address. In this example, everything is on the same subnet, so no BBMD is required. It's also important to note that if registrations to multiple BBMDs are required, multiple local devices(with unique address/port combinations) will be needed to make those connections.

Remote Device:

Remote address/Port:

This is the address that Ignition will send a unicast "who-Is" message to. In many cases, this address is not necessarily respected, as Ignition will attempt to connect to the first device that responds with "i-Am device {Remote Device Number}" regardless of its IP address.

Remote Device Number:

This is the most important information, as Ignition will only attempt to connect to a device that has the matching Device ID. It is important to know that certain BACnet routers or BBMDs can sometimes shift device IDs when translating across subnets. Wireshark or a third-party BACnet explorer program is helpful here to browse for all device IDs that are present on the network to confirm the actual device ID that is being broadcasted.

A remote device may have a single IP address with many device IDs associated with it. In this case, Ignition must have a separate remote BACnet device configured for each device ID corresponding to that IP address.

COV:

Stands for Change of Value. These settings are not relevant for the initialization process, as they affect how Ignition polls the devices once a connection is made. If this is enabled, Ignition relies on the device to send updates when values change instead of periodically polling the device.

Discovery timeout:

This field was added in 8.1.4, and dictates how long, in seconds, before the initialization times out. This may need to be extended if connecting over a slow network or to a device with many tags.

Troubleshooting:

Tools:

Wireshark:

Wireshark is an extremely useful network monitoring tool that allows us to analyze packets with greater granularity. Often times, we'll need Wireshark captures in order to fully diagnose problems with initializing connections, as loggers do not provide enough context on their own. In Wireshark, you can apply a display filter for just "bacnet" in order to filter for bacnet traffic specifically.
https://www.wireshark.org/download.html

Yabe:

Yet another BACnet explorer. This is a very useful tool that is able to automatically scan the network it is on for any BACnet devices. Useful for independent testing to see if any devices are reachable from the gateway, and also to confirm device IDs for Ignition to connect to.

https://sourceforge.net/projects/yetanotherbacnetexplorer/

Loggers:

For troubleshooting BACnet initialization, Wireshark will likely provide the best information, however the Ignition loggers under com.serotonin.bacnet4j may provide supplementary information that could be useful to troubleshooting.

Common errors/fixes:

Wrong remote device ID:

If Ignition is sending out "who-Is" messages and other devices are getting back with "i-Am" messages (can be confirmed with Wireshark), where the device IP address is correct, but the device ID does not match what is specified in the remote device configuration, then the Remote ID may not be what you think it is. YABE will be able to confirm what the remote ID should be, and that is what you will need to supply in the remote ID field for the remote device configuration.

No response/wrong response to Ignition's "who-Is":

Most often the cause of no response whatsoever is that the broadcast address is incorrect or Ignition is attempting to broadcast to devices that are on a separate subnet. YABE is a good tool to verify if the computer Ignition is running on can connect to any devices at all. As for solutions, you may need to add a NIC or BBMD/BACnet router in order to communicate with a different subnet.

Example:

In this example, we see Ignition broadcasting to it's own x.x.118.255 subnet broadcast address. We also see Ignition send out a unicast "who-Is" to the device that resides on the .120.x subnet. When receiving "i-Am" responses back, Ignition is able to see broadcasts on the .118.255 broadcast channel, but does not receive anything back from the .120 subnet. In this scenario, a BBMD/BACnet route would be necessary for Ignition to connect to a device that resides on the .120 subnet.

Seeing "i-Am"s, but device fails to initialize:

There are a couple of potential causes for this, but the first place you'll want to check is for any port congestion. As mentioned in the local device settings, ideally only one device or process can be listening on a ip/port. Running this command in command prompt on a windows machine will give a list of all processes listening on port 47808(the default BACnet port).

netstat -anon | findstr "47808"

If you have any third party BACnet explorer programs, it would be best to change their port designation or shut them off. It is also important to note that there are some issues within Ignition improperly shutting down it's local device, leaving a second set of pids listening on the same address/port. This was partially addressed in 8.1.7, and often the only solution once it gets into this state is to restart the Ignition service.

Alternatively, if you see a conversation happening via BACnet protocol between Ignition and your target device in the Wireshark captures, but initialization still fails, you may need to increase the Discovery timeout in the remote device configuration. Prior to 8.1.4, this timeout was set to a static 5 seconds, so if device initialization is taking longer than that hard coded time out, you may need to upgrade to be able to extend that discovery period to allow for initialization.

Summary:

There are a few takeaways that should always be kept in mind when working on setting up or troubleshooting BACnet:

The device number is the key identifier for all devices on the network. Ignition will connect to the device which responds with the matching device number as configured on your remote device in Ignition, even if the response IP address is different. Device numbers should be unique.
An IP address does not necessarily correlate with a single physical BACnet device. Sometimes a single IP address correlates to multiple device numbers, in which case separate remote devices are needed in Ignition.
The primary mechanism in BACnet initialization is "Who-Is"/"I-Am" exchange. Ignition sends out both a broadcast to all devices on the specified subnet as well as a direct unicast to the IP/Device number specified.
In troubleshooting initialization, verify with Wireshark that Ignition's "Who-Is" is being received by the device you're connecting to, and an "I-Am" is being received by Ignition.
In most cases, multiple local devices aren't necessary unless dealing with multiple NICs on the gateway, and configuring multiple local devices with the same bind address and port is not supported and may cause dropped or misrouted traffic. In almost all cases, a local device bind address of 0.0.0.0 is sufficient, and in many cases is required.
A BBMD is a device which helps manage more complex BACnet networks of multiple subnets. Although not technically required, a BBMD is strongly recommended as it makes configuring your network more robust in terms of security, scalability, and efficiency. As the size of networks and number of subnets grow, the need for BBMDs increases exponentially for these reasons.

References: