What is a BMS? A plain-English guide to building management systems

Walk into the plant room of any decent-sized office, hotel or hospital and you’ll find a few grey panels full of controllers, terminals and cabling. That’s the building management system, or BMS. It’s the thing that decides when the boilers fire, how warm the air coming out of the vents should be, and who gets an alarm when a pump packs up at 2 a.m.

You’ll also hear it called a BEMS (building energy management system) or BAS (building automation system). In the UK people use the three names more or less interchangeably.

What it looks after

On a typical commercial site the BMS runs the heating (boilers or heat pumps, pumps, mixing circuits), the hot water (calorifiers and circulation pumps), the ventilation and air conditioning (air handling units, fan coils, VAV boxes, extract fans) and the cooling (chillers and their pumps). Depending on the building it might also handle lighting, metering, leak detection and generator monitoring.

What it doesn’t do is replace life-safety systems. The fire alarm, emergency lighting and gas safety controls are separate systems in their own right. The BMS watches them and reacts. For example, when the fire alarm goes off it shuts down the air handling units. But it isn’t the thing keeping anyone safe.

How it’s put together

Whatever the brand, nearly every BMS is built in the same four layers.

At the bottom are the field devices: sensors measuring temperature, pressure, humidity and CO₂, plus the actuators that move valves and dampers and the relays that start fans and pumps.

Those are wired to controllers. Some are big plant controllers in a panel running an entire AHU or boiler house. Others are small unitary controllers sitting on each fan coil unit.

The controllers talk to each other over a network, these days usually BACnet over IP or the older RS-485 BACnet MS/TP, with Modbus, LON or KNX turning up too.

On top sits the supervisor, or front end. That’s the software people use: graphics, alarms, trend logs and time schedules.

One principle matters more than any other here. The controllers should run the plant on their own. If the network goes down or the front-end server dies, the boilers and AHUs should carry on with their last instructions. The supervisor is there for people to look at and adjust things. It isn’t there to do the controlling.

The control loop

Almost everything a BMS does is some version of the same idea. A sensor measures something, say the supply air at 16 °C. The controller compares it with what it should be, say 18 °C. It then moves something to close the gap, opening the heating valve a bit further, and then it measures again. That’s a closed control loop, and most HVAC loops use PID control to decide how hard to push. There’s a separate guide on how PID loops work and how to tune them.

Wrapped around those loops are the rules that make plant behave sensibly:

• time schedules and optimum start
• interlocks, like no heating unless the fan is proven running
• frost protection
• alarm handling

All of that together is the control strategy, and it should be written down in the O&M manual. If nobody can find it, that’s usually the first sign a site has been neglected.

Points

Everything the BMS knows about is called a point. Temperatures and pressures come in as analogue inputs. Run and fault signals come in as digital inputs. Valve and damper positions go out as analogue outputs, and start/stop commands as digital outputs. On top of those there are software points such as setpoints, schedules and calculated values.

A medium-sized office can easily have a few thousand points, all listed in the points schedule. When an engineer takes over a site, the points schedule and the control strategy are the first two documents they’ll ask for.

Open versus proprietary

Older systems were often proprietary: one manufacturer’s controllers, network and front end, and in practice only that manufacturer’s approved partners could touch them. Most specifications now ask for open protocols, mainly BACnet, so kit from different manufacturers can share one front end. That’s a big part of why integration platforms like Niagara are so widespread.

“Open” has its limits, though. Programming tools, software licences and passwords can still tie a site to one contractor. It’s worth asking about those before you sign anything.

Why a good BMS matters

A well-run BMS is one of the cheapest ways to cut a building’s energy bill, because it decides when plant runs and how hard. The biggest wins are rarely clever. They come from basics like these:

• Schedules match how the building is actually used.
• Nothing has been left in hand after a repair.
• Heating and cooling aren’t fighting each other in the same room.
• Setpoints are sensible, not whatever happened to stop the last complaint.

It also makes fault-finding much faster. A trend log showing exactly what a valve, a sensor and a setpoint did at 3 a.m. beats any amount of guessing.

Spotting a neglected system

You can usually tell quickly. Nobody knows what the logic is supposed to do. The alarm list has hundreds of entries that everyone has learned to ignore. The only copy of the controller programs is on the controllers themselves. Half the plant is in override and nobody remembers why. And at least one sensor has been reading a few degrees out for years.

A well-looked-after BMS is the opposite. The strategies are up to date, the alarms mean something, backups are kept off site, and the graphics actually match the plant.

If you’re new to all this, the BMS glossary will help with the jargon, and how to become a BMS engineer covers getting into the trade. To see how the pieces come together on a real bit of plant, the AHU control strategy guide is a good next read.