BACnet

What BACnet/IP Needs From the Network

BACnet/IP is UDP, not TCP, and by default it uses port 47808, written 0xBAC0 in most vendor documentation. Discovery depends on broadcast: the station sends Who-Is as a local broadcast and every device that hears it answers with I-Am. That works on a flat subnet and stops working the moment an IP router sits between the station and the devices, because routers do not forward broadcasts. None of this is visible from the station, which simply reports that discovery found nothing.

The standard answer is a BBMD, a BACnet Broadcast Management Device. One BBMD sits on each subnet that holds devices, and each BBMD carries a Broadcast Distribution Table naming its peers, so a broadcast is unicast to those peers and re-broadcast locally by each of them. Two BBMDs on the same subnet is a configuration error rather than redundancy, and it produces duplicated traffic and duplicate I-Am answers. A station on a subnet with no devices of its own can instead register as a foreign device with one BBMD, which then forwards broadcast traffic to it for the life of the registration; that registration carries a time to live and is renewed by the station, not by the BBMD.

NAT is the case that surprises people. BACnet/IP carries the originating address inside the message payload, in the Forwarded-NPDU a BBMD sends and in the registration a foreign device makes, and a NAT device rewrites the IP header without touching the payload. The result is a station whose requests get through and whose answers never arrive, because devices are replying to a private address they were handed inside the message. Some BBMD implementations expose a public address setting for exactly this reason; where they do not, the workable path is a routed or VPN connection rather than a translated one.

• Firewall rules have to pass UDP 47808 in both directions. A rule that permits outbound traffic only lets the station send Who-Is and never see the answers.
• The Broadcast Distribution Table has to match on every BBMD in the internetwork. A subnet listed in one table and omitted from the others is reachable in one direction only.
• The BBMD's own address has to be static, since every foreign device registration and every peer table entry points at it by address rather than by device instance.
• Separate BACnet internetworks sharing one physical LAN are kept apart by UDP port, usually 47809 and up. Devices on different ports do not see each other even though they sit on the same wire.
• Site to site VPNs and wireless bridges that carry unicast correctly often drop broadcast traffic, so supervision across such a link normally means foreign device registration rather than plain discovery.

MS/TP Trunks: Token Rotation and the Physical Layer

MS/TP is a token bus on RS-485. Only the device holding the token may start a transaction, and the token passes between masters in MAC address order, so the number that governs responsiveness is token rotation time rather than baud rate. Every device on a segment has to run the same baud rate, the usual choices being 9600, 19200, 38400 and 76800, with 76800 the practical ceiling for most field controllers. Adding devices lengthens rotation for every point on the trunk, which is why a segment that behaved at commissioning degrades as terminal units are added years later.

Two device properties do most of the damage when they are left at defaults. Max_Master tells a device how far up the address range to look for a successor, so a device left at 127 on a trunk whose highest MAC address is 12 spends part of every rotation polling for masters that do not exist; setting Max_Master on every master to the highest address actually in use is one of the few changes that speeds up a trunk without touching a single poll rate. Max_Info_Frames sets how many messages a device may send before it must pass the token on, and raising it on the device that does the polling lets that device get more done per rotation, while raising it everywhere simply moves the bottleneck.

• 120 ohm termination at both physical ends of the segment and nowhere else. Extra terminators load the line; missing ones cause reflections that appear as CRC errors at higher baud rates and vanish when the trunk is slowed down.
• Bias applied at one point on the segment, usually by a jumper on a router or controller. Without bias an idle line floats, and the resulting framing errors read as intermittent device dropouts.
• Shield grounded at one end only. Grounded at both ends it becomes a current path, and the error rate then follows the building's electrical load rather than anything happening on the trunk.
• Daisy chain topology. Star wiring and T taps often pass commissioning at 9600 and then fail when the trunk is raised to 38400.
• Correct A and B polarity at every device. A reversed pair usually silences only that device, which makes a wiring fault look like a failed controller.
• MAC addresses unique on the segment, masters in 0 to 127 and slaves in 128 to 254. Duplicates produce token passing failures that appear to move around as devices are power cycled.

How a BACnet Network Appears Inside the Station

The driver adds a BacnetNetwork under the station's Drivers node, and that network holds a Local Device object with its own object identifier and network number, so the station is a participant on the wire rather than an observer of it. Below the network sit device objects, created by discovery or added by hand, and below each device sit proxy points. A proxy point is a Niagara point carrying a BACnet proxy extension that names the object identifier and the property it reads, which is why moving or renaming a point in the station changes nothing on the device, and why renaming an object on the device does not break the point.

Poll rates are not per point values in the way people expect. The BACnet poll service divides work into fast, normal and slow buckets, each with its own rate, and every proxy point is assigned to one of them. Tuning a station therefore means moving points between buckets and setting three numbers, not editing each point, and the working discipline is that only points driving logic or alarms belong in the fast bucket. Points that are written rather than read consume no poll bandwidth at all.

ReadPropertyMultiple collapses many property reads into a single request and response, and on any device with more than a handful of points it is the difference between a usable trunk and a slow one. It is bounded by the APDU size the device accepts, commonly 480 octets on MS/TP against 1476 on BACnet/IP, so only a finite number of properties fit in one response. Devices that advertise ReadPropertyMultiple and then fail on large requests are a recognizable class: the device works while a few points are mapped and begins returning errors as the point count grows. The diagnostic is to shrink the request or disable ReadPropertyMultiple for that one device and see whether the errors stop.

Timeouts, Aborts and What a Capture Tells You

When points go stale, three different causes look identical from inside the station: the device is not answering, it is answering more slowly than the configured APDU timeout allows, or the answer is being lost on the way back. The default APDU timeout is 6000 ms with three retries, so a single unresponsive device can hold a network's attention for roughly twenty four seconds on one request. That is the mechanism behind the familiar complaint that one dead controller made a whole trunk slow.

A capture separates the three. If the request never appears on the wire, the problem is above it: wrong device instance, wrong network number, or a routing path that was never in place. If the request appears and nothing comes back, the device is not answering and the next question is physical. If the response comes back late, the fix is a longer timeout or less load, not more retries, since retries multiply the traffic that caused the delay in the first place. If Reject or Abort PDUs come back, the device is answering in order to say it cannot handle what was asked, and the reason code is specific: buffer overflow or segmentation not supported points at message size rather than at the network.

Segmentation is declared rather than negotiated blindly. A device's Segmentation_Supported property reports one of segmented-both, segmented-transmit, segmented-receive or no-segmentation, and a device reporting no-segmentation can only return what fits in a single APDU. The visible symptom is that reading the device's Object_List fails outright on a controller with several hundred objects while every individual point reads normally. The way around it is to read Object_List by array index, index zero returning the element count and each following index one object identifier, which turns one oversized response into many small ones.

Verifying What a Device Actually Supports

A conformant device carries the answer in its own Device object. Reading Protocol_Services_Supported and Protocol_Object_Types_Supported, which are bit strings of the services the device implements and the object types it can present, together with Segmentation_Supported, Max_APDU_Length_Accepted and Protocol_Revision, is a handful of requests that list what the firmware will actually answer.

Some equipment carries a communication card that wraps an internal proprietary or Modbus bus, presenting a fixed set of BACnet objects that the card refreshes on its own schedule. The card answers every read immediately out of its own cache, so the network looks fast while the values are as old as the internal scan interval, which is often several seconds and is not exposed as a BACnet property anywhere. Polling such a device faster than its internal scan changes nothing except traffic. The way to find the real interval is to force a change at the equipment and time how long it takes to appear at the station.

A PICS states which BIBBs the vendor claims, and a BTL listing states that a particular firmware version passed testing against a particular protocol revision. Both describe the version that was tested, and field equipment frequently ships with different firmware, so the Device object's Firmware_Revision, Application_Software_Version and Protocol_Revision are worth reading and comparing against the version the document covers before treating that document as a description of the device in front of you.