2、基础知识：TinyML系统架构、嵌入式资源约束、稳定性测试的定义与核心指标

TinyML 的稳定性测试并非简单的“跑一跑看会不会死机”，它建立在对系统架构、资源边界和失效模式的深刻理解之上。与云端 AI 推理不同，TinyML 设备通常以单片机（MCU）为核心，运行在电池供电、无操作系统或轻量级 RTOS 的环境中，任何内存越界、外设挂死或电源跌落都可能导致设备永久失联。本章将系统梳理 TinyML 系统的典型架构分层、嵌入式环境的资源约束本质，并给出稳定性测试的准确定义与可量化的核心指标，为后续章节的测试方案设计奠定理论基础。

2.1 TinyML 系统架构：从传感器到决策的三层链路

TinyML 系统的硬件架构通常可以抽象为三个核心层次：感知层、处理层和执行层。理解这一分层是稳定性测试设计的前提，因为每一层都有其独特的失效模式，而层与层之间的接口往往是故障的高发地带。

感知层负责将物理世界的模拟信号转换为数字量。常见的传感器包括温湿度传感器（如 SHT30）、六轴惯性测量单元（如 MPU6050）、数字麦克风（如 ICS43432）以及光电传感器等。这些传感器通过 I2C、SPI 或单总线协议与 MCU 通信。在稳定性测试中，感知层最典型的故障是传感器寄存器配置丢失导致的数据漂移，以及 I2C 总线在异常时序下产生的总线锁死（Bus Hang）。例如，当传感器在 MCU 读取过程中突然断电再上电，其内部状态机可能进入未知状态，导致后续所有读写操作无响应。

处理层是 TinyML 的核心，通常由一颗主频在 80MHz 至 240MHz 之间的 Cortex-M 系列 MCU 构成。该层运行着轻量级推理框架（如 TensorFlow Lite for Microcontrollers）、特征提取算法以及应用逻辑。处理层的资源约束最为严苛：Flash 通常在 256KB 到 2MB 之间，RAM 通常在 64KB 到 512KB 之间。由于 TinyML 模型通常以静态数组形式存放在内存中，任何动态内存分配（malloc/free）行为都应被严格限制或完全避免。处理层的稳定性风险主要来自递归调用导致的栈溢出、全局缓冲区越界写入，以及推理引擎内部状态在异常输入下的不可恢复错误。

执行层将推理结果转化为物理动作或通信数据。典型的执行器包括 GPIO 控制的 LED 指示灯、PWM 驱动的蜂鸣器、继电器开关，以及 BLE 或 LoRa 无线模块。执行层的稳定性问题往往表现为外设驱动在长时间运行后进入异常状态，例如 UART 的 FIFO 溢出后未正确清空导致后续所有数据帧错位，或者无线模块在信号干扰下进入不可恢复的掉线状态。

三层之间通过中断、DMA 或轮询方式交互。在稳定性测试中，需要特别关注中断优先级配置不当导致的中断丢失，以及 DMA 缓冲区在 CPU 访问与 DMA 写入之间的竞争条件（Race Condition）。

2.2 嵌入式资源约束：稳定性测试的边界条件

与桌面或服务器环境不同，TinyML 设备的资源约束是且不可扩展的。这些约束直接决定了稳定性测试的策略和通过标准。

资源类型	典型范围	对稳定性测试的影响
Flash 存储	256KB - 2MB	代码段 + 模型权重 + 只读数据；无法容纳冗余备份，固件损坏即设备变砖
RAM 内存	64KB - 512KB	静态分配为主；栈空间通常仅 2KB - 8KB，递归或深层调用极易溢出
CPU 主频	80MHz - 240MHz	推理时延敏感；长时间高负载导致温度升高，影响时钟稳定性
电源供给	电池 3.0V - 4.2V	电压跌落会导致 Flash 写入失败、传感器读数异常、无线模块重启
外设接口	I2C / SPI / UART	总线无内置超时机制，一旦从设备无响应，主控可能永久阻塞

在稳定性测试中，资源约束意味着我们不能简单地通过增加日志缓冲区或开启更多调试功能来观察系统状态。例如，在 RAM 仅有 128KB 的设备上，一个完整的日志系统可能占用 16KB 以上的内存，这会显著改变系统的内存布局和栈深度，导致测试结果失真。因此，稳定性测试通常采用“最小侵入”原则：使用 MCU 内置的硬件调试接口（如 SWD）读取实时变量，或者通过一个专用的调试 UART 口输出精简的状态码，而不是在目标代码中嵌入大量日志打印。

另一个关键约束是时间确定性。TinyML 推理任务通常有严格的时延要求（例如每 100ms 完成一次推理）。在稳定性测试中，我们需要验证在长时间运行后，推理时延是否仍然满足要求。由于 MCU 没有操作系统或仅有轻量级 RTOS，任务调度的不确定性（如中断频繁抢占）可能导致推理时延出现抖动。测试时需要记录时延的最大值、平均值和标准差，而不仅仅是平均值。

2.3 稳定性测试的定义与核心指标

稳定性测试（Stability Testing）在 TinyML 语境下，是指通过模拟或加速设备在真实运行环境中的压力条件（长时间连续运行、温度变化、异常复位等），验证系统在预定生命周期内保持功能正确、性能达标且不出现永久性失效的能力。它不同于功能测试（验证“做不做”），也不同于性能测试（验证“快不快”），而是关注“持久且可靠地做”。

以下是 TinyML 稳定性测试的四个核心量化指标：

• 内存泄漏率（Memory Leak Rate）：对于使用动态内存分配的系统，内存泄漏表现为堆可用空间随时间单调递减。对于 TinyML 系统，即使采用静态分配，也可能存在“逻辑泄漏”——例如，一个环形缓冲区在异常情况下未正确释放读指针，导致有效数据空间逐渐减少。测试方法是在固定时间间隔（如每小时）记录一次堆剩余空间或关键缓冲区的水位，绘制趋势线。若斜率不为零，则判定存在泄漏。
• 看门狗超时次数（Watchdog Timeout Count）：看门狗是 MCU 内部或外部的硬件定时器，必须在规定时间内被软件“喂狗”（清零），否则系统强制复位。看门狗超时次数直接反映了系统卡死或死循环的发生频率。在稳定性测试中，通过读取看门狗复位标志寄存器（如 STM32 的 RCC_CSR 寄存器）来累计复位次数。理想情况下，长时间测试（如 72 小时）内该计数应为 0。
• 复位计数（Reset Count）：系统复位分为上电复位、看门狗复位、外部引脚复位和软件复位。通过读取复位状态寄存器，可以区分复位来源。如果看门狗复位次数持续增加，说明系统存在未处理的异常路径；如果外部复位频繁，则需检查电源或复位电路设计。
• 温度漂移率（Temperature Drift Rate）：在温度变化环境下，传感器的零点偏移、ADC 参考电压的温漂以及 MCU 内部振荡器的频率漂移都会影响推理结果的准确性。温度漂移率定义为：在单位温度变化下，关键输出参数（如分类置信度、回归预测值）的变化量。测试需要在温控箱中执行 -20°C 至 +60°C 的循环，并记录每个温度点的输出偏差。

2.4 实战场景：智能温控节点的 72 小时稳定性评估

下面通过一个具体的案例来展示上述指标如何在实际项目中落地。假设我们开发了一个基于 STM32L4 系列 MCU 的智能温控节点，它每 500ms 读取一次温湿度传感器（SHT30），运行一个 20KB 的神经网络模型判断“舒适/偏热/偏冷”三档状态，并通过 LoRa 模块每 30 秒上报一次结果。

初始现象与目标：在实验室常温（25°C）下，设备功能正常。但客户反馈在工业现场（环境温度约 40°C）运行 3 天后，部分设备出现“死机”现象，断电重启后恢复。我们的目标是通过稳定性测试复现问题并定位根因。

测试设计与关键数据：

1. 将 5 台设备放入温控箱，设定温度循环：-10°C（保持 2 小时）→ 25°C（保持 2 小时）→ 60°C（保持 2 小时），循环 12 次（共 72 小时）。
2. 每台设备通过 SWD 接口连接调试器，每 10 分钟记录一次：堆剩余字节数、看门狗复位计数、复位源寄存器值、LoRa 上报成功率。
3. 在 60°C 阶段，使用热风枪对 MCU 局部加热至 85°C（模拟极端工况），观察是否触发复位。

分析判断过程：测试进行到第 30 小时（第二次 60°C 循环）时，设备 #3 的 LoRa 上报成功率从 99% 骤降至 60%，同时看门狗复位计数从 0 跳变为 3。读取复位源寄存器，发现均为 IWDG（独立看门狗）复位。进一步查看堆剩余字节，发现从初始的 24.5KB 缓慢下降至 23.8KB，虽然下降幅度不大，但趋势线斜率为负，提示存在轻微内存泄漏。

实际操作步骤：我们首先通过调试器在 LoRa 发送函数入口和出口设置断点，发现当温度超过 70°C 时，LoRa 模块的 SPI 通信偶尔返回超时错误。而代码中的错误处理逻辑是：若发送失败，则重试 3 次；若仍失败，则丢弃数据并返回。问题在于，重试期间 CPU 处于阻塞等待状态，导致主循环中的喂狗操作被延迟超过 1 秒（看门狗超时设置为 1.5 秒）。在高温下，LoRa 模块的 SPI 时钟频率因温漂而略微偏移，增加了通信错误概率，最终触发了看门狗复位。

结果对比与修复：修复方案是将 LoRa 发送改为非阻塞模式（使用 DMA + 中断回调），并在等待期间允许喂狗操作执行。同时，将 SPI 通信超时时间从 100ms 缩短至 50ms，并增加总线恢复机制（连续 3 次失败则重新初始化 SPI 外设）。修改后重新进行 72 小时测试，看门狗复位计数为 0，LoRa 上报成功率恢复至 99.8%，堆剩余字节趋势线斜率为零。

风险与代价：非阻塞发送增加了代码复杂度，需要处理 DMA 中断与主循环的并发访问。此外，缩短 SPI 超时时间在极端低温下可能导致误判，因此需要在 -20°C 下额外验证 24 小时。

2.5 总结复盘：稳定性测试的工程要点

本章的基础知识为后续章节的测试方案设计提供了理论框架。在实际项目中，需要牢记以下要点：

• 架构决定测试策略：感知层重点测试总线抗干扰和传感器重初始化；处理层重点测试内存边界和推理引擎的鲁棒性；执行层重点测试外设驱动在异常后的恢复能力。
• 资源约束是硬边界：测试代码本身不能显著改变系统的内存和时间特性。优先使用硬件调试接口和轻量级状态码，避免在目标固件中嵌入重型日志。
• 指标必须可量化：内存泄漏率、看门狗超时次数、复位计数和温度漂移率是四个基础指标。根据具体应用，还可以增加“无线通信丢包率”、“传感器数据有效帧率”等业务级指标。
• 温度与复位是孪生问题：高温往往导致通信时序错误，而通信阻塞又可能触发看门狗复位。测试时需将温度循环与异常复位注入结合进行，才能暴露真实故障链路。