Three protocols in one building: bringing BACnet, Modbus and S7 into a single system

Introduction

On a building automation project, the first problem is rarely technical — it is archaeological. The HVAC went in ten years ago, the meters were replaced three years ago, the lifts and the generator each have their own controller, and every batch was installed by a different contractor, in a different year, speaking a different protocol.

Then someone asks: "Should we just replace everything with one protocol?"

The answer is almost always no. Replacing working equipment to suit the system costs far more than making the system read the equipment. BACnet HVAC coexisting with Modbus meters is the norm, not the exception.

This article covers the real differences between the three protocols, and where things actually go wrong when they are mixed.

1. Three protocols, one sentence each

The middle row is the important one, and the whole of the next section is about it.

2. The risk with Modbus is not technical — it is that point list

A BACnet device can be discovered: connect to it and it will report which objects it has, what type each one is, and what units it uses. The system builds the screens from that.

Modbus has no such layer. What comes back is a number: the value at address 40001 is 235. Whether that 235 is 23.5°C, 235 kW, or a set of status bits is something the protocol has no idea about — the meaning lives entirely in the point list the manufacturer supplies.

So the situations that actually bite on site are these:

• The equipment still runs fine, but the original point list is lost
• The manufacturer shipped new firmware and the point list version no longer matches; the values read out look plausible but belong to a different measurement
• A point list exists, but only as a scanned PDF, and someone typed the fields into the system by hand

The second is the dangerous one, because nothing reports an error. Temperature reads 23.5°C, the screen looks entirely normal, and it is in fact another sensor's value.

So the first action when connecting a Modbus device is always to ask for the point list — and to ask which firmware version it corresponds to. A Modbus device without a point list is, from the system's point of view, unreadable: not because you cannot get numbers out of it, but because the numbers cannot be trusted.

3. BACnet has two physical layers — do not confuse them

BACnet commonly runs two ways. The names are similar; the cabling is not:

• BACnet/IP — over Ethernet, sharing the same cabling and subnet planning as any other network gear
• BACnet MS/TP — over an RS-485 serial bus, where segment length, termination resistors and unique station numbers all matter

MS/TP is very common in existing buildings, because it was the cheapest way to pull cable at the time. Its practical limits are the same family as Modbus RTU: the whole bus shares bandwidth, so the more devices hang off it, the slower a full polling cycle becomes. If someone asks for per-second updates, count the devices on that bus first.

4. S7: Siemens' own world

Siemens PLCs speak their own protocol, reading data blocks inside the PLC. It performs well and the data structures are clear — but you need the address layout from the PLC program first.

That is the same problem as the Modbus point list under a different name. The difference is that a PLC usually still has a manufacturer or an original contractor you can ask, whereas the company behind a ten-year-old Modbus meter has often long since closed.

5. The real difficulty in mixing: not protocols, but disconnection

Reading three protocols is a solved problem. What actually gets you out of bed at night is two other things.

Communication drops, and has to come back by itself

Site networks go down. A switch reboots, an RS-485 line gets knocked loose by other trades, a PLC power-cycles. None of that is exceptional; it is routine. The system has to reconnect on its own once the link returns, not wait for someone to hit refresh.

On our demo site we exercised exactly this on real hardware (the full description of the system is on SynBA Building Automation): control writes, reconnection after loss of communication, and loss and recovery of the PLC heartbeat fallback — with eight subsystems each given their own screens (built on photographs, floor plans and schematics), verified one by one against real devices. This behaviour cannot be validated in a simulator, because a simulator does not fail the way real equipment fails.

Heartbeat protection: what should the equipment do when the system dies

This is the most frequently skipped question with the most serious consequences. Suppose the supervisory server crashes. Should the PLCs on site hold their current state, or fall back to a safe one?

That has to be answered before the first line of control logic is written, and the answer has to live in the PLC, not in the supervisory server. If the server is down, protection logic running on the server is down with it. The usual approach is for the server to send a periodic heartbeat, and for the PLC to switch itself to a defined safe state when the heartbeat stops arriving.

6. What to ask during evaluation

If you are evaluating a building automation system, these questions are more useful than "how many protocols do you support":

1. Can all three protocols run on one server? If not, a handful of odd devices will cost you an entire second system
2. How are Modbus point lists imported? Typing in several hundred addresses and importing a file are different schedules
3. Has reconnection been tested? Ask "did you test it on real equipment", not "do you support it"
4. Which layer does heartbeat protection live in? If the answer is "the server", ask them to think again
5. What does the second site cost to deploy? If it costs the same as the first, the system has no reuse mechanism

The last point is how you tell a product from a project. A system built on device templates plus per-site configuration gets noticeably cheaper on the second building; one that is rewritten each time does not. SynBA is built on that principle.

Three questions we ask first

1. Which subsystems does the building already have, and who installed each? This sets the amount of archaeology
2. Can the Modbus point lists still be found? If not, schedule that work first — it takes longer than the programming
3. Do you want to watch, or to control? Reading status and issuing control commands are two different orders of safety requirement