BACnet and Modbus explained

BACnet and Modbus are the two protocols you are most likely to meet in building automation. BACnet was designed for buildings and describes equipment in a structured, self-explaining way; Modbus is an older, simpler industrial protocol that moves numbered registers and leaves their meaning to a vendor's documentation. Most buildings use both, and knowing the difference saves a great deal of trouble at integration time.

A protocol is the agreed language that controllers, meters, drives and software use to exchange data. When every device in a building speaks an open protocol, the owner can mix equipment from different makers and choose who services the system. When devices speak only proprietary languages, every connection needs a custom gateway and every change goes back to one vendor.

How BACnet works

BACnet was developed for building automation and is published by ASHRAE as Standard 135; it is also an ISO standard. Its central idea is that every device describes itself as a set of objects, and every object has properties.

• A supply air temperature sensor appears as an Analog Input object, with properties such as Present Value, Units, Description and Status Flags.
• A fan start command appears as a Binary Output object.
• A setpoint stored in a controller appears as an Analog Value object.
• Schedules, calendars, trend logs and notification classes are objects too.

Devices then use standard services to work with those objects: read a property, write a property, subscribe to changes of value, report alarms and events, discover what devices and objects exist on the network. Because objects carry their own names and units, a workstation can find a new controller and understand much of what it holds without a separate map.

Commands in BACnet go through a priority array. Several sources can write to the same output at different priorities, such as a manual operator override, a demand-limiting routine and the normal sequence, and the highest-priority active command wins. Releasing an override returns control to the next level down. Overrides that are never released are one of the most common reasons a BACnet building does not behave as designed.

How Modbus works

Modbus dates from the late 1970s, when it was created for programmable logic controllers. It is simple, widely supported and still common in meters, variable frequency drives, generators, boilers, chillers and UPS units. One device acts as the client (traditionally called the master) and asks; the others act as servers (slaves) and answer. A server never speaks unless asked.

Data in Modbus lives in four tables:

• Coils: single bits that can be read and written, such as a run command.
• Discrete inputs: single bits that can only be read, such as a status contact.
• Input registers: 16-bit values that can only be read, such as a measured current.
• Holding registers: 16-bit values that can be read and written, such as a setpoint.

A register is just a number at an address. Whether register 3 is a voltage in tenths of a volt, part of a 32-bit energy total or a fault code is defined only in the maker's register map. Integrators routinely deal with scaling factors, values split across two registers, word-order differences and the old convention of numbering holding registers from 40001 while the protocol itself counts from zero. Modbus RTU runs over RS-485 serial wiring; Modbus TCP runs over Ethernet.

Comparing the two

The clearest difference is in what a device tells you about itself. A BACnet device can be asked what it contains and answers with named, typed objects. A Modbus device answers only the register numbers it is asked for, and the meaning lives in a document.

They also differ in how data moves. Modbus clients poll: they ask each device for the same registers over and over, and a busy serial network can only poll so fast. BACnet supports polling too, but also lets a client subscribe to a value so that the device reports only when it changes, which keeps traffic down and updates quick.

Networks and wiring

In most buildings, BACnet/IP runs on the Ethernet network between supervisory controllers and workstations, while field controllers hang off serial trunks below them. BACnet MS/TP and Modbus RTU both use RS-485 wiring, and both suffer from the same installation mistakes.

Good RS-485 practice for either protocol:

• Run the trunk as a daisy chain from device to device. Avoid star wiring and long stubs.
• Use the shielded twisted-pair cable the device makers specify, and ground the shield as they direct.
• Terminate the two ends of the trunk, and only the two ends, and provide biasing where the devices require it.
• Give every device a unique address and set the same speed on every device on the trunk.
• Keep the number of devices and the trunk length within the makers' limits, and record the trunk on the drawings.

On the IP side, BACnet discovery relies on broadcast messages that do not cross routers by default, so multi-subnet systems need BACnet broadcast management devices or equivalent configuration. A newer option, BACnet Secure Connect (BACnet/SC), carries BACnet over encrypted connections and is worth asking about for new systems; our guide to cybersecurity for building automation explains why.

Specifying an open system

• Ask for each BACnet device's Protocol Implementation Conformance Statement (PICS), which lists the objects and services it supports, and prefer devices tested and listed by the BACnet Testing Laboratories.
• Require the device profile that fits each role, such as building controller, advanced application controller or operator workstation.
• For Modbus equipment, require the complete register map, with scaling and data types, as a submittal.
• Set a naming convention for devices, objects and points before programming starts. Our guide to BAS points and sequences of operation covers points lists.
• Require the owner to receive programming tools, licences, passwords and backups at handover.

How ehZee can help

We design building automation systems around open protocols, choose where BACnet and Modbus each fit, and specify the networks, gateways and documentation that make integration work. See our building automation system design service.

Common questions