IBMS 常被描述为“把所有东西连起来的平台”。这句话是对的，但没什么用。真正有用的问题是：连接发生在哪里，数据归谁，某个子系统出问题时会发生什么。
我们在每个项目中都使用三层模型：设备层、监控层、应用层。它来自本项目实践背后的分布式集成模型，并且在真实建筑中经受住了考验，因为它让职责保持清晰。
为什么扁平优于纵深
每增加一个网关、协议转换器或中间件跳点，就增加一份延迟、一个故障点，以及一个数据模型可能漂移的地方。扁平架构减少了传感器与需要据此行动的人之间的翻译次数。
扁平不等于“没有层级”。它意味着层级是功能性的，而不是偶然形成的：边缘有控制器，中间有一个监控核心，应用从核心读取数据，而不是各自建立影子数据库。
第一层：设备层
设备层是物理控制发生的地方。Loxone 控制器与 I/O 模块运行本地顺序、读取传感器、驱动执行器。第三方系统通过网关或原生接口接入：冷热源用 BACnet/IP，电表与逆变器用 Modbus，照明与遮阳用 KNX，灯具用 DALI，消防与遗留设备用干接点。
重要的设计决策不是哪种协议胜出，而是哪个控制器拥有哪段顺序，以及监控层离线时会发生什么。本地控制应该完整到让建筑保持安全与可用。
第二层：监控层
监控层是集成核心。它把每个子系统归一为统一对象模型：一个点位有身份、单位、质量标志、告警状态与历史。门就是门，无论它来自门禁控制器还是 PLC；温度就是温度，无论它通过 BACnet 还是 Modbus 到达。
跨系统联动就在这里。门禁开门，照明、暖通与视频监控响应。联动在监控层配置，而不是在厂商控制器之间硬接线。这使它可见、可测试、可修改。
监控层必须拥有的东西
- 一个带优先级、确认与升级的告警模型。
- 一个可以覆盖、但不需要修改控制器代码的日程模型。
- 命令、设定值与确认的审计轨迹。
- 以已知分辨率存储区间数据的历史模型。
- 一套能经受交付与移交的命名规范。
第三层：应用层
应用层是人看到的部分。它应该为角色而建，而不是为集成商的演示而建：运维视图突出需要关注的事，工程视图暴露点位与趋势，管理视图报告结果。
应用从监控核心读取数据。它们不直接轮询子系统，也不维护自己的事实副本。这条规则避免了仪表盘与 BA 系统各说各话的经典故障。
一个具体例子
租户在 07:40 进入楼层。门禁控制器报告事件。监控层检查租户日程与楼层占用状态，释放照明场景，启动空调顺序，并让视频监控标记进入事件。运维人员看到一个事件，而不是四个。
如果一个跨系统行为无法用一句话描述，它大概应该写进有记录的顺序里，而不是藏在某个脚本里。
规格书应该写什么
| 要求 | 为什么重要 |
|---|---|
| 本地控制独立性 | 网络或云端中断时，建筑必须保持安全与可用。 |
| 开放协议清单 | 防止单一厂商成为获取建筑数据的唯一通道。 |
| 单一告警模型 | 阻止重复告警，让升级过程可审计。 |
| 点位命名规范 | 让移交、维护与后续集成成为可能。 |
| 历史保留与导出 | 能源与性能声明需要站得住的数据链。 |
三层模型不是产品图，而是职责图。如果你说不清某个行为归哪一层，它大概率放错了地方。
结论
IBMS 架构的重点不是连接最多的系统，而是让连接可读：一个数据模型、一个告警模型、一条审计轨迹，以及能在断网时存活的本地控制。这些做对了，仪表盘是容易的；做错了，再漂亮的仪表盘也救不了项目。
