An IBMS scope fails in two directions: it is either so vague that every vendor prices a different project, or so prescriptive that it describes a product instead of an outcome. A deliverable scope sits between the two.
Start with the outcome
Write down what the building must do: which decisions the operator needs to make, which alarms must reach which role, which reports must exist at handover. The outcome is the test for every line that follows.
The system list
List every subsystem in scope, its vendor, its interface and who owns the data. If an interface is unknown, make the audit a deliverable rather than assuming it exists.
| Item | What to state | Owner |
|---|---|---|
| HVAC / plant | BACnet/IP or Modbus, point list, gateway responsibility | BMS vendor |
| Access control | API or OSDP/Wiegand, event list, door status | Access vendor |
| CCTV | ONVIF/RTSP or VMS API, camera map, event linkage | VMS vendor |
| Energy meters | Modbus, pulse or utility API, interval and units | Metering vendor |
| Hotel PMS | ODBC or API, check-in/out events, room status | PMS vendor |
| Fire alarm | Dry contacts or supervised inputs; fire panel retains authority | Fire contractor |
The interface matrix
The matrix is the single most useful page in the scope. For each subsystem, state the physical interface, the protocol, the data direction, the point count and who tests the connection. If two vendors share an interface, name the one who owns the gateway.
The point schedule
The point schedule defines every point, its address, range, unit, alarm limits and naming convention. It is not a commissioning detail. Without it, the graphics, alarms and trends cannot be tested consistently.
The alarm philosophy
Define alarm classes, priorities, routing and escalation. State which alarms are suppressed during maintenance and who can acknowledge them. An IBMS with 4,000 undifferentiated alarms is not an operating picture; it is noise.
Acceptance tests
- Point-to-point verification against the schedule.
- Alarm generation, routing and acknowledgement.
- Each cross-system interlock, tested from the triggering event.
- Trend and report accuracy for an agreed period.
- Failover: what happens when the network or a controller is unavailable.
A scope that cannot be tested is not a scope; it is a hope. Write the test before you write the requirement.
What to leave out
Do not specify a product model unless the project genuinely requires it. Specify the outcome, the interfaces, the data model and the acceptance tests. That leaves room for the integrator to propose a solution that fits the building.
The takeaway
A good IBMS scope is a set of boundaries: systems, interfaces, points, alarms, tests and handover. Get those right, and the commercial conversation becomes about value rather than ambiguity.
