Scenarios · Multi-site
Multi-Site IBMS: One Operating Picture Across Buildings
How to design a multi-site IBMS with a common data model, local autonomy and a central layer that survives network outages.
Quick answer
A multi-site IBMS gives a portfolio one data model, one alarm model and one reporting layer while each building keeps local control. Sites run their own sequences and store their own history; the centre compares performance, distributes standards and manages access, but is not required for day-to-day operation.
What one operating picture actually requires
A portfolio dashboard is not a multi-site IBMS. The harder work is agreeing what a point means across buildings: the same name for outdoor temperature, the same units, the same alarm severity, the same time-zone handling and the same definition of occupancy. Without that model, the centre receives data it cannot compare and operators spend their time reconciling definitions. The model should be written down before the first site is configured, with a naming convention, an object dictionary and a rule for site-specific extensions. Standardisation at this layer is what makes portfolio reporting credible, and it is also what makes a new site faster to commission.
Local autonomy and the central layer
Each site should remain fully operable when the wide-area link is down. Site controllers run HVAC, lighting, shading and metering sequences and hold enough history to survive an outage. The central layer aggregates, visualises, reports and manages users. It may also distribute template updates, but those updates should be staged and reversible. This division keeps safety and comfort local while giving management a portfolio view. It also limits the blast radius of a central fault and makes the network architecture easier to secure. The central platform can be upgraded without touching site control logic. The test is simple: disconnect a site and confirm that the building still runs, alarms are still recorded and history is not lost.
Standardise the template, document the site profile
A portfolio needs a common template: graphics, point naming, alarm classes, schedule objects, report definitions and user roles. It also needs a site profile for the things that legitimately differ: plant type, climate, opening hours, tenant metering, local regulations and network topology. The template should be versioned, and each site should record which version it runs. When a site needs a deviation, write it down and decide whether it should be promoted into the next template version. This prevents the slow divergence that turns a portfolio into a set of unrelated systems. It also gives the central team a way to roll out an improvement without re-engineering every building by hand.
Rollout, security and governance
Roll out in waves, with a reference site that proves the template before it is replicated. Define who can change setpoints, who can acknowledge alarms and who can add users at each level. Segment building networks from corporate IT, require named accounts, and maintain a patching and firmware policy that covers controllers, gateways and the central platform. Test a site in isolation and then test the portfolio view, including what happens when one site is offline. Governance is not paperwork: it is the difference between a system that stays comparable and one that quietly fragments. The operating model should name the people who own each layer and the cadence for reviewing performance. A short monthly report is enough to keep the portfolio visible.
Layers in a multi-site IBMS
7 rows| Layer | Function | Design decision |
|---|---|---|
| Site control | HVAC, lighting, shading and metering sequences | Runs locally and survives a WAN outage |
| Site history | Trend storage and alarm log | Retains enough data for local operation and later upload |
| Central aggregation | Portfolio dashboards and reports | Reads a common data model, not raw vendor points |
| Alarm management | Cross-site routing and escalation | Separates critical portfolio alarms from local nuisance alarms |
| User access | Roles and permissions | Applies least privilege at site and central level |
| Template management | Standard graphics, sequences and naming | Versions the template and records each site's version |
| Network and security | Segmentation, remote access, patching | Keeps building networks separate from corporate IT |
Project images
3 images
Frequently asked
01Do all sites need the same BMS?
They need a common data model and reporting layer. Site hardware can differ if the template defines how points, alarms and history are exposed.
02What happens when a site loses its connection?
The site keeps running on local control and stores history locally. The centre should show the site as offline and backfill data when the link returns.
03Who owns the data?
The owner should. Contracts should state where data is stored, how it is exported and what happens at the end of a service agreement.
04How do we handle different time zones?
Store time stamps with an explicit time zone and synchronise clocks. Reports should state whether they use local or central time.
05Can we add a new site later?
Yes, if the template is versioned and the new site is profiled against it. The cost and effort depend on how far the site deviates from the standard.
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.