IBMS · Architecture
IBMS Architecture — A Reference Model That Survives Handover
A reference architecture for an IBMS: field devices, a network and gateway layer, a supervision core with one data model, and role-based applications.
Quick answer
An IBMS architecture has four layers: field devices and controllers, the network and gateway layer, a supervision core with one data model, and role-based applications. Control stays local, integration logic lives in the core, and applications read from it rather than polling subsystems directly.
Four layers, one source of truth
Treat the architecture as four layers. Field devices measure and actuate. Controllers execute local sequences. The network and gateway layer carries data between protocols and networks. The supervision core normalises points into one object model and owns alarms, schedules, history and interlocks. Applications sit on top and present role-specific views. The layers are defined by responsibility, not by product names. A single box may perform two layers in a small building, but the responsibilities should still be written down, because that is what makes the system testable and maintainable after the project team has left. When a layer is skipped, the missing responsibility usually reappears as a manual routine. Write the responsibility next to each box on the drawing.
The network and gateway layer
Most integration failures start here. BACnet/IP, Modbus TCP, KNX and DALI each have their own timing, addressing and diagnostic model. Keep the building network segmented from the corporate network, document every gateway and its point map, and avoid stacking translators. A gateway should translate a protocol, not own a control sequence. Where a subsystem exposes a stable API, use it directly; where it does not, define the gateway owner, power supply, firmware policy and failure behaviour. Network diagrams drawn after commissioning are a warning sign, not a deliverable. Keep a port list and an address plan; commissioning is faster when the map is right. A gateway that needs a laptop and a password nobody has is not an open interface.
The supervision core
The core is where the IBMS becomes more than a collection of connectors. Every point needs an identity, a unit, a quality flag, a history policy and an alarm class. Every subsystem needs a naming convention that a new engineer can read. Schedules and interlocks belong here so they can be seen, tested and changed without editing vendor code. The core also owns time synchronisation, user roles and the audit trail. If two applications disagree about a value, the core is the place to resolve it, not a third database maintained by the reporting team. Point names should describe the equipment, the location and the function, in that order. A name that only the original programmer understands is a future service call.
Resilience and security by design
Local control must survive a supervision outage, a network fault and a server restart. That means controllers hold their sequences and safe positions, and the network has a documented failure mode. Security is part of the same design: segmented VLANs, named accounts, least privilege, patching, logging and a controlled remote-access path. Backups should be restorable by the client, not only by the original integrator. Test the failure cases during commissioning, because an architecture that has never been failed on purpose is still only a drawing. Document the recovery steps and test them with the client's team, not only with the installer's laptop. A backup that has never been restored is a hope, not a control.
IBMS layers and responsibilities
5 rows| Layer | Owns | Design question |
|---|---|---|
| Field | Measurement and actuation | Are sensor locations and fail positions defined? |
| Controller | Local sequences and safety | What runs when the network is down? |
| Network and gateway | Protocol translation and transport | Who owns each gateway and its point map? |
| Supervision core | Data model, alarms, history, interlocks | Is there one identity for each point? |
| Application | Role-based views and reports | Does it read from the core or poll subsystems? |
Project images
3 images
Frequently asked
01How many layers does an IBMS architecture need?
Three or four, depending on whether the network is counted separately. What matters is that each layer has an owner and a clear failure behaviour, not the number itself.
02Where should gateways sit in the architecture?
At the edge, close to the subsystem they translate, on a documented network segment. They should not carry control logic or become an undocumented single point of failure.
03Can the IBMS run in the cloud?
The application layer can, and often does. Supervision and local control should remain on site so the building keeps operating when the connection drops.
04How should cybersecurity be handled?
Segment networks, use named accounts with least privilege, patch on a defined cycle, log administrative actions and control remote access. These are design requirements, not an IT afterthought.
05Which document defines the architecture?
A network riser, a point schedule, a protocol matrix and a responsibility matrix. Together they show what connects to what, who owns each interface and how it will be tested.
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.