4、事件触发推理概念：事件驱动架构、触发源与推理触发策略

在TinyML设备的实际部署中，功耗预算往往被限制在毫瓦甚至微瓦级别。若系统持续以固定频率采集传感器数据并执行推理，大部分能量将消耗在“无事件发生”的空转时段。事件触发推理（Event-Driven Inference）正是为解决这一矛盾而设计的范式：系统默认处于低功耗待机状态，仅在特定事件发生时被唤醒并执行推理任务。本章将系统阐述事件驱动架构的基本组成、三类典型触发源的特征与选择方法，以及连续推理与事件触发推理的对比与融合策略。

上图展示了事件触发推理系统的完整链路：左侧为三类触发源，中间为事件检测与仲裁模块，右侧为推理引擎，底部为低功耗待机状态。系统在无事件时处于深度睡眠，一旦触发源产生有效事件，MCU被唤醒并执行推理，完成后再次回到待机。这一架构的核心在于“用事件代替轮询”，从而将功耗集中在真正需要计算的时刻。

4.1 事件驱动架构的核心原理

事件驱动架构（Event-Driven Architecture, EDA）在TinyML中的本质是“状态机+异步中断”的组合。系统被划分为两个明确的运行域：事件等待域和事件处理域。在事件等待域中，CPU核心时钟关闭，仅保留必要的唤醒源（如RTC、GPIO中断控制器、DMA通道）和少量RAM以维持上下文。当触发条件满足时，硬件自动完成唤醒序列，将CPU从低功耗模式恢复至运行模式，并跳转到预设的中断服务程序（ISR）或事件回调函数。

与传统的轮询架构相比，事件驱动架构有三个关键设计原则：

• 中断优先于轮询：所有触发源必须能够产生硬件中断，而非依赖软件循环查询状态寄存器。硬件中断的响应延迟通常在微秒级，而轮询的延迟取决于循环周期，可能达到毫秒级甚至更高。
• 事件最小化处理：ISR中只做必要的上下文保存、事件标志置位和快速数据搬运（如将传感器FIFO数据拷贝到SRAM），复杂的特征提取和模型推理应放在主循环或低优先级任务中执行，避免阻塞中断响应。
• 确定性唤醒路径：从事件发生到推理启动的延迟必须可预测。这要求唤醒源配置、时钟切换时间、电源域稳定时间等参数在系统设计阶段就进行精确测量和文档化。

事件驱动架构的另一个重要方面是事件与任务的解耦。触发源只负责“通知”系统有事件发生，而具体执行什么推理、如何处理结果，由上层应用逻辑决定。这种解耦使得系统可以灵活应对多种触发源组合，例如“传感器中断+定时器超时”共同决定是否执行一次完整的推理。

4.2 三类触发源的特性与选择

触发源的选择直接决定了系统的功耗基线和响应能力。下表对比了TinyML中三类主要触发源的电气特性、适用场景和典型配置参数：

触发源类型	典型硬件接口	唤醒延迟	待机功耗贡献	适用场景	关键配置参数
传感器中断	GPIO外部中断、INT引脚	1-10 µs	传感器自身功耗（µA级）	运动检测、振动、接近感应、声音事件	触发阈值、去抖时间、中断锁存
定时器	RTC、低功耗定时器（LPTIM）	10-100 µs	定时器外设功耗（<1 µA）	周期性环境采样、超时补偿、心跳检测	周期值、自动重载、闹钟匹配
外部信号	UART RX、SPI CS、I2C地址匹配、无线唤醒	50 µs - 1 ms	通信外设待机功耗（数µA）	上位机命令、无线配置、按键交互	波特率、地址过滤、唤醒前导码

传感器中断是最常用的触发源，尤其适用于物理量突变场景。现代智能传感器（如BMI270、LIS2DW12）内置可配置阈值比较器和FIFO缓冲区，当加速度幅值超过设定阈值或FIFO半满时，通过INT引脚输出脉冲唤醒MCU。选择传感器中断时需注意：

1. 阈值设置：阈值过低会导致频繁唤醒，增加平均功耗；阈值过高则可能漏检真实事件。建议根据应用场景的物理特性进行统计，例如人体活动检测的加速度阈值通常设为±1.5g，而工业振动监测可能需要±5g。
2. 去抖与滤波：机械开关或电磁干扰可能产生毛刺，需要在传感器端或MCU端配置去抖滤波器（通常为1-10ms）。去抖时间过长会增加事件响应延迟，需权衡。
3. FIFO批量处理：对于高频采样（如音频），建议使用传感器FIFO积累一定量数据后再触发中断，避免每次采样都唤醒MCU。例如，16kHz采样率下，FIFO深度为32时，中断频率降至500Hz，功耗显著降低。

定时器触发适用于需要周期性确认状态的场景，如环境监测节点每10秒采集一次温湿度。定时器触发的优势在于功耗完全可控，但无法响应异步事件。实际系统中，定时器常作为“补偿机制”与传感器中断配合使用：当传感器中断过于频繁或长时间无中断时，定时器强制唤醒系统执行一次状态检查。

外部信号触发主要用于系统间通信。例如，边缘网关通过UART发送命令唤醒传感器节点进行数据上报；或使用Sub-GHz无线模块的唤醒前导码（Wake-on-Radio）实现远程触发。这类触发源的功耗开销主要在通信外设的监听状态，需根据通信频率和占空比进行优化。

4.3 推理触发策略：连续推理 vs 事件触发推理

推理触发策略决定了系统“何时计算”的根本问题。连续推理（Continuous Inference）指MCU以固定频率（如10Hz）周期性地采集数据并执行模型推理，无论环境是否发生变化。事件触发推理则仅在检测到特定事件后才启动推理流程。两种策略的对比见表4-2：

对比维度	连续推理	事件触发推理
平均功耗	高（推理功耗×频率）	低（待机功耗为主）
响应延迟	固定（≤1/频率）	事件发生后立即响应（µs级）
事件丢失风险	低（持续采样）	中（取决于触发源灵敏度）
计算资源占用	高（CPU持续活跃）	低（大部分时间休眠）
适用场景	数据流稳定、需要完整时间序列	稀疏事件、突发性物理量变化
典型功耗比	基准（1×）	0.01× ~ 0.1×

选择触发策略时，需考虑三个核心问题：事件稀疏度（单位时间内有效事件的数量）、推理成本（单次推理的能耗和时间）、业务容忍度（漏检或误检的代价）。

对于事件稀疏度极低的应用（如工业设备故障监测，一天仅几次异常），事件触发推理可将功耗降低2-3个数量级。但对于需要连续追踪信号波形的应用（如心电图分析），事件触发可能导致关键特征丢失，此时应选择连续推理或“事件触发+数据缓冲”的混合方案。

混合策略（Hybrid Strategy）是工程实践中的常见折中：系统以较低频率（如1Hz）进行“粗检测”推理，当粗检测发现异常趋势时，切换到高频连续推理模式进行精细分析。这种策略既保持了低功耗基线，又能在关键时刻提供完整的数据支持。

4.4 案例拆解：智能门磁传感器的触发策略设计

下面通过一个完整的智能门磁传感器案例，展示事件触发推理策略的工程落地过程。

背景与约束：某智能家居项目需要设计一款门窗状态传感器，要求使用CR2032纽扣电池（标称容量220mAh）供电，目标工作寿命≥2年。传感器需检测门窗的开关状态，并在状态变化时通过BLE上报。此外，还需每5分钟上报一次心跳包以确认设备在线。MCU选用Nordic nRF52832（Cortex-M4F），加速度传感器选用LIS2DW12（内置运动检测和FIFO）。

初始方案与问题：第一版设计采用连续推理策略，MCU以10Hz频率读取加速度数据并运行一个简单的阈值判断模型。实测平均电流为450µA，计算得电池寿命仅为220mAh / 0.45mA ≈ 489小时 ≈ 20天，远低于2年目标。

关键参数分析：通过电流分析仪（如Joulescope）测量，发现系统功耗分布为：MCU活跃（10Hz采样+推理）占85%，BLE广播占10%，待机仅占5%。进一步分析发现，门窗状态变化每天仅约20次，每次变化持续约2秒，其余时间传感器数据几乎无变化。

策略重构：将系统改为事件触发推理架构：

1. 传感器中断触发：配置LIS2DW12的运动检测功能，当加速度变化超过阈值（±0.5g）时，通过INT1引脚唤醒MCU。同时启用FIFO模式，每次触发保存前后各16个采样点（共32点，采样率50Hz），用于后续状态判断。
2. 定时器补偿：使用RTC定时器每5分钟唤醒MCU一次，发送心跳包并检查传感器状态。若发现传感器FIFO中有未处理的数据（可能因中断丢失），则补做一次状态判断。
3. 外部信号：BLE连接事件作为外部触发源，当手机APP连接时，立即唤醒MCU执行一次状态确认并上报。

实施步骤：

// 伪代码示例：事件触发推理主循环
void main_loop() {
    while(1) {
        // 进入低功耗模式，等待事件
        __WFE();
        
        // 检查唤醒源
        if (int1_flag) {  // 传感器中断
            read_fifo_data();
            extract_features();
            run_inference();  // 判断门窗状态
            if (state_changed) {
                ble_send_notification();
            }
            int1_flag = 0;
        }
        
        if (rtc_flag) {  // 定时器心跳
            send_heartbeat();
            check_fifo_leftover();
            rtc_flag = 0;
        }
        
        if (ble_flag) {  // 外部BLE命令
            handle_ble_command();
            ble_flag = 0;
        }
    }
}

结果对比：优化后系统平均电流降至12µA（待机8µA + 事件处理等效4µA），计算电池寿命为220mAh / 0.012mA ≈ 18333小时 ≈ 2.1年，满足设计目标。事件响应延迟从原来的100ms（轮询周期）降至5ms（中断唤醒+快速处理）。

风险与代价：事件触发方案引入了传感器阈值误触发的风险。例如，强风导致门窗轻微振动可能触发误判。解决方案是在传感器端增加去抖（设置20ms的稳定时间），并在MCU端增加二次确认逻辑（连续两次触发才判定为状态变化）。此外，若传感器中断引脚被噪声持续触发，可能导致系统无法进入深度睡眠，需在固件中增加“连续触发次数限制”的保护机制。

复盘经验：本案例的核心教训是“先测量，后优化”。通过电流分析仪精确测量各模块功耗，才能确定功耗瓶颈在推理频率而非BLE通信。事件触发策略并非万能，它依赖于对应用场景事件稀疏度的准确评估。对于事件频繁的场景（如振动监测），事件触发可能退化为连续推理，此时应重新评估传感器阈值和FIFO深度。

4.5 常见误区与设计要点

在事件触发推理系统的设计中，工程师常陷入以下误区：

• 误区一：所有外设都必须关闭才能省电。实际上，某些外设（如DMA、传感器FIFO）在低功耗模式下仍可工作，合理利用它们可以进一步降低唤醒频率。例如，让DMA在后台将传感器数据搬运至内存，仅在缓冲区满时唤醒CPU。
• 误区二：中断服务程序越短越好，因此把所有逻辑都放到主循环。这可能导致事件标志被覆盖或丢失。正确做法是ISR中设置标志并拷贝关键数据，主循环中处理数据，但需确保主循环的轮询周期小于事件发生的最小间隔。
• 误区三：忽略唤醒源配置的初始化顺序。在进入低功耗模式前，必须确保所有唤醒源已正确配置并使能，否则可能导致系统无法唤醒。建议在进入睡眠前执行一次“唤醒源自检”，确认EXTI、RTC等寄存器状态。
• 误区四：只关注平均功耗，忽略峰值电流。事件触发瞬间的电流尖峰（如传感器FIFO读取+模型推理）可能达到数十毫安，若电源设计不当，可能导致电压跌落和系统复位。需在电源端增加足够的去耦电容（建议100µF+1µF+100nF组合）。

事件触发推理不是简单的“中断+睡眠”组合，而是一种系统级的功耗-响应权衡设计。工程师需要深入理解触发源的物理特性、MCU的低功耗模式细节以及应用场景的事件统计规律，才能构建出既省电又可靠的TinyML系统。在实际项目中，建议先使用开发板和电流分析仪建立功耗基线，再逐步引入事件触发机制，每一步都验证功耗和响应延迟的变化，避免“一刀切”式的架构替换。