IBMS · Scope
IBMS Scope — A Subsystem Matrix, Not a Wish List
A practical method for defining IBMS scope: a subsystem matrix, realistic integration depth, exclusions and acceptance criteria.
Quick answer
IBMS scope is defined by a subsystem matrix: for each system, state whether it is monitored, controlled, included in cross-system interlocks or only reported. Life-safety and security systems usually stay under their own control, with the IBMS supervising status and events rather than issuing commands.
Scope is a matrix, not a list
A list of subsystems says what is connected. A matrix says what each connection is allowed to do. Use rows for systems and columns for monitoring, control, alarm handling, cross-system interlock and reporting. Add columns for interface owner and acceptance test. The matrix exposes gaps before they become change orders: a system marked for control but with no writable interface, or an interlock that depends on a point nobody supplies. It also gives the operator a realistic picture of what the platform will and will not do. A matrix with no owner column is a diagram of intentions. Keep the acceptance test column visible during design reviews; it turns a promise into a deliverable.
Realistic depth per subsystem
HVAC usually supports full monitoring and control. Lighting may support scenes and schedules, but not every luminaire group is worth individual control. Energy meters are monitor-only, with reporting depth set by the meter and the gateway. Access control can share events and permissions, while the access system keeps its own decision logic. Fire alarm is monitor-only for status and events; commands stay with the fire system. Lifts, parking and guest rooms vary widely. The right depth is the one the operator will actually use, not the maximum the protocol allows. Guest room control may include scenes and energy limits, while the hotel PMS keeps its own workflow. Each depth decision should be justified by an operating scenario, not by a protocol capability list.
What to leave out
Exclude anything that cannot be supported after handover. That includes obsolete controllers with no documented interface, vendor portals that require a personal account, and systems whose only integration path bypasses their safety limits. Life-safety commands should stay with the life-safety system itself. Avoid integrating a subsystem just to display one value on a dashboard; the interface, gateway and maintenance burden will outlive the novelty. A clear exclusion list protects the project as much as a clear inclusion list. Every exclusion needs a reason and a consequence, so the client can accept it knowingly. If a subsystem has no stable interface, a documented manual process is often the honest answer.
Writing the scope statement
Turn the matrix into a scope statement with four parts: inclusions, exclusions, interface responsibilities and acceptance tests. Name the protocol, the gateway owner, the point count basis and the data ownership. State what happens when an interface is unavailable. Define the test that proves each row, and require the result in the handover pack. Review the statement at each design stage, because scope grows quietly through site questions. The document should be short enough to read in one meeting and specific enough to price. Use the same terms as the tender documents, so the scope can be compared line by line. When a question changes the scope, record the change and its cost before proceeding.
Typical IBMS integration depth by subsystem
7 rows| Subsystem | Typical depth | Boundary |
|---|---|---|
| HVAC | Monitor and control | Sequences remain in DDC controllers |
| Lighting | Scenes, schedules and status | Emergency lighting stays on its own system |
| Energy metering | Monitor and report | Meter accuracy and gateway ownership |
| Access control | Events and permissions | Access decisions remain in the access system |
| CCTV | Events and selected streams | Privacy and retention rules |
| Fire alarm | Status and events only | Commands remain with the fire system |
| Lifts and parking | Status, alarms and availability | Vendor interface and safety limits |
Project images
3 images
Frequently asked
01Should the IBMS control the fire alarm system?
No. Fire alarm and other life-safety systems keep their own dedicated control. The IBMS may monitor status and events and display them alongside other alarms.
02How many subsystems should an IBMS integrate?
There is no target number. Integrate the systems that support a decision the operator actually makes; leave the rest out until a real use case appears.
03Can we add a subsystem later?
Yes, if the data model, naming and network are designed for it. Retrofitting an undocumented subsystem is much harder than adding one with a stable interface.
04Who owns the gateway?
One party should. The scope statement should name who supplies, configures, tests and maintains it, including firmware updates and spare units.
05What proves the scope is complete?
A signed matrix with an acceptance test result for every row, plus a list of exclusions agreed by the client and the operator.
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.