Understanding BACnet – Inductive Automation Australia

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:

Generally, the wildcard address on 0.0.0.0 will suffice for the bind address, though there may be instances in which you will want to specify Ignition's IP address on a specific subnet if multiple local devices must be created for separate NICs.

On most devices and operating systems, in order to receive broadcasts, your local device must be bound to the wildcard address 0.0.0.0. Multiple local devices may be bound to this address.

Port:

47808 is the default port(BAC0 if converted to hex). Multiple devices may listen on this port, but as the number of devices increases, it's possible that port congestion can cause reinitialization or overall slowness.

In a simple situation on a single subnet, having multiple local devices with the same IP and port settings has no real advantage over a single local device.

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 having multiple local devices with the same bind address and port configuration doesn't provide any advantage. 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: