3. 移动巡检通信机制总览
数字工地移动巡检的核心挑战在于：巡检终端（手机/平板）在复杂、移动、网络不稳定的环境下，如何可靠、实时地将质量数据（照片、视频、传感器读数、检查表单）上传至后台，并接收指令。本章从架构、协同模型、协议选型三个维度，构建完整的通信机制视图。
3.1 巡检通信架构：三层物理拓扑
移动巡检通信架构采用经典的端-边-云三层拓扑，每一层承担不同的职责与通信角色。
| 层级 | 物理实体 | 核心职责 | 通信特征 |
|---|---|---|---|
| 端（End） | 巡检手机、平板、智能安全帽、手持终端 | 数据采集（拍照、录像、扫码、传感器读数）、本地缓存、人机交互 | 移动性高、网络波动大、电量敏感 |
| 边（Edge） | 工地边缘网关、塔吊基站、区域汇聚节点 | 协议转换、数据汇聚、本地决策、断网续传、实时转发 | 固定部署、低延迟、有限算力 |
| 云（Cloud） | 中心服务器、质量追溯平台、大数据存储 | 持久化存储、全局分析、模型训练、跨项目协同 | 高带宽、高可靠、弹性扩展 |
架构要点：端侧不直接与云通信，而是通过边缘网关进行数据汇聚与协议适配。这种设计在工地网络不稳定时，边缘网关可作为“数据缓冲池”，避免因云侧不可达导致巡检任务中断。
3.2 端-边-云协同模型：数据流与决策流
协同模型定义了数据如何在三层之间流动，以及决策权如何分布。在质量追溯场景中，我们采用“端侧采集、边侧缓存与预处理、云侧持久化与分析”的协同策略。
3.2.1 数据流模型
- 上行数据流（端→边→云）：巡检照片、视频片段、GPS坐标、检查表单、传感器读数。端侧生成后立即推送到边缘网关，网关进行格式校验、去重、压缩后转发至云平台。
- 下行数据流（云→边→端）：巡检任务指令、质量判定标准更新、历史缺陷数据、离线缓存策略。云平台将配置下发至边缘网关，网关缓存后按需推送给巡检终端。
- 本地闭环流（端↔边）：在断网或弱网条件下，端侧与边缘网关之间维持本地通信，完成基础的质量检查与数据暂存，待网络恢复后再同步至云端。
3.2.2 决策权分布
| 决策类型 | 决策位置 | 典型场景 |
|---|---|---|
| 实时告警 | 边层 | 传感器读数超限，边缘网关立即触发声光报警，无需等待云侧响应 |
| 质量判定 | 云层（模型） + 边层（规则） | 云侧AI模型分析照片缺陷，边侧执行预定义的检查规则 |
| 任务调度 | 云层 | 根据项目进度自动生成巡检任务，下发给指定终端 |
| 数据缓存策略 | 端层 + 边层 | 终端根据信号强度自动切换在线/离线模式，边缘网关管理缓存队列 |
协同设计原则：端侧保持轻量，只做采集与展示；边侧承担实时性与可靠性；云侧负责复杂计算与全局一致性。避免将AI推理或大数据分析放在端侧，以降低终端功耗与硬件成本。
3.3 通信协议选型原则
协议选型直接影响巡检系统的实时性、可靠性与功耗。不同层级、不同数据类型的通信需求差异显著，需遵循以下原则进行匹配。
3.3.1 协议选型对比
| 协议 | 适用层级 | 传输模型 | 实时性 | 可靠性 | 功耗 | 典型场景 |
|---|---|---|---|---|---|---|
| MQTT | 端↔边 | 发布/订阅 | 高（QoS 0/1/2） | 高（支持持久会话） | 低 | 传感器数据上报、巡检指令下发 |
| CoAP | 端↔边 | 请求/响应（类HTTP） | 中 | 中（支持重传） | 极低 | 低功耗传感器、电池供电终端 |
| HTTP/HTTPS | 边↔云 | 请求/响应 | 中 | 高（TLS加密） | 高 | 照片/视频上传、批量数据同步 |
| AMQP | 边↔云 | 消息队列 | 中 | 极高（事务支持） | 中 | 跨系统数据集成、异步任务分发 |
| WebSocket | 端↔边（实时场景） | 全双工 | 极高 | 高 | 中 | 实时视频流、远程协助 |
3.3.2 选型原则
- 按数据特征匹配：小数据量、高频次（如传感器读数）优先选MQTT或CoAP；大数据量、低频次（如照片上传）选HTTP/HTTPS。
- 按网络环境适配：弱网环境优先选MQTT（支持QoS 2保证送达）或CoAP（UDP传输，重传机制轻量）；稳定网络可选HTTP/AMQP。
- 按功耗约束选择：电池供电终端（如智能安全帽）优先选CoAP或MQTT-SN；固定供电设备（如边缘网关）无此限制。
- 按安全合规要求：所有跨公网通信必须启用TLS加密；内网通信（端↔边）可根据安全等级选择明文或加密。
- 避免协议堆叠过重：同一链路尽量只使用1~2种协议，减少协议转换开销。例如端↔边统一使用MQTT，边↔云统一使用HTTP。
常见选型误区：不要在所有场景都使用HTTP。HTTP的请求/响应模型在弱网下频繁重连会导致电量快速耗尽，且不支持服务端主动推送。巡检指令下发场景应优先使用MQTT的发布/订阅模型，实现服务端实时推送。
3.3.3 协议栈示例
以下是一个典型数字工地移动巡检的协议栈配置，供参考：
端侧（巡检手机） → 边缘网关：MQTT over TCP/TLS
- 主题：site/{projectId}/inspection/{deviceId}/data
- QoS：1（至少一次送达）
- 心跳：30秒
边缘网关 → 云平台：HTTPS（批量上传） + AMQP（异步消息）
- 照片/视频：HTTP POST multipart/form-data
- 质量判定结果：AMQP message queue
- 配置下发：AMQP topic exchange
端侧 ↔ 边缘网关（本地闭环）：CoAP over UDP（断网模式）
- 资源路径：/inspection/{deviceId}/cache
- 重传：3次，超时2秒
协议选型总结：端↔边以MQTT为主力，CoAP为低功耗补充；边↔云以HTTPS和AMQP为主，兼顾批量传输与异步解耦。所有协议选型需与网络环境、数据特征、功耗预算、安全等级四维对齐，避免“一刀切”导致系统在工地复杂环境下失效。