BMS
Building Management System (BMS)
What a building management system controls, which functions it owns, and where a BMS ends and a BAS or IBMS layer begins.
What a building management system controls
A BMS sits between the plant and the people who run it. On the plant side it connects chillers, boilers, air-handling units, fan-coil units, pumps, valves, dampers, meters and sensors. On the operator side it provides graphics, schedules, alarms, trends and setpoint changes. The scope is fixed by a point schedule: every sensor, actuator, status contact and alarm becomes a named point with a unit, a range, an alarm limit and an owner. If a device is not in the point schedule it is not in the BMS, even when it stands in the same plant room. A BMS is therefore a bounded system: broad enough to supervise plant, narrow enough for its responsibilities to be written down. The boundary matters more than the brand.
- Chillers, boilers, pumps and primary/secondary water circuits
- AHUs, FCUs, fresh-air and exhaust systems
- Schedules, occupancy modes and setpoints
- Alarms, trends, run hours and equipment status
- Metering and basic energy reporting
The functions a BMS actually owns
Control is only one part of the job. A working BMS also holds the operating logic that keeps equipment safe and the building usable: start/stop sequences, lead/lag rotation, valve and damper modulation, frost protection, setpoint schedules, alarm limits, run-hour counters and equipment fault reporting. It records what happened and when. It lets an engineer adjust a sequence without rewriting the whole programme. It makes the state of the plant legible to someone who is not in the plant room. These functions are unglamorous, but they are what an operator notices when a BMS is missing or poorly commissioned. A system that shows a polished dashboard but cannot explain why a chiller did not start has failed the operational test. The sequence of operations is the real specification; the graphics are only a view of it. Every function should have a defined trigger, a defined normal state and a defined failure state.
- Start/stop and lead/lag sequencing
- PID loops, valve and damper modulation
- Frost, high-limit and equipment protection
- Alarm limits, routing and acknowledgement
- Trend logs and run-hour records
Point naming and the point schedule
Point naming is an engineering decision, not a labelling detail. A useful convention carries the building, floor, system, device, function and signal type in a fixed order, for example B01-L03-AHU-02-SAT for supply air temperature. The name should be unique, stable and readable without the drawing. The point record should also hold the controller and channel, the signal type, the engineering unit, the normal range, the alarm limits, the trend interval, the writable flag and the responsible party. Inconsistent naming produces duplicate points, missed alarms and slow fault finding. A reviewed point schedule is the contract between the mechanical designer, the controls contractor and the operator, and it should be frozen before graphics or sequences are built. Where a point is calculated rather than measured, the record should show the formula and its inputs.
- Fixed order: building, floor, system, device, function
- Signal type, unit, range and alarm limits
- Controller, channel and responsible party
- Frozen before graphics and sequences are built
Alarms, trends and operator workload
An alarm is a request for action, not a log entry. Alarm rationalisation decides which conditions deserve an operator response, at what priority, with what deadband and delay, and which conditions are only events. A common planning range in building operations is a small number of actionable alarms per operator per hour during normal running; dozens usually mean the alarm design is measuring the wrong things. Group repeated plant alarms, suppress alarms from equipment that is intentionally off, and separate equipment faults from communication faults. Trends support diagnosis: sample temperatures and pressures at intervals that match the plant dynamics, log commands and setpoint changes with a user and a timestamp, and keep history long enough to compare seasons. The point schedule and the alarm schedule should be reviewed together.
- Priority, deadband and delay per alarm
- Group repeated alarms and suppress planned outages
- Separate equipment faults from communication faults
- Trend intervals matched to plant dynamics
- Time-limited, visible shelving instead of permanent suppression
Where a BMS ends
A BMS is not the whole building. It normally stops at plant and environmental control. Fire detection and suppression remain separate systems with their own approvals; the BMS may receive status and issue a controlled shutdown, but it does not replace the fire panel. Security, access control, CCTV and parking usually sit on their own platforms. Lifts, tenant billing and enterprise IT are outside the BMS scope. Lighting and shading may be integrated where the project asks for it, but they are not automatic BMS functions. The distinction between BMS, BAS and IBMS matters here. BAS describes the discipline and the control layer; BMS is the management view of that layer; IBMS is the integration layer above, joining the BMS with security, fire status, guest rooms and other systems. A BMS tender should not be asked to deliver an IBMS operating model.
- Fire alarm: status only; the fire system keeps authority
- Security and CCTV: separate platforms, event integration only
- Lifts, tenant billing and IT: outside BMS scope
- Lighting and shading: optional, project-specific
- BAS, BMS and IBMS: three different scopes
Testing, commissioning and handover
Commissioning proves the point schedule, not the sales brochure. Point-to-point testing checks every input against a known stimulus and every output against the field device. Sequence testing runs each plant mode, including failure and recovery: lead/lag changeover, frost alarm, valve failure, network loss, sensor out of range. Trend and alarm tests confirm that the right event reaches the right operator with the right priority. Schedules and overrides are tested at the boundaries, not only in the middle of the day. The handover pack should contain the as-built point schedule, network diagrams, controller and programme backups, alarm schedule, trend list, test records, operating instructions and training records. A witnessed site acceptance test, signed by the parties who will operate and maintain the system, is worth more than a folder of screenshots. Commissioning is also where sequence gaps appear: a mode that was never described, a sensor that was never installed, an interlock that only exists in the narrative.
- Point-to-point, sequence and failure testing
- Witnessed site acceptance test
- As-built points, backups and alarm schedule
- Operator training and signed test records
- Repeatable tests with expected results
Responsibilities and modernisation
Most BMS failures are boundary failures. The mechanical contractor owns the plant and its safeties; the controls contractor owns the controllers, sequences and graphics; the IT team owns the network and remote access; the operator owns setpoints and schedules after handover. A responsibility matrix should name each of these, including who supplies field wiring, who terminates sensors, who configures IP addresses and who approves a sequence change. In a modernisation, keep what is serviceable, replace what is not, and integrate the rest through open protocols. A staged cutover is usually safer: read-only integration first, control migration second, old system retirement last. The old system should remain available until the new one has passed its tests and the operators trust it. Documentation should include the as-built sequences, not only the as-built drawings, and training should cover normal operation, alarm response and the first ten minutes of a fault.
- Responsibility matrix for plant, controls, IT and operations
- Staged cutover: read-only, control, retirement
- As-built sequences, not only drawings
- Training for normal operation and first response
- Old system stays until acceptance
BMS functions and ownership
14 rows| Function | BMS role | Typical boundary |
|---|---|---|
| Plant control | Owns start/stop, modulation and sequences | Safety devices keep their own protection |
| Schedules and setpoints | Owns time programmes and operating modes | Changes are logged and role-controlled |
| Point schedule and naming | Defines points, units, ranges and owners | Reviewed and frozen before build |
| Alarms | Generates, rationalises, routes and records equipment alarms | Fire and security alarms stay in their systems |
| Trends | Stores plant and sensor history at defined intervals | Long-term enterprise analytics may sit above |
| Energy metering | Reads meters and reports plant consumption | Tenant billing is a separate function |
| Lighting and shading | Optional integration through gateways | Not part of a plant-only BMS scope |
| Access and CCTV | Receives events where integrated | Owned by security platforms |
| Fire alarm | Receives status and supervises shutdown | Fire panel retains authority |
| Remote access | Provides a supervised, logged connection | IT security policy defines the path |
| Sequence and interlock testing | Proves modes, failure and recovery | Witnessed SAT is signed |
| Documentation and training | As-built points, backups and instructions | A condition of handover |
| Network and cybersecurity | Segmented control network and accounts | IT owns the infrastructure |
| Modernisation | Staged cutover with read-only verification | Old system retired after acceptance |
Project images
3 images
Frequently asked
01Is a BMS the same as a BAS?
Not exactly. BAS is the wider discipline of building automation and often refers to the control layer itself. BMS usually emphasises supervision and management: schedules, alarms, trends, energy and maintenance information. Many projects use the terms interchangeably, so the scope should define which functions are included.
02Does a BMS control HVAC only?
HVAC and plant are the core, but a BMS often supervises pumps, meters, some lighting, shading and equipment status. The exact list comes from the point schedule, not from the label on the system.
03Can a BMS control lighting and access?
It can receive events and issue commands where the systems expose an interface, but lighting and access normally remain on their own platforms. The BMS supervises and coordinates; it does not become the access-control or lighting system.
04What is the difference between a BMS and an IBMS?
A BMS runs plant and equipment. An IBMS integrates the BMS with access, CCTV, parking, fire status, guest rooms and other systems, then applies cross-system rules and one operating picture. The IBMS supervises the BMS rather than replacing its safety sequences.
05Can we keep our existing BMS?
Often yes. An integration layer can read the existing BMS through BACnet, Modbus or another open interface. Whether to keep, extend or replace it is a commercial and lifecycle decision, confirmed after an audit.
06Does a BMS need a permanent internet connection?
No. Plant control, schedules and alarms should run on the local network. Remote access is optional and should be supervised, logged and segmented from the control network.
07Which protocols should a BMS support?
At minimum, the protocols used by the installed plant and meters. Common choices include BACnet/IP, Modbus RTU/TCP, KNX, DALI and dry contacts. The project should confirm which points are readable, writable and time-stamped.
08How long does a BMS project take?
It depends on building size, plant complexity, the state of existing systems and the commissioning window. A staged programme with an audit, point schedule, factory testing and site commissioning is more reliable than a single deadline.
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.