An IBMS is often described as “a platform that connects everything”. That description is true and useless. The useful question is where the connection happens, what owns the data, and what happens when one subsystem misbehaves.
We use a three-layer model on every project: device, supervision and application. It comes from the distributed integration model used in the project specification behind this practice, and it has survived contact with real buildings because it keeps responsibilities explicit.
Why flat beats deep
Every additional gateway, protocol translator or middleware hop adds latency, a failure point and a place where the data model can drift. A flat architecture reduces the number of translations between a sensor and the person who needs to act on it.
Flat does not mean “no hierarchy”. It means the hierarchy is functional, not accidental: controllers at the edge, one supervision core, and applications that read from that core rather than building their own shadow databases.
Layer 1: device
The device layer is where physical control happens. Loxone controllers and I/O modules run local sequences, read sensors and drive actuators. Third-party systems connect through gateways or native interfaces: BACnet/IP for plant, Modbus for meters and inverters, KNX for lighting and shading, DALI for luminaires, dry contacts for fire and legacy equipment.
The important design decision is not which protocol wins. It is which controller owns which sequence, and what happens when the supervision layer is offline. Local control should be complete enough that the building remains safe and usable.
Layer 2: supervision
The supervision layer is the integration core. It normalises every subsystem into a common object model: a point has an identity, a unit, a quality flag, an alarm state and a history. A door is a door whether it comes from an access controller or a PLC. A temperature is a temperature whether it arrives over BACnet or Modbus.
This is where cross-system interlocks live. Access opens a room; lighting, HVAC and CCTV respond. The interlock is configured in the supervision layer, not hard-wired between vendor controllers. That makes it visible, testable and changeable.
What the supervision layer must own
- A single alarm model with priority, acknowledgement and escalation.
- A schedule model that can be overridden without editing controller code.
- An audit trail for commands, setpoints and acknowledgements.
- A history model that stores interval data at a known resolution.
- A naming convention that survives handover.
Layer 3: application
The application layer is what people see. It should be built for roles, not for the integrator's demo: an operator view that surfaces what needs attention, an engineer view that exposes points and trends, a management view that reports outcomes.
Applications read from the supervision core. They do not poll subsystems directly, and they do not maintain their own copy of the truth. That rule prevents the classic failure mode where the dashboard and the BMS disagree.
A worked example
A tenant enters a floor at 07:40. The access controller reports the event. The supervision layer checks the tenant's schedule and the floor's occupancy state. It releases the lighting scene, starts the HVAC sequence, and asks CCTV to mark the entry event. The operator sees one event, not four.
If a cross-system behaviour cannot be described in one sentence, it probably belongs in a documented sequence, not in a hidden script.
What to specify
| Requirement | Why it matters |
|---|---|
| Local control independence | The building must remain safe and usable during a network or cloud outage. |
| Open protocol list | Prevents a single vendor from becoming the only path to the building's data. |
| Single alarm model | Stops duplicate alarms and makes escalation auditable. |
| Point naming convention | Makes handover, maintenance and future integration possible. |
| History retention and export | Energy and performance claims need a defensible data trail. |
A three-layer model is not a product diagram. It is a responsibility diagram. If you cannot say which layer owns a behaviour, the behaviour is probably in the wrong place.
The takeaway
IBMS architecture is not about connecting the most systems. It is about making the connections legible: one data model, one alarm model, one audit trail, and local control that survives the network. Get those right and the dashboard is easy. Get them wrong and no dashboard will save the project.
