IBMS
IBMS — Integrated Building Management System
IBMS explained: how an integrated building management system unifies HVAC, lighting, access, CCTV, energy and fire status into one operating picture.
What IBMS means
IBMS stands for integrated building management system. It is an integration layer, not a single brand of controller. It gathers data from the BMS and from other building systems, normalises that data into a common model, and gives operators one place to see status, acknowledge alarms and issue commands. The BMS still controls the plant; the IBMS coordinates across systems and reports on the building as a whole. That distinction keeps the architecture honest and prevents an integration project from becoming an unplanned controls replacement. That boundary also matters commercially: an IBMS should not become a way to replace a working BMS without a separate decision. The IBMS should be priced and scoped as an integration service, not as a licence with unspecified engineering. A clear scope names the systems, the data, the rules and the operator roles the platform must support.
- Integration layer above the BMS
- Common data and alarm model
- One operator view across systems
- BMS keeps plant control
Subsystems in one model
A typical IBMS scope includes HVAC and plant, lighting, shading, access control, CCTV, intrusion alarm, parking, public address, lifts, energy meters, guest-room control and fire status. Each subsystem keeps its own controller and its own safety responsibilities. The IBMS reads status, writes permitted commands and links events across systems. The integration matrix should state, for every subsystem, which data is read-only, which is writable, and which vendor remains responsible for the equipment. That matrix is the practical definition of the project. Every subsystem should have a named owner, an interface document and a tested failure mode. Read-only points are not a limitation; they are a boundary that protects the subsystem's safety and warranty. The matrix should also record the data direction, the update rate and the behaviour when the link is lost, because those three details decide whether the operator can trust the screen.
- HVAC, lighting and shading
- Access, CCTV and intrusion
- Parking, lifts and public address
- Energy, guest rooms and fire status
Alarms that operators can use
An IBMS collects alarms from systems that were never designed to share them. Without rationalisation, the result is a wall of noise. A workable alarm model normalises descriptions, removes duplicates, ranks events by consequence, routes them to the right role and records acknowledgement and escalation. Chilled-water failure, a door forced open and a meter communication fault should not arrive with the same priority. The alarm philosophy is agreed during design, tested during commissioning and reviewed after the first operating season. The operator should be able to see why an alarm was raised, not only that it exists; context is part of the alarm. Alarm counts and repeat events should be reviewed, because a noisy system trains operators to ignore it. A useful metric is how many alarms require action; if most are nuisance events, the alarm model needs work, not more screens.
- Normalised alarm descriptions
- Ranking by consequence
- Routing, acknowledgement and escalation
- Post-season alarm review
Interlocks and cross-system logic
The value of an IBMS appears when systems act together. Access opening a room can bring lighting, HVAC and CCTV to the right state. A parking entry can raise lighting in the approach zone. A fire alarm can release doors and stop air-handling units, while the fire panel retains authority over life-safety functions. Interlocks should be configured as visible rules, not hidden wiring between vendor controllers. Each rule needs a trigger, a condition, an action, a timeout and a failure behaviour. Testing proves the rule works, and the audit trail shows who changed it. A rule that cannot be tested should not be deployed, because the building will eventually depend on it. Cross-system rules should fail in a defined direction, usually leaving the affected subsystem in its local safe state. Rules also need an owner and a review date; otherwise they accumulate and contradict each other.
- Access, lighting and HVAC linkage
- Parking and façade lighting
- Fire mode with panel authority
- Visible rules with audit records
Operator experience
An IBMS is judged at 02:00, when one person is on shift and something is wrong. The interface should show what changed, where it is, what it affects and what to do next. Role-based views keep the operator, the engineer and management on the same data at different depths. Floor plans, trends and alarm history should be reachable without hunting through menus. Mobile access helps a small team cover a large site. Training and documentation are part of the product, not an afterthought. A useful test is a person unfamiliar with the project completing a routine task without asking for help. Views should be designed around roles and tasks, not around the vendor's menu structure. The interface should also distinguish a measured value from a stale value, because a screen that looks live but shows old data is worse than no screen.
- Clear hierarchy and drill-down
- Role-based views and permissions
- Trends, floor plans and alarm history
- Training and operator documentation
Open protocols and local-first control
IBMS depends on interfaces. BACnet/IP and Modbus are common for plant and meters, KNX for lighting and room control, DALI for luminaires, APIs and ODBC for business systems, and dry contacts for equipment that offers nothing else. The platform should run on the local network, keep history on site and treat remote access as an option with authentication and logging. Network segmentation between OT and IT is part of the design. The owner should be able to change integrator without losing the point model, the graphics and the data. Documentation should include the network diagram, the point model and the licence position, so the owner is not locked to one supplier. Remote access should be revocable without disrupting local operation. Local-first does not mean isolated: it means the building keeps running when the wide-area link does not, and the operator can still reach the data on site.
- BACnet, Modbus, KNX and DALI
- APIs and ODBC for business systems
- Local servers and history
- Segmentation and audited remote access
Architecture, networks and cybersecurity
An IBMS is a network project as much as a controls project. The integration server, gateways and operator clients sit on a segmented network; building services should not share a flat network with office IT. A common design uses a dedicated OT VLAN, a firewall between OT and IT, and controlled remote access through a VPN or broker with multi-factor authentication. Time synchronisation matters because alarms and trends from different systems must line up; without a consistent time source, event correlation becomes guesswork. History storage, backup and restore should be specified, including how long data is kept and who can export it. User accounts should come from a directory where possible, with role-based permissions and an audit log for commands and setpoint changes. Remote access should be revocable without disrupting local operation. Cybersecurity is not a product feature added at the end; it is part of the integration architecture.
- OT and IT segmentation
- Consistent time synchronisation
- Role-based accounts and audit logs
- Backup, retention and remote access policy
Delivery stages and common failure modes
Delivery follows a sequence. An audit confirms the systems, versions and available interfaces. An integration matrix defines read and write rights, owners and boundaries. A point model gives every item a name, unit, permission and alarm priority. Gateways and interfaces are configured and tested in the factory where possible, then on site. Commissioning moves from point-to-point checks to cross-system rules and failure tests, and ends with a soft-landing period in which operators use the system under real conditions. Documentation includes the network diagram, point model, integration matrix, test records, licence position and recovery procedure. Common failure modes are predictable: an API that was assumed but never tested, alarm floods that hide the real event, stale data from a gateway, duplicate point names, time drift between systems, and a licence model that prevents the owner from adding points without the original supplier.
- Audit and integration matrix
- Point model and gateway testing
- Cross-system and failure tests
- Soft landing and as-built records
IBMS integration matrix
18 rows| Subsystem | Typical interface | IBMS role | Boundary |
|---|---|---|---|
| HVAC and BMS | BACnet/IP, Modbus, 0–10 V | Schedules, setpoints, alarms, trends | BMS keeps plant control |
| Lighting | DALI, KNX, relays | Scenes, occupancy, fault status | Lighting controller keeps local control |
| Shading | KNX, Modbus, dry contacts | Solar and wind rules, scenes | Motor or façade controller keeps limits |
| Access control | API, OSDP via controller, dry contacts | Door status, release, event linkage | Access system keeps permission logic |
| CCTV | ONVIF or vendor API | Camera map, event linkage, health status | VMS keeps recording and retention |
| Intrusion alarm | Dry contacts, API | Zone status, arm/disarm events | Alarm panel keeps detection logic |
| Fire alarm | Dry contacts, supervised inputs | Status, pre-alarm and linkage only | Fire panel keeps life-safety authority |
| Smoke control | Dry contacts, API | Status and damper position | Smoke control system keeps its sequence |
| Parking | API, TCP/IP | Entry status, space counts, exceptions | Parking system keeps barrier control |
| Public address | API, dry contacts | Zone status, scheduled messages | PA system keeps emergency override |
| Lifts | Dry contacts, API | Status, fault and alarm signals | Lift controller keeps motion safety |
| Energy meters | Modbus, M-Bus via gateway, pulses | Sub-metering, baselines, allocation | Metering system keeps tariff data |
| Water and gas meters | Modbus, M-Bus via gateway, pulses | Consumption trends and leak alarms | Utility metering keeps billing data |
| EV charging | OCPP, vendor API | Session status, load control, exceptions | Charger operator keeps billing and safety |
| UPS and generators | SNMP, Modbus, dry contacts | Run hours, fuel status, transfer events | Power system keeps transfer logic |
| Guest rooms and PMS | API, ODBC, RCU interface | Check-in/out events, room status, energy limits | PMS keeps reservations and billing |
| Visitor management | API, dry contacts | Pre-registration status, door events | Visitor system keeps identity checks |
| Building analytics and FDD | Historian API, database export | Fault detection, baselines, performance reports | Analytics layer keeps its models |
Project images
3 images
Frequently asked
01What is an IBMS?
An integrated building management system connects building subsystems into one data model, alarm list and operator view. It adds cross-system rules and reporting while each subsystem keeps its own controller and safety responsibilities.
02What is the difference between IBMS and BMS?
A BMS controls and supervises building services, especially HVAC and plant. An IBMS sits above it and integrates the BMS with access, CCTV, parking, energy, guest rooms and fire status. The BMS remains the control layer.
03Do we have to replace our existing BMS?
No. The usual approach is to integrate the existing BMS through BACnet, Modbus or another available interface. Replacement is a separate commercial decision, not a precondition for an IBMS.
04Can an IBMS run without the internet?
Yes. The integration platform and control logic should run on the local network, with history stored on site. Internet access is optional for remote support and reporting.
05Which protocols does an IBMS support?
Common interfaces include BACnet/IP, Modbus RTU and TCP, KNX, DALI, APIs, ODBC and dry contacts. The actual set depends on the installed equipment and the gateways selected for the project.
06How are fire alarms handled?
Fire remains a separate life-safety system. The IBMS reads status and pre-alarm signals through dry contacts or supervised inputs and may trigger defined linkages, but the fire panel retains authority at all times.
07How are alarms prioritised?
Alarms are normalised, deduplicated and ranked by consequence, not by source system. The alarm philosophy defines priority, routing, acknowledgement and escalation, and is tested during commissioning.
08Can an IBMS cover multiple buildings?
Yes. Local controllers can run each building while a central layer consolidates alarms, energy and reports. The design should define what stays local and what depends on the network between sites.
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.