BACnet vs Modbus: Which Protocol for Your Building Automation Project?

What "Supports BACnet" Actually Guarantees

Both protocols are graded, and the grade is what determines how much work the integration takes. ASHRAE 135 defines device profiles built out of BIBBs, the BACnet Interoperability Building Blocks, and the profile sets the floor. A B-ASC device, an Application Specific Controller, is required to answer ReadProperty and WriteProperty and not much beyond that. Change of value subscription, ReadPropertyMultiple, trend log objects, schedules, alarm and event notification, and segmentation are each declared separately, and a device can legitimately claim BACnet support with none of them.

The document that settles this is the PICS, the Protocol Implementation Conformance Statement, which a conforming device is supposed to publish. Ask for it before you specify the device and read the BIBB list against what your sequence actually needs. Two devices with the same profile can still differ in maximum APDU size and in whether they support segmented responses, and both of those decide whether you can read an object list or a large array in one transaction.

"Supports Modbus" is even less specific, because there is no profile at all. What you need from the vendor is the function code list and the register map. A device may implement 03 for holding registers and 04 for input registers but support only 06, write single register, and not 16, write multiple registers, which decides whether a multi-register setpoint can be written atomically or has to be assembled in two writes. Ask as well for the maximum number of registers the device returns in one response, which is often well below the protocol ceiling of 125, and whether the unit is a native Modbus TCP server or an RTU device sitting behind a gateway.

Update Rate Is the Constraint Nobody Checks

Modbus is strictly poll and response. There is no unsolicited reporting in the protocol, so every value on a graphic costs a transaction. On RTU the arithmetic is unforgiving: at 9600 baud each character is about 11 bit times, a read of 20 registers is roughly 8 bytes out and 45 back, and between frames you owe a 3.5 character silent interval plus whatever the device takes to turn around, commonly 10 to 50 ms. Multiply that by the number of slaves on the daisy chain and you have the real ceiling.

This is why register layout matters more than register count. One function code 03 request can return up to 125 contiguous holding registers, so 30 points packed into one block is a single transaction while the same 30 points scattered across a 2000 register span can be a dozen. If the map is fixed by the vendor you are stuck with the layout you were given, and it constrains your scan rate before you write a line of logic.

BACnet gives you two ways out. ReadPropertyMultiple batches properties across objects in one request, and a COV subscription pushes an update only when Present_Value moves past COV_Increment, which makes network load a function of how much the plant is doing rather than how many points you drew. The catch is that subscriptions carry a lifetime and have to be renewed. When one lapses and nothing resubscribes, the point does not throw an error, it simply stops changing. On MS/TP the ceiling is token rotation time, set by baud rate, the number of masters, and the Max_Master value. Max_Master left at its default of 127 on a segment with eight devices means every token holder polls for 119 addresses that will never answer.

Decide the update rate per class of point before you build the point list. A trend that reports every fifteen minutes and a control loop feedback that has to land inside a five second scan are different network problems, and treating every point as though it needs the fast rate is the usual reason a system cannot keep up with itself.

Writing Is Where the Two Diverge Most

Reading is the easy half. BACnet has arbitration built into the object model: commandable objects carry a Priority_Array with 16 levels, every write takes a level, and the highest active level wins. Writing NULL at your level relinquishes it, and control falls through to the next active level or to Relinquish_Default when all sixteen are empty. Level 1 is manual life safety, level 2 automatic life safety, level 6 is reserved for minimum on and off timing, and by convention automation logic writes at 16 while operator overrides sit at 8. The practical consequence is that two systems can command the same output without fighting, and also that a point left commanded at priority 8 by a system decommissioned years ago will quietly override yours forever. You can read the Priority_Array and see exactly which level is holding it.

Modbus has nothing equivalent. A write to a holding register is an overwrite, last writer wins, with no record of who wrote it and no mechanism to release it. The protocol assumes a single master per serial segment, and over TCP nothing prevents several masters from writing the same register. The symptom is a setpoint that oscillates between two values with no fault reported anywhere.

Two device level behaviors are worth confirming before you design any write path. Some devices accept a value into a staging register and apply it only when a separate enable or commit register is written, so the write reports success and nothing happens. Others store setpoints in EEPROM with finite write endurance, which a supervisory loop rewriting the same value every scan will eventually consume. Write on change rather than on schedule, and read back to confirm instead of rewriting to be sure.

Failure Modes to Design Around

The two protocols do not fail in the same way, and recognizing the signature is most of the diagnosis. The ones worth designing around:

• BACnet: device instance numbers have to be unique across the entire internetwork, not just the local subnet. Two devices shipped with the same factory default both answer Who-Is, and the supervisor binds to whichever replies first. The symptom is a device that intermittently displays another device's points.
• BACnet: discovery depends on broadcasts, and routers do not forward them. Crossing subnets requires a BBMD on each subnet with matching Broadcast Distribution Tables, or Foreign Device Registration with a lifetime that has to be renewed. A BDT edited on one side only produces discovery that works in one direction and not the other.
• BACnet: network numbers must be unique per network segment. A duplicate network number on two routers produces routing loops and devices that appear and disappear without any device level fault.
• BACnet: MS/TP trouble is usually physical rather than logical. Missing or incorrect bias and termination, a shield grounded at both ends, or a stub hung off the daisy chain shows up as intermittent token loss rather than a clean failure, which is why it gets misdiagnosed as a driver problem.
• Modbus: word order for anything wider than 16 bits is not specified by the protocol. Big endian, little endian, byte swapped and word swapped variants all exist in the field, sometimes selectable in the device and sometimes not mentioned in the documentation at all.
• Modbus: signed against unsigned. A 16 bit register holding a small negative value reads as roughly 65,000 when interpreted as unsigned, and a genuine value near full scale reads as a small negative when interpreted as signed.
• Modbus: address base. Documentation that says 40001 usually means offset 0 of function code 03, but not always, and some vendors publish the raw offset instead. The classic symptom is an entire map that is off by one.
• Modbus: unit ID. Native TCP devices frequently ignore it, but when a gateway is in the path it is the serial slave address. Copy a working map without changing the unit ID and twelve meters behind one gateway all return the same device's data.
• Modbus: register maps change with firmware revision. The same model two revisions apart can move a block or change a scale factor, and nothing in the protocol announces it. Record the firmware revision alongside the map.

Know What You Inherit, and Prove It on a Bench

The protocol is cheap and the mapping is what you own. A BACnet integration keeps its meaning in the devices, because object names, units and descriptions live on the equipment, so a replacement supervisor rediscovers most of what the previous one knew. A Modbus integration lives entirely in your mapping layer: offsets, data types, word order, scale factors and engineering units exist only in the configuration you built and the PDF you were handed. Replace that configuration and the work is done again from nothing. Hiring reflects the same asymmetry, since BACnet troubleshooting is a mainstream controls skill while an undocumented register map is a per device puzzle that general experience does not shorten. Treat the point list, the register map and the vendor documents as source: export them, keep them under version control with the station, and keep a local copy of the vendor PDF, because the vendor's download page will eventually only carry a later revision.

Most of the rest can be settled before you commit, for the cost of one device and an afternoon. Put one unit of the equipment in question on a bench with the supervisor you intend to use and work through it in order. A useful bench sequence looks like this:

• For BACnet, run a Who-Is from the same subnet, read the Device object's Object_List, and check whether Object_Name, Units and Description are actually populated rather than left at defaults.
• Check for proprietary extensions. Object type identifiers of 128 and above and property identifiers of 512 and above are vendor specific, and a supervisor without the vendor's definitions will show them as raw numbers or not at all.
• For Modbus, read every block you intend to use with a generic master before you build any mapping, and compare each value against the device's own display or a known reference.
• Force a real value to change at the device and watch it move on the wire in the direction and magnitude you expect. A static reading hides sign, scaling and word order errors completely.
• Write one point exactly the way production will write it, then read back the Priority_Array on BACnet, or power cycle the device and read the register again on Modbus, to confirm the write actually persisted.
• Time a full poll of the real point count at the real baud rate or the real network, not a three point sample. A map that polls comfortably at five points can miss its scan window at three hundred.
• Disconnect the network or the serial lead and watch what the supervisor reports and how long it takes to report it. That is what the failure will look like at two in the morning, and a bench is a much cheaper place to learn it.