1. 课程导入

在嵌入式人工智能落地进程中，ESP32系列芯片凭借其双核处理能力、内置Wi-Fi/蓝牙、丰富的外设接口以及极具竞争力的成本，成为TinyML原型验证和小批量产品交付的首选平台。然而，从实验室中的模型跑通到生产环境中的稳定运行，中间横亘着一条由功耗预算、系统鲁棒性和通信质量共同构成的“交付鸿沟”。本章作为整个课程的总纲，旨在帮助学员建立完整的项目交付思维框架，明确功耗、稳定性与联网可靠性三大验收维度的定义边界、量化指标和判定方法。我们将从工程验收的视角出发，剖析一个TinyML项目从硬件选型到最终签收的全生命周期，并重点回答三个核心问题：设备在电池供电下能持续运行多久？在恶劣电磁环境和异常输入下是否会出现死机或误判？无线连接在真实场景中的丢包率和时延是否满足业务SLA？这三个问题的答案，构成了验收报告中最具说服力的数据支撑。

上图展示了本课程的核心验收框架：三大维度并非孤立存在，而是通过项目交付决策节点相互耦合。例如，降低功耗可能要求降低CPU频率，但这会直接影响推理延迟和模型精度；增强网络可靠性需要增加重传机制，却会带来额外的功耗开销。因此，验收过程本质上是一个多目标优化问题的求解过程。在后续章节中，我们将逐一拆解每个维度的测试方法、工具链和判定标准，并在最后一章给出综合评分模型。

1.1 项目交付的完整流程与角色分工

核心原理：一个标准的ESP32 TinyML项目交付流程通常包含六个阶段：需求分析与指标拆解、硬件选型与电路设计、模型训练与量化压缩、固件开发与集成、系统测试与调优、验收评审与文档归档。每个阶段都有明确的输入、输出和评审门禁（Quality Gate）。在实际项目中，常见的失败原因并非技术难度过高，而是阶段间的信息断层——例如算法工程师交付的模型在PC上精度达标，但移植到ESP32后因定点化损失和内存限制导致精度骤降，而硬件工程师在选型时未预留足够Flash空间。

操作流程清单：

1. 需求分析：与客户确认设备工作环境（室内/室外、温度范围）、供电方式（电池容量/太阳能）、通信频次（每5秒上报 vs 每小时上报）、推理实时性要求（<100ms vs <2s）。输出《需求规格说明书》。
2. 指标拆解：将业务需求转化为可测量的技术指标。例如“电池续航6个月”拆解为“平均电流≤0.5mA，峰值电流≤500mA，每日唤醒次数≤1440次”。
3. 原型验证：使用ESP32-DevKitC进行快速原型开发，验证模型推理效果和基本通信链路。
4. 工程化设计：完成原理图设计、PCB Layout、天线匹配、电源树设计。此阶段需重点关注DC-DC转换效率、LDO压降和去耦电容布局。
5. 固件开发：基于ESP-IDF或Arduino框架编写应用代码，集成TFLite Micro推理引擎、Wi-Fi协议栈和电源管理驱动。
6. 系统测试：按照验收标准逐项执行功耗测试、稳定性测试和联网可靠性测试，记录原始数据并生成测试报告。
7. 验收评审：由独立的质量保证人员（QA）对照验收标准逐条核对，确认无遗留问题后签署《项目验收报告》。

1.2 功耗验收：从电池寿命到能量预算

核心原理：功耗验收的本质是验证设备在真实工作负载下的能量消耗是否符合设计预算。ESP32在活跃模式（Active）下电流可达240mA（Wi-Fi开启），而在深度睡眠（Deep Sleep）模式下可降至10μA以下，两者相差四个数量级。因此，功耗验收的关键在于准确测量设备在不同工作状态（运行、空闲、睡眠、唤醒）下的时间占比和电流值，并据此计算平均功耗。常用的测量工具包括高精度万用表（如Keysight 34465A）、直流电源分析仪（如Joulescope）或低功耗测试板（如Nordic Power Profiler Kit）。

测量方法与计算模型：

平均电流 = (T_active × I_active + T_sleep × I_sleep + T_wakeup × I_wakeup) / T_total
电池寿命(h) = 电池容量(mAh) / 平均电流(mA) × 0.85(放电效率系数)

以一个典型的工业振动监测节点为例：设备每10分钟唤醒一次，采集加速度数据并运行CNN模型进行故障分类，随后通过Wi-Fi将结果上传至云端。实测数据如下：唤醒后工作时间为850ms，期间平均电流为180mA；Wi-Fi传输时间为120ms，平均电流为240mA；其余时间处于深度睡眠，电流为12μA。计算得到平均电流约为0.31mA，若使用2000mAh的ER18505锂电池，理论续航为6451小时（约268天），考虑电池自放电和低温影响，实际续航约220天。

案例拆解：智能农业土壤监测节点

某智慧农业项目要求节点在野外环境连续工作1年，使用3节AA碱性电池（总容量约2400mAh）。初始设计中，节点每30分钟唤醒一次，通过土壤湿度传感器采集数据，经ESP32处理后通过LoRa（注意：此处为说明功耗对比，实际ESP32需外接LoRa模块）发送数据。初步测试发现，由于传感器上电稳定需要200ms，且ESP32在初始化Wi-Fi时默认开启射频校准，导致每次唤醒的平均电流高达45mA，预计续航仅22天。

经过分析，优化措施包括：1）将传感器供电改为GPIO控制，仅在采样前50ms上电；2）在ESP32中禁用Wi-Fi射频，改用BLE广播发送数据（功耗降低60%）；3）使用ESP32的ULP协处理器在睡眠期间定期唤醒RTC，替代主CPU定时器。优化后，每次唤醒的平均电流降至8.2mA，续航提升至约11个月，满足验收要求。

1.3 稳定性验收：长时间运行与异常恢复

核心原理：稳定性验收旨在验证系统在持续运行过程中不发生死机、重启、数据损坏或功能退化。ESP32作为TinyML平台，其稳定性挑战主要来自三个方面：内存管理（TFLite Micro的arena分配策略）、外设驱动（I2C/SPI总线上的设备热插拔）、以及无线协议栈（Wi-Fi重连时的资源泄漏）。验收标准通常包括：连续运行72小时无重启、异常输入不导致系统崩溃、断电重启后能自动恢复至正常工作状态。

测试方法：

• 长稳测试：使用自动化脚本控制设备执行典型工作负载，持续运行72小时以上，每5分钟记录一次系统状态（内存余量、任务栈高水位、错误计数）。
• 故障注入：通过软件模拟传感器断线、Wi-Fi信号消失、Flash写入失败等异常场景，观察系统是否能够通过看门狗或错误处理机制恢复正常。
• 内存泄漏检测：在ESP-IDF中启用CONFIG_HEAP_POISONING_COMPREHENSIVE选项，运行24小时后检查堆内存最小值是否低于初始值的5%。

// 内存监控示例代码（ESP-IDF）
#include "esp_heap_caps.h"
void monitor_task(void *arg) {
    while (1) {
        size_t free = heap_caps_get_free_size(MALLOC_CAP_8BIT);
        size_t min_free = heap_caps_get_minimum_free_size(MALLOC_CAP_8BIT);
        ESP_LOGI("MEM", "Free: %d, MinFree: %d", free, min_free);
        vTaskDelay(pdMS_TO_TICKS(5000));
    }
}

案例拆解：智能门锁指纹识别模块

某智能门锁项目在客户现场反馈“使用一周后指纹识别速度变慢，最终无法识别”。初步排查发现，TFLite Micro在每次指纹匹配时都会分配一块临时tensor arena，但未在推理结束后释放。随着匹配次数增加，堆内存碎片化加剧，导致后续推理因内存不足而失败。通过启用ESP-IDF的堆内存调试功能，定位到tflite::MicroInterpreter::Invoke()调用后存在约2KB的内存泄漏。修复方案是在每次推理前调用arena->Clear()重置内存池，并在固件中加入内存余量监控，当可用内存低于阈值时主动重启系统。

1.4 联网可靠性验收：无线链路的真实表现

核心原理：联网可靠性验收关注的是ESP32在真实无线环境中的通信质量，包括连接建立成功率、数据包传输成功率、往返时延（RTT）以及断线重连时间。与实验室的理想环境不同，实际场景中存在Wi-Fi信道拥挤、2.4GHz频段干扰（蓝牙、微波炉、ZigBee）、多路径衰落等问题。验收标准应基于业务需求制定：对于周期性上报数据的场景，允许偶发丢包但必须保证数据新鲜度；对于实时控制场景，则要求端到端时延小于100ms且丢包率低于0.1%。

测试方案设计：

案例拆解：商场导购机器人远程监控

某商场部署了20台导购机器人，每台机器人内置ESP32作为传感器数据采集和远程控制网关。验收时发现，在商场营业高峰期（11:00-14:00），机器人上报数据的丢包率高达15%，且部分机器人频繁掉线。通过频谱分析仪检测发现，商场内顾客手机的Wi-Fi热点和蓝牙设备造成了严重的2.4GHz频段拥塞。解决方案包括：1）将ESP32的Wi-Fi发射功率从19.5dBm提升至20.5dBm（需确认法规允许）；2）启用ESP32的Wi-Fi Agile Multiband功能，优先连接5GHz频段（需外接5GHz前端模块）；3）在固件中实现自适应重传机制，当连续3次发送失败时，将数据暂存至Flash，待网络恢复后补发。经过优化，丢包率降至0.8%，重连时间从平均25秒缩短至4秒。

1.5 综合验收评分模型与决策

在完成三大维度的独立测试后，需要将结果汇总为综合评分，以支持最终的交付决策。建议采用加权评分法，权重根据项目类型调整：对于电池供电的户外设备，功耗权重设为40%；对于实时控制类设备，稳定性权重设为50%；对于数据采集类设备，联网可靠性权重设为40%。每个维度得分采用百分制，并设置单项否决项——例如，若出现任何一次非预期重启，稳定性维度直接判定为0分。

评分计算示例：

综合得分 = 功耗得分 × 0.35 + 稳定性得分 × 0.40 + 联网可靠性得分 × 0.25
判定规则：
- 综合得分 ≥ 85分，且无单项否决项 → 通过验收
- 综合得分 70-84分，或有非关键缺陷 → 有条件通过，需限期整改
- 综合得分 < 70分，或存在单项否决项 → 不通过，需重新设计

在最终验收报告中，除了得分表外，还应包含测试环境描述、设备清单、原始数据附件、遗留问题清单及整改建议。报告应由测试工程师和QA共同签署，并提交给项目干系人确认。