一个拥有50栋写字楼的物业集团在全国运营着约2000樘自动门。如何知道哪些门今天出了故障？哪些门该维护了？哪些门能耗异常高？上个月总共开关了多少次？如果没有统一的远程监控和管理平台，这些信息都散落在各地、各个门控器中——物业只能在门坏了报修之后才知道——完全的被动运维。本文给出一个可以管理数千樘自动门的远程监控与云平台数据架构方案。
一、平台总体架构——从边到云的四层模型
| 层级 | 功能 | 技术实现 |
|---|
| L0——现场设备层 | 每樘门的门控器+IoT DTU通信模块 | 门控器通过RS-485/Modbus RTU提供运行数据（开关次数/运行电流/温度/故障代码/门状态等）→DTU采集Modbus寄存器→再通过4G/WiFi上传 |
| L1——边缘汇聚层 | 每栋建筑部署一个边缘网关——汇聚本建筑内所有门的Modbus数据→上行到云 | Linux嵌入式边缘网关（ARM Cortex-A核心+≥512MB RAM+≥8GB eMMC存储）。运行协议转换服务（Modbus RTU→MQTT/OPC UA）和本地数据缓存（断网时数据不丢失——联网后自动补传） |
| L2——云平台层 | 设备管理+数据存储+业务逻辑 | MQTT Broker(EMQX)+时序数据库(TimescaleDB/TDengine)+微服务(Java/Go)。设备管理——设备注册/认证/OTA固件升级。数据流——MQTT→流处理(Kafka/Flink)→时序数据库→RESTful API |
| L3——应用展现层 | Web大屏驾驶舱+APP远程监控 | React/Vue前端+ECharts可视化。大屏：地理分布地图+门状态概览+告警汇总+关键KPI。APP：门列表+单门详情+告警推送+远程开门 |
二、核心功能模块
| 模块 | 功能描述 | 价值 |
|---|
| 实时状态监控 | 每樘门的实时状态（开/关/故障/运行中/待机）以颜色标记展示在地图和列表中——5s刷新一次 | 物业管理人员一眼看到"全网"的门状态——哪里有问题立刻知道 |
| 告警管理 | 门故障自动生成告警（故障代码+门位置+发生时间）→分级推送：低级告警（传感器脏污需清洁）APP推送+邮件、高级告警（门停运/门故障）电话或短信告警 | 从被动等报修转变为主动发现故障——故障响应时间从"数小时到半天"缩短到"数分钟" |
| 预防性维护计划 | 根据门的运行次数（如每200,000次换皮带、每500,000次润滑导轨）和历史故障数据→自动生成维护工单→推送给维保技师 | 从"坏了才修"的被动维修转向"到时间就修"的预防性维护→减少故障停机30-50% |
| 能耗分析 | 统计每樘门的日/月/年耗电量+同期对比+能耗异常检测（某门近期的能耗比历史平均高20%→可能是导轨卡滞/电机效率下降→推送检修工单） | 量化门的能耗成本（每樘门的年耗电100-300 kWh——2000樘门年总耗电约20-60万kWh=16-48万元电费）→能耗异常检测可提前发现隐藏故障 |
| 运行统计报表 | 可按门/建筑/区域/品牌/控制器型号等多维度生成开关次数、故障率、平均故障间隔时间(MTBF)、维修成本等的周期报表 | 为设备采购评估做数据支撑（哪个品牌/型号的MTBF最高——以后采购优先考虑） |
三、通信协议选择
- 门控器↔边缘网关：Modbus RTU over RS-485——最通用最可靠、硬件成本最低（任何MCU都有UART和RS-485收发器）
- 边缘网关↔云平台：MQTT——轻量、支持TLS加密、支持QoS（消息不丢失）、百万级并发
- Web/APP↔云平台API：RESTful API over HTTPS——Web和APP直接用HTTP/JSON方便开发
- 可选——如果项目需要企业级语义互操作（如门的运行数据需要接入楼宇自控系统BAS/BMS）：边缘网关上行采用OPC UA替代或叠加MQTT——OPC UA提供信息模型和安全模型——更适合工业级应用
四、安全架构
- 设备认证——每个门控器/边缘网关在平台注册时获得唯一的X.509设备证书→设备连接MQTT Broker时必须提供证书进行TLS双向认证（Mutual TLS）
- API鉴权——Web/APP调用云端API时使用OAuth 2.0+JWT Token进行身份验证和授权
- OTA固件升级——固件升级包必须由平台的私钥签名→设备下载固件后用平台的公钥验证签名——防固件被篡改或植入恶意代码
