What is the difference between BMS, BAS and an IoT platform?

Two of these three acronyms mean almost the same thing, and the third is something else entirely. BMS (building management system) and BAS (building automation system) describe one category: the controllers, networks and supervisory software that automate and supervise building services such as HVAC, lighting and plant. Suppliers and regions use the terms interchangeably, so there is no technical difference to read into the acronym.

An IoT platform is a different kind of product. It is software, usually cloud-hosted, that connects large numbers of devices, collects their data and makes it available to applications. What it typically does not provide is the engineered control sequences, equipment protection and local resilience that a BMS exists to deliver.

The comparison worth making, then, is not BMS against BAS but automation against data platform, and the real question is where each function should live.

One category, two labels

Where anyone does draw a distinction, "BAS" puts the stress on the automation itself, with controllers running sequences in the field, while "BMS" leans towards the supervisory layer operators use. In tender documents and supplier literature the two overlap almost completely. We use BMS throughout.

The label matters far less than the architecture of the particular system in front of you. You need to know which control functions run in local controllers and carry on if the supervisory server or network is lost, which depend on a central server on site, and which rely on an external or cloud service. You also need to know which protocols the system uses internally and at its boundaries; BACnet is common, alongside Modbus, KNX and proprietary buses.

What an IoT platform actually does

An IoT platform handles device connectivity and management: onboarding, identity, firmware updates and health monitoring for sensors and gateways. It ingests data over protocols such as MQTT or HTTPS, stores and processes it, often in time-series databases with rules engines, and exposes it to applications through APIs and integrations.

Those are valuable functions, particularly for adding monitoring at scale, such as wireless sensors across a portfolio, or for drawing data from many systems into one place. But a platform that can send a command to a device has not thereby taken on the engineering responsibility for sequences, interlocks, safe states and operator overrides. If those functions move out of the BMS, someone has to design, test and own them in their new home.

Messaging is not meaning

MQTT, standardised by OASIS (version 5.0 is the current specification), is a lightweight publish/subscribe protocol. Devices publish messages to named topics on a broker, and applications subscribe to the topics they need. It offers three delivery levels, at most once, at least once (with duplicates possible) and exactly once, and the right level should be chosen deliberately for each data stream.

What MQTT does not define is what a message means. A successful exchange does not tell an application which room a value belongs to, what its unit is or whether the sensor can be trusted. Topic structure, payload format, asset identifiers, timestamps, quality flags and permissions all still need designing, and the same is true of any transport protocol.

Side by side

The table describes typical products. Individual offerings vary, and some suppliers combine both roles, which is exactly why a demonstration on your own use case tells you more than a category label.

When the two belong together

An IoT platform often makes sense alongside a BMS when you need monitoring the BMS does not cover, such as wireless sensors in storerooms, risers or tenant areas; when data from several systems or buildings has to come together in one place; or when applications from different suppliers need consistent access to the same data. It is a weaker choice when the real need is better control of plant the BMS already manages. Improving the BMS configuration is usually the more direct route.

Putting suppliers to the test

The fairest comparison gives every bidder the same scenario and asks each to show five things:

• the data path from sensor to application, with the protocol at each step;
• where any control decision is made, and who engineers it;
• what happens on loss of the internet, of the platform and of a sensor;
• how devices are onboarded, updated and retired;
• the recurring costs per device, site or data volume.