3、智能门锁系统架构：端侧、边缘侧、云端协同，以及模型更新在其中的位置
智能门锁的OTA模型更新并非简单的“下载-替换”过程，而是建立在端、边、云三层协同架构之上的系统工程。端侧负责实时推理与本地决策，边缘侧承担区域级网关汇聚与策略缓冲，云端则完成模型训练、版本管理与发布调度。理解这三层架构中数据流、控制流和模型流的走向，是设计可靠人脸模型升级方案的前提。本章将拆解这一架构，并明确模型更新在其中的具体位置与交互关系。
上图展示了智能门锁系统三层架构中模型更新的完整链路。云端负责模型的训练、验证和版本发布，边缘侧作为中间层承担策略缓存和批次控制，端侧则执行最终的模型接收、校验和切换。模型更新并非端侧孤立行为，而是由云端发起、边缘协调、端侧执行的协同过程。下面从各层职责、模型流走向和关键设计要点三个维度展开。
3.1 端侧：本地推理与模型驻留
端侧即智能门锁本体，通常包含人脸识别模组（摄像头+红外补光）、AI处理单元（NPU或高性能MCU）、安全芯片和锁控MCU。端侧的核心职责是实时、低延迟地完成人脸检测、活体判断和特征比对。由于门锁场景对功耗和响应时间极其敏感（通常要求解锁响应小于1秒），模型必须驻留在本地Flash中，推理过程不依赖网络。
在模型更新场景中，端侧需要具备以下能力：
- A/B分区存储：将当前运行模型（A区）和新下载模型（B区）分别存储，避免升级失败导致设备变砖。
- 模型校验机制：下载完成后，端侧需对模型文件进行哈希校验（如SHA-256）和签名验证，确保模型完整且来自可信源。
- 回滚触发条件：当新模型在试运行期间出现解锁失败率升高、活体误判等异常时，端侧能自动回退到A区模型。
3.2 边缘侧：区域网关与策略缓冲
边缘侧通常指小区或楼宇内的智能网关、集中器或管理平台。它不直接参与人脸识别，但承担着连接云端与大量门锁设备的桥梁作用。边缘侧的存在解决了两个核心问题：一是云端与门锁之间的网络不稳定问题，二是大规模设备同时升级时的带宽和并发压力。
边缘侧在模型更新中的具体职责包括：
- 模型包缓存：云端将模型包下发至边缘网关，网关暂存模型包，并根据云端指令分批推送给门锁设备。
- 灰度批次控制：边缘侧根据设备分组（如按楼栋、单元或设备ID哈希）执行灰度策略，先推送1%设备，观察稳定后再扩大范围。
- 断点续传与重试：当门锁设备因断电或网络中断导致下载失败时，边缘侧支持从断点继续传输，避免重新下载整个模型包。
- 本地日志汇聚：收集门锁上报的升级结果、推理异常日志，并汇总后转发至云端。
| 层级 | 主要硬件/组件 | 模型更新中的角色 | 关键约束 |
|---|---|---|---|
| 云端 | 训练服务器、对象存储、OTA服务 | 模型训练、版本管理、灰度策略制定 | 训练数据隐私合规、模型版本兼容性 |
| 边缘侧 | 区域网关、边缘服务器 | 模型包缓存、批次分发、状态汇聚 | 存储容量有限、网络带宽波动 |
| 端侧 | 人脸模组、NPU、MCU、Flash | 模型接收、校验、A/B切换、推理 | Flash空间、NPU内存、功耗预算 |
3.3 云端：训练、验证与发布调度
云端是整个模型更新体系的大脑。它负责从海量端侧设备收集人脸特征数据（脱敏后）、训练新模型、在仿真环境中验证模型效果，并制定详细的发布计划。云端与边缘侧、端侧的交互主要通过MQTT或HTTPS长连接完成。
云端在模型更新中的关键流程如下：
- 数据回流：端侧定期上传“难例样本”（如误识别为陌生人的家庭成员照片、光线极差环境下的模糊人脸）至云端，用于模型迭代训练。
- 模型训练与评估：使用GPU集群训练新模型，并在云端测试集上评估准确率、误识率（FAR）和拒识率（FRR）。只有当新模型在测试集上全面优于旧模型时，才允许进入发布流程。
- 发布策略配置：云端OTA服务配置灰度比例、暂停条件（如失败率超过5%则自动暂停）、回滚指令等参数。
3.4 模型更新在架构中的位置与数据流
模型更新在系统架构中横跨三层，其核心数据流可以概括为“一上一下”两条链路：
下行链路（模型下发）：云端训练完成 → 模型打包并签名 → 推送至边缘网关 → 边缘网关按灰度策略分批推送给端侧 → 端侧下载至B区 → 校验签名和哈希 → 切换至B区运行 → 上报升级结果。
上行链路（数据回流）：端侧采集推理异常样本和性能指标 → 上报至边缘网关 → 边缘网关聚合后转发至云端 → 云端存入训练数据集 → 触发下一轮模型迭代。
这两条链路并非完全独立。在实际运行中，下行链路的灰度发布节奏需要参考上行链路反馈的实时指标。例如，当灰度比例达到10%时，云端会检查这10%设备上报的解锁失败率是否超过预设阈值（如0.5%），若超过则立即暂停发布并触发自动回滚。
3.5 实战场景：某公寓项目的人脸模型灰度升级
某智慧公寓项目部署了500台智能门锁，使用v2.1版本人脸模型。运营方发现部分租户在逆光环境下解锁失败率偏高（约3.2%），云端团队基于收集的难例样本训练了v2.2模型，在内部测试集上FAR从0.1%降至0.06%，FRR从3.2%降至1.8%。现计划通过OTA进行升级。
初始条件与约束：500台设备分布在10栋楼，每栋楼50台；边缘网关部署在每栋楼的弱电井中；设备端Flash剩余空间为12MB，v2.2模型大小为9.5MB（v2.1为8.8MB），A/B分区方案可行；升级窗口限制在凌晨2:00-5:00，避免影响租户正常使用。
操作步骤：
- 云端将v2.2模型包（含签名）推送至10个边缘网关，网关确认收到并缓存。
- 云端设置灰度策略：第一批选择1号楼（50台）作为金丝雀批次，升级完成后观察24小时。
- 边缘网关在凌晨2:00向1号楼设备推送升级指令，设备下载模型至B区，校验签名后自动切换，并上报“升级成功”状态。
- 24小时后，云端检查1号楼设备上报的解锁失败率：从3.1%降至1.9%，无异常告警，决定扩大灰度至50%（5栋楼）。
- 第二批升级完成后，再次观察12小时，确认无误后推送剩余5栋楼。
- 全部升级完成后，云端标记v2.2为“全量发布”状态，v2.1模型保留在云端版本仓库中作为回滚备选。
结果与复盘：整个升级过程耗时3天，500台设备全部升级成功，无一台需要人工干预回滚。复盘发现，边缘网关的断点续传功能在2台设备因夜间断电导致下载中断时发挥了关键作用，恢复供电后自动续传完成升级。此外，由于提前在灰度阶段验证了模型在低光照下的表现，避免了全量发布后可能出现的租户投诉。
3.6 常见误区与设计要点
在智能门锁模型更新的架构设计中，以下误区需要特别规避：
- 误区一：将边缘侧视为可选项。在设备规模较小（少于50台）时，云端直连设备或许可行；但一旦规模扩大，边缘侧的缓冲和调度作用不可替代，否则云端OTA服务极易成为瓶颈。
- 误区二：忽略端侧Flash的磨损均衡。频繁的模型擦写会缩短Flash寿命。建议在端侧采用“双备份+差量更新”策略，仅下载模型变化的部分，减少写入量。
- 误区三：灰度发布只看设备数量。更科学的做法是按“设备使用频率”分层，优先升级高频使用设备（如主出入口门锁），以便更快暴露潜在问题。
- 误区四：回滚机制只依赖端侧。云端和边缘侧也应保留上一版本模型，并支持远程强制回滚指令，以应对端侧自动回滚失败的情况。