楼宇设备智能管理平台

项目背景

企业楼宇里的照明、空调、通风、环境传感与水电计量设备，通常是分批建起来的：不同年代、不同区域、不同管理流程，各留一套台账。这份材料要解决的核心问题不是再加一套监控系统，而是能不能把这些设备放进同一个对象模型里，让状态可读、重复操作可自动化、异常有统一响应。材料属产品介绍性质，未披露客户、合同范围、交付周期与验收结果，因此这里只说明平台能力与按客户环境定制交付的方式。

设备分散到什么程度

分散体现在四个层面，而不是一句管理效率低能概括。一是资产：跨城市、楼宇、楼层的设备缺少统一的建档与分级方式，台账靠人工维护，改动不留痕迹。二是数据：照明、空调、环境与能耗各自成表，对象口径和时间口径对不齐，复盘时拼不出同一张图。三是控制：定时开关、条件联动、情景切换与报警响应分散在不同系统里执行，没有一套规则能完整描述什么条件下、对哪些设备、做什么动作、失败如何退。四是边界：多企业共用一套平台时，谁看得见哪些设备、谁有权改哪条规则，事先说不清楚。

我们的做法与三个取舍

第一个取舍是先做统一设备与空间建模，再谈可视化。可视化面板的演示效果最直接，但在城市—楼宇—楼层—设备的对象关系稳定之前，大屏只是把散乱换了一种画法，点位一调整就要重做。所以我们先固定空间层级与设备档案，把面板和看板放到模型稳定之后。

第二个取舍是规则引擎不追求通用表达式。我们先把定时、逻辑、情景、报警四类固定形态的规则做扎实，用可配置参数配合任务调度承载，而不是一开始就做通用规则语言。代价是复杂的跨系统策略仍需开发介入；换来的是运营人员能自己改参数、改完能确认是否生效、出问题能追到哪条规则触发。

第三个取舍是控制权限按设备分级，不做全局开放。能读状态和能写控制点是两件事。接入时逐项确认哪些设备允许下行控制、哪些只做状态监视，再据此划分角色可见范围，避免把空调末端与计量设备暴露给所有使用人员。

平台如何承载这套管理

公开能力地图归为四个功能域：设备与空间负责建档，自动化运营负责规则编排与报警记录，环境与能源负责趋势、分项、电费与报表视图，平台治理负责租户、账号、角色、菜单与操作日志。入口分 PC 端、移动端与可视化控制面板三类。设备消息经统一接入层进入 MQTT 连接，由规则与任务模块驱动动作，业务数据与缓存由 MySQL、Redis 承担，消息侧由 EMQX 支撑，整体采用前后端分离与模块化服务组织。

交付边界与尚未披露的部分

有三件事说在前面。第一，材料未披露历史项目的交付周期与验收结果，我们也不引用未经核验的性能与容量数字，实际接入规模以现场点表梳理的结论为准。第二，多租户与权限属于应用层边界，安全效果需要专项验证，不能因为功能存在就当作已经成立。第三，既有楼宇自控系统的改造、现场点位施工与第三方硬件质保不在平台范围内。

后续演进

可继续加深的位置取决于运营复盘的结果：能耗分项与电费的口径细化、报警从产生到处理关闭的记录完整度、以及面向多楼宇的比较视图。至于趋势预测与数据挖掘类能力，现有材料没有给出明确实现边界，按需求评估单独讨论，不作为平台既有能力对外表述。