BMS and AI — why building automation needs a semantic layer

BMS and AI: a difference in operating logic

criterion	BMS	AI-based solutions
operating logic	programmed rules and scenarios	patterns learnt from data, prediction of events
data scope	mainly building sensors	building and external data, e.g. weather, occupancy, tariffs
response	to events and alarms	in advance, based on a forecast
decision	the operator sets the rules, the system executes them	the system recommends or changes settings within limits set by the operator
scale	a single building or campus	a portfolio of buildings, if the data are comparable

The last row is the key one. Analysis of a building portfolio works only when data from different buildings can be compared.

The layer that is rarely discussed

In many buildings the measurement points in the BMS carry names given by the installer, different in each building and understood only by the service technician. The same supply-air temperature sensor has a different name in every building in the portfolio. The model does not know what a given point measures, where it is located or which device it is linked to.

That is why, before analytics, a semantic layer is needed: a shared vocabulary of points, devices and zones, data owners and definitions of measures. The market has open standards for describing building data, such as Brick and Project Haystack. It is the same logic we apply in semantic transformation, that is, organising a company’s names, processes and data so that people, language models and board reports understand them the same way.

What combining BMS and AI delivers

• Condition-based maintenance. Inspections and servicing planned on the basis of how equipment behaves, not only the calendar.
• Optimised consumption. Control of heating, cooling and lighting according to actual occupancy and outside conditions.
• Comparing buildings. Identifying buildings and installations that consume more than comparable ones.
• Reporting. Energy consumption data assigned to buildings, zones and installations, ready for reports to the owner and for environmental reporting.

Only a before-and-after measurement in a specific building confirms the scale of the effect.

How to start: a checklist for the board

1. Data inventory. What data the BMS collects, in what format, and whether they can be exported.
2. Point vocabulary. Consistent names for measurement points, devices and zones, at least in the pilot building.
3. Business objective. Energy consumption, number of failures, user comfort, reporting; one objective to start with.
4. Pilot building. One building or one installation, for example ventilation and air conditioning.
5. Baseline. A measurement before the change, using data from the system.
6. Limits of automation. What the system may change by itself, what it only recommends, and who is responsible for the result.
7. Delivery partner. An integrator who knows both building automation and data analytics.

What has changed since first publication

• We have removed the comparison of percentage savings for BMS and AI and the reported pilot results; they had no stated sources.
• We have added a section on the semantic layer and on open standards for describing building data.
• We have made clear that decisions on how installations operate are taken by a person, and that the limits of automation are set before implementation.