Everything on screen is green. Is the BMS really controlling the building?

Command, status and outcome are three different things

For a fan, the display can show an ‘on’ command, a run signal from the variable speed drive and a measured airflow rate. These parameters are related but not interchangeable. Even structured data models distinguish between commands, sensor readings and setpoints. ¹

Consider a hypothetical case. The BMS sends a command and the drive reports that the motor is running, but a damper in one zone is closed. The first two signals are correct, yet the required ventilation is not being delivered there.

Sufficient confirmation should therefore be defined for each function. A motor signal confirms one thing, a pressure sensor another, and a zone airflow measurement something else. There is no need to install every possible sensor everywhere. What matters is understanding the uncertainty left by the selected set.

Opening a valve does not mean transferring heat

In a water circuit, a 100% valve command is not a measured flow rate. A lack of results may be due to the mechanical position of valves, pump condition or incorrect signal mapping.

We would check the chain step by step: what the controls requested, what the actuator confirmed and how the physical parameters changed. That is the difference between watching an interface and verifying system operation. HVAC commissioning involves confirming that actual operation meets the design criteria, not merely that no fault messages are present. ²

However, a fault should not be diagnosed from a single instantaneous temperature difference. After a command, a justified response time must be allowed for the particular circuit.

A good BMS can do more than display information

A BMS need not be a passive screen. It can coordinate operating modes, schedules, setpoints and starts. For example, PNNL discusses optimum start and demand-based pressure reset as building control functions — without requiring a separate ‘AI’ purchase just for these actions. ³

Problems arise when the contract lists screens and point counts but does not define how they should work together.

For an office, agreeing a sequence to prepare rooms before the working day is more useful than ordering another overview schematic. For a server room, it is a standby activation sequence. For a chiller plant, it is confirmation of the required flow rates before enabling a unit, in accordance with its requirements.

What the operations team needs to see

On the operating screen, I would show not only equipment status but also the control mode, active setpoint, command source and data freshness. If a parameter is not updating, it should not be presented as current simply because its last value was normal.

There must also be a clear route to the cause: why a unit stopped, which interlock is active and what the operator needs to do. These are proposed interface requirements, not default features of every BMS.

For the client, the outcome is not a larger number of coloured elements. It is the ability to distinguish an executed command from an unexecuted one and locate a problem more quickly.

A BMS is valuable when the entire chain can be traced: task → action → confirmation → actual outcome in the building.