BMS · IBMS
BMS vs IBMS — Supervision or Integration?
A BMS supervises building services; an IBMS integrates them with security, fire, lifts, parking and energy into one operating picture. Where the line falls.
Quick answer
A BMS supervises building services such as HVAC, lighting and metering. An IBMS integrates the BMS with security, fire, lifts, parking and other systems into one platform with shared alarms, cross-system interlocks and consolidated reporting. The difference is integration depth and governance, not the number of screens.
Scope: building services versus the whole building
A BMS normally starts with HVAC: chillers, boilers, air handling units, terminal units and the meters that show what they consume. Lighting, shading and sometimes access events are added because they share the same operator. An IBMS widens that scope to the rest of the building: security, CCTV, fire alarm status, lifts, parking, guest rooms and external systems. The distinction is not prestige. It is the number of interfaces the operator has to reconcile and the number of events that must be judged together. A BMS can be complete for its scope and still leave the control room with four screens. The operator's job is to decide, and every extra interface makes that decision slower.
Integration depth: gateways versus a common model
Many BMS projects integrate by gateway: each subsystem keeps its own model, and the BMS maps selected points into graphics. That works for monitoring, but cross-system logic becomes brittle because every rule depends on a vendor's naming. An IBMS is expected to normalise points into one object model, with identity, units, quality and history, then apply one alarm model and one interlock engine. The difference shows up during change: renaming a point in one system should not break a rule in another. It also shows up in reporting, where the same metric must mean the same thing across subsystems. A common model also makes a new subsystem cheaper to add, because the naming and alarm rules already exist.
When an IBMS earns its place
An IBMS earns its cost where decisions cross system boundaries: a fire event that must release access, a tenant entry that should start HVAC and lighting, a campus that needs one energy view, a control room that supervises several buildings. It also helps where accountability is distributed, because a common audit trail makes each action traceable. A single building with a small plant, one operator and few third-party systems usually does not need that machinery; a well-scoped BMS with open exports is easier to run. The test is not building size but the number of coupled decisions. If a building has one plant room and one team, an IBMS can add cost without adding a decision anyone needs to make.
The delivery risk is scope, not technology
Most IBMS problems are scope problems. Integrating everything produces shallow integrations, unclear responsibilities and an alarm list nobody trusts. Start with a subsystem matrix: rows for each system, columns for monitoring, control, alarms, interlocks and reporting. Mark what is out of scope and why. Assign the interface to one party, name the protocol, and define an acceptance test for each row. That document is more valuable than a platform demonstration, because it survives into commissioning and handover. It also lets the client compare proposals without comparing slide decks. Write it before the tender, not after the kick-off meeting, and keep it alive through design changes.
- Rows: every subsystem, including those explicitly excluded
- Depth: monitor, control, alarm, interlock or report
- Interface: protocol, gateway owner and point map
- Acceptance: the test that proves each row
BMS and IBMS compared
6 rows| Dimension | BMS | IBMS |
|---|---|---|
| Primary scope | Building services: HVAC, lighting, metering | Whole building: services plus security, fire status, lifts and parking |
| Typical subsystems | Plant, AHUs, terminals, meters, lighting | BMS plus access, CCTV, fire alarm status, lifts, parking, guest rooms |
| Data model | Points mapped per subsystem | One normalised object model across systems |
| Cross-system logic | Limited; often within one subsystem | Configured interlocks across subsystems |
| Typical operator | Building technician and energy manager | Control-room team, facility management and management reporting |
| Main risk | Fragmented screens and duplicate alarms | Scope creep and shallow integrations |
Project images
3 images
Frequently asked
01Is an IBMS just a dashboard on top of a BMS?
No. A dashboard displays data; an IBMS owns the integration model, alarm routing, interlocks and audit trail. If it only reads screenshots from other systems, it is a viewer, not an integration platform.
02Can an IBMS replace the BMS?
It usually does not. The BMS remains the supervision layer for building services, and the IBMS integrates it with other systems. Replacing a working BMS to gain integration is rarely the shortest path.
03Must all subsystems come from one vendor?
No. Open protocols and gateways allow mixed vendors. What must be single is the data model and the interface responsibility; otherwise nobody owns the translation.
04Is IBMS only for large buildings?
Mostly, because value grows with the number of systems and operators. A small building with one plant and one team can often meet its needs with a BMS and open exports.
05What is the first step?
Build a subsystem matrix with monitoring, control, alarms, interlocks and reporting columns. That exposes the real scope before a platform is selected.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.