3、智能门锁系统架构：从传感器、主控、执行机构到云端的完整系统组成

智能门锁并非一个简单的“电机+蓝牙”组合，而是一个典型的边缘计算与物联网协同系统。在 TinyML 实战中，我们既要理解每个硬件模块的电气特性，更要把握数据流、控制流和能量流在整个系统中的走向。只有把传感器采集、主控推理、执行机构动作、云端同步这四个环节打通，才能设计出既安全又低功耗的产品。本章将从系统级视角拆解智能门锁的完整架构，并重点说明各模块之间的接口关系与交互时序。

3.1 系统分层与模块边界

智能门锁的系统架构可以划分为四个核心域：传感器域、主控域、执行机构域和云端平台域，外加一个贯穿全局的电源域。传感器域负责物理世界的信号采集，包括指纹图像、触摸按键、门磁状态、人体红外、防撬开关等；主控域是系统的“大脑”，运行 TinyML 模型、状态机和安全策略；执行机构域将控制指令转化为机械动作，驱动电机或电磁锁完成开锁/闭锁；云端平台则承担设备管理、日志上报、远程授权和 OTA 升级。电源域为所有模块提供稳定、低功耗的能量供给。

各模块之间的交互并非单向的数据流，而是存在明显的控制回路。传感器将采集到的原始数据通过 SPI、I2C 或 GPIO 中断方式传递给主控；主控经过推理和决策后，通过 PWM 或 GPIO 控制电机驱动；执行机构的状态（如限位开关、电流检测）又反馈给主控，形成闭环控制。同时，主控通过 WiFi/BLE 与云端通信，既上报事件日志，也接收远程指令。理解这些交互关系，是后续进行低功耗设计和安全联调的基础。

3.2 核心交互流程与数据链路

从一次典型的指纹开锁操作来看，系统交互流程可以拆解为五个阶段。第一阶段是唤醒：PIR 检测到人体接近或用户触摸键盘，通过 GPIO 中断唤醒主控，此时主控从 deep sleep 模式恢复，初始化外设。第二阶段是采集：主控向指纹传感器发送采集命令，传感器返回指纹图像数据，通常为 192×192 像素的灰度图，约 36KB。第三阶段是推理：主控运行 TinyML 模型，对指纹图像进行特征提取和比对，输出匹配分数和决策结果。第四阶段是执行：若匹配成功，主控通过 PWM 控制电机驱动，带动离合机构完成开锁动作，同时读取限位开关确认到位。第五阶段是上报：主控通过 WiFi 将开锁事件、时间戳、用户 ID 等信息推送到云端，并同步更新本地日志。

这条数据链路中，最关键的瓶颈在于推理阶段的耗时和功耗。以 ESP32-S3 为例，运行一个参数量约 50KB 的 MobileNetV2 变体模型，推理时间约为 80-150ms，电流消耗约 240mA。如果每次开锁都全速运行，对电池寿命的影响非常显著。因此，实际设计中通常采用两级唤醒策略：第一级由 PIR 或触摸中断唤醒主控，但不启动 WiFi；第二级在指纹匹配成功后，才启动 WiFi 进行数据上报。这种设计可以将待机功耗控制在 10μA 以下，而单次开锁的等效功耗约为 0.5mAh。

3.3 低功耗架构与电源设计

智能门锁通常使用 4 节 AA 电池（6V 总电压）或单节锂电池（3.7V），要求待机功耗低于 50μA，整机续航 6-12 个月。电源域的设计需要区分三种工作状态：待机态、工作态和峰值态。待机态下，主控进入 deep sleep，传感器和 WiFi 模块断电或处于低功耗模式，仅保留 RTC 和中断唤醒电路，整机电流约 5-15μA。工作态下，主控运行推理，传感器采集数据，电流约 50-150mA。峰值态出现在电机启动瞬间，堵转电流可达 500mA-1A，此时需要电容储能或 DC-DC 的峰值电流能力支撑。

电源树的设计通常采用两级转换：第一级将电池电压通过 DC-DC 降压至 3.3V，为主控、传感器和 WiFi 供电；第二级通过 LDO 输出 1.8V 给指纹传感器内部模拟电路，或通过电荷泵产生 5V 给电机驱动。关键设计点在于：DC-DC 的静态电流要低（如 TPS62740 静态电流 360nA），LDO 的压差要小，且各电源轨需要独立的使能控制，以便在待机时切断非必要模块的供电。

// 电源状态切换伪代码
typedef enum {
    POWER_STATE_SLEEP,      // 待机: 5μA
    POWER_STATE_SENSING,    // 采集: 30mA
    POWER_STATE_INFERENCE,  // 推理: 120mA
    POWER_STATE_ACTUATING,  // 执行: 400mA
    POWER_STATE_COMMUNICATE // 通信: 250mA
} power_state_t;

void power_state_transition(power_state_t next) {
    switch (next) {
        case POWER_STATE_SLEEP:
            gpio_set_level(WIFI_EN, 0);   // 关闭WiFi
            gpio_set_level(SENSOR_EN, 0); // 关闭传感器
            esp_deep_sleep_start();        // 进入deep sleep
            break;
        case POWER_STATE_SENSING:
            gpio_set_level(SENSOR_EN, 1);
            // 等待传感器稳定
            vTaskDelay(pdMS_TO_TICKS(50));
            break;
        // 其他状态转换...
    }
}

3.4 安全机制与云端交互

智能门锁的安全体系分为本地安全和云端安全两层。本地安全包括：指纹模板的加密存储（通常使用 AES-128 加密后存放在 Flash 独立分区）、防撬开关检测（当锁体被强行拆卸时触发本地告警并上报）、连续失败锁定（5 次指纹验证失败后锁定 30 秒，防止暴力破解）。云端安全则涉及设备身份认证（使用 TLS 双向认证）、通信加密（MQTT over TLS）、以及 OTA 固件签名校验。

在云端交互设计上，需要区分事件上报和指令下发两种模式。事件上报采用 QoS 1 级别，确保开锁记录不丢失；指令下发（如远程授权临时密码）采用 QoS 0 级别，因为时效性高于可靠性。设备与云端的心跳间隔通常设置为 5-10 分钟，心跳包中携带电池电量、信号强度、最近事件序号等信息。如果设备离线超过 24 小时，云端应产生离线告警，提示用户检查设备状态。

3.5 案例拆解：一款量产门锁的架构优化过程

某智能锁厂商的初代产品采用“STM32F407 + 独立 WiFi 模块 + 电容指纹传感器”方案，实测待机功耗 180μA，4 节 AA 电池续航仅 3 个月，且开锁响应时间长达 2.8 秒。用户投诉集中在“电池不耐用”和“指纹识别慢”两个问题上。我们团队介入后，从系统架构层面进行了三项优化。

第一项优化：更换主控并调整电源域。将 STM32F407 替换为 ESP32-S3（支持深度睡眠 7μA），并增加 TPS62740 DC-DC 作为主电源轨。同时将 WiFi 模块的供电从常开改为 GPIO 控制，仅在通信阶段使能。优化后待机功耗降至 12μA，理论续航提升至 14 个月。

第二项优化：引入两级推理策略。原方案每次开锁都运行完整指纹识别流程，耗时 1.2 秒。我们改为：第一级使用轻量级分类器（MobileNetV2 的 0.25 倍宽度，参数量 18KB）在 40ms 内完成粗匹配，过滤掉 80% 的非匹配指纹；第二级仅在粗匹配通过后运行完整模型（参数量 52KB）进行精确认证。整体推理时间从 1.2 秒降至 180ms，且误识率从 0.8% 降至 0.1%。

第三项优化：云端通信改为事件驱动。原方案每 30 秒上报一次心跳，WiFi 频繁开关导致功耗增加。我们改为：正常待机时关闭 WiFi，仅在开锁事件、低电量告警或每日固定时间点（凌晨 3 点）进行短连接上报。单次连接时间从 8 秒压缩到 2.5 秒（通过减少 TLS 握手开销和精简 JSON 数据包）。

优化后的实测数据对比如下：

这次优化的核心经验是：系统架构的瓶颈往往不在单一模块，而在于模块间的交互策略。待机功耗高并非因为某个器件耗电，而是因为 WiFi 常开和主控睡眠模式选择不当；响应慢并非因为模型太大，而是因为缺少分级推理机制。在 TinyML 门锁设计中，架构层面的决策（如电源域划分、唤醒策略、通信模式）对最终产品体验的影响，远大于单个算法或器件的优化。

总结来说，智能门锁的系统架构是一个典型的“感知-决策-执行-反馈-上云”闭环。传感器域负责感知物理世界，主控域承载 TinyML 推理和策略决策，执行机构域完成物理动作，云端平台提供远程管理和数据服务，电源域则为整个系统提供能量保障。在实际开发中，需要特别关注模块间的接口时序、功耗状态切换和安全管理机制。只有从系统层面统筹设计，才能打造出既安全可靠又低功耗的智能门锁产品。