What is the difference between an independent data layer and a BMS?

A building management system (BMS) runs the building. It monitors and controls heating, ventilation and air conditioning, often lighting and other plant too, through controllers that execute operating sequences close to the equipment. An independent data layer makes the building's information usable beyond the BMS: it collects data from the BMS and other systems, adds consistent identities and context, and serves it to applications. One is about safe, reliable control; the other is about access to information.

The two are meant to work together, and trouble usually starts when their roles blur. A data platform begins sending commands without anyone deciding who answers for the result, or a BMS supplier's dashboard is treated as though it were an open data layer.

Side by side

The US Department of Energy notes that building controls integration often involves multiple vendors, each with its own proprietary hardware, software and protocols, which leaves data in unconnected silos. A data layer is one way to reduce that fragmentation as far as information is concerned. It does not, by itself, change how the plant is controlled.

When the data platform starts giving orders

Some platforms offer "write-back": changing set points or schedules in the BMS, perhaps to run an optimisation or respond to a demand-response signal. That can be valuable, but it moves part of the control responsibility outside the BMS, and the questions that follow need answers before the feature is switched on.

Ownership is the first question. For every schedule, set point and alarm limit, one system has to be authoritative. Then consider conflict: if an operator and the platform change the same value, which wins, and how is that recorded? External changes should be confined to an agreed range. The BMS needs a defined behaviour when the platform stops responding, whether that is holding the last value, reverting to a default or returning to its local schedule. Every change should leave an audit trail of who changed what, when and why. And write-back functions should go through the same testing and commissioning as any other control function, however easily the software lets them be switched on.

The building must keep running on its own

If the data layer or its internet connection fails, the building should carry on regardless. Local plant control and essential alarms belong within the BMS and its own network. A portfolio dashboard must never become an accidental single point of failure for heating, cooling or ventilation.

Four questions for suppliers

Is the proposed integration read-only, and if not, which values are written and within what limits? How are conflicts between operators and external commands resolved and logged? What does the BMS do when the platform is unreachable? And who is responsible for the result of an external command? A supplier who cannot answer all four plainly has not yet designed the integration.