6 万个终端、60 栋楼、12 个子系统：新建校区的物联网底座怎么搭

这是西南某医科大学的新建校区，4 万余名师生，60 栋楼宇。校区从零建设，好处是设备可以统一规划，坏处是所有子系统同时进场，谁也没有耐心等你的平台标准。

项目要接入的范围包括：宿舍智能门锁、浴室水表水控、直饮水、智能洗衣机、消费 POS、图书馆设备、建筑楼控、建筑能效、视频安防、出入口控制、停车场、机房动环、智慧教室，以及底层的计算机网络。

客户的核心诉求只有一句话：**6 万多个设备要能统一管理、统一维护、统一共享**。不是做一个大屏给人看，是让后勤、保卫、教务三个部门都能查到自己关心的设备状态，而不是各自登录一套厂商系统。

项目启动时，12 个子系统对应 12 家厂商。有的给 SDK，有的只给 HTTP 接口文档，有的给数据库直连账号，还有两家只能通过定时导出 Excel 交换数据。

平台侧的做法不是「一家一家对接」，而是先定物模型，再让厂商按物模型提供数据。这一步很关键——如果先对接再抽象，最后会得到 12 套无法统一的数据结构。

物模型分三层

• **属性（Property）**：设备当前状态，可读可写。门锁的开锁状态、水控的余额、断路器的功率。
• **事件（Event）**：设备主动上报的瞬时信息。门锁被撬、水控余额不足、烟感报警。
• **服务（Service）**：平台向设备下发的指令。远程开锁、水控强制断水、断路器分闸。

每类设备定义一套物模型，同型号设备复用。61395 个终端最终收敛成 40 多类物模型——这个收敛比是后面所有工作的基础。

接入通道按设备能力分三类

门锁和部分水控走网关型，一个门锁网关带 40 多把锁。视频走平台型，只同步通道目录和状态，不碰视频流。断路器和楼控走直连或网关，看厂商固件。

6 万个设备接入平台之后，第二个问题马上来了：**这台设备是谁装的、装在哪、什么型号、保修到什么时候**。

新建校区的现实是：设备分批进场，施工队换了好几拨，有些设备装完了没登记，有些登记了型号写错，还有些装在图纸上有、现场找不到。

平台的做法是给每台设备一个唯一编码，把「设备身份」和「物理位置」分开存。位置用「楼宇 - 楼层 - 房间」三级编码，和设备编码解耦——设备可以换、位置不变，位置可以改造、设备不动。

• 设备编码由平台统一生成，不由厂商提供，避免厂商换型号导致编码失效
• 位置编码和校区基建图纸对齐，后勤、保卫用同一套位置语言
• 设备与位置是多对多关系：一间教室有多台设备，一台网关可能管多个房间的门锁
• 台账里保留「接入时间」和「首次上报时间」，两者不一致说明设备装了但没通

新建校区的物联网项目有个绕不开的矛盾：校区建设有工期，平台标准要时间。等标准定完再接入，工期等不起；先接入再定标准，后面全要返工。

这个项目的处理方式是先出一份「接入规范」的最小版本，只规定三件事：设备编码规则、必填属性字段、数据上报格式。这份规范在第一批设备进场前发给所有厂商，后面再逐步补充细节。

规范里最有用的一条是**必填字段清单**。设备型号、安装位置、所属子系统、责任厂商、保修截止日——这五个字段必须填，缺一个不予接入验收。这条卡住之后，后面的台账工作省了一大半。

代价是前期和厂商的沟通成本很高，有两家厂商因为不愿意改数据格式，最后改用网关采集。但从结果看，这个代价是值得的：如果先接入后补字段，6 万台设备的数据补录工作量是灾难级的。