4、任务模型分类：周期任务、偶发任务、非周期任务在TinyML中的表现形式与建模方法

TinyML系统的核心挑战在于，必须在有限的算力、内存和能量预算内，同时管理多个推理任务。这些任务并非随机到达，而是遵循特定的时间模式。理解并区分周期任务、偶发任务与非周期任务，是进行多模型调度设计的第一步。在实时系统理论中，任务模型决定了调度器的优先级分配策略、可调度性分析方式以及资源预留方案。在TinyML场景下，由于MCU（微控制器）通常没有完整的多线程操作系统，任务模型直接映射为对推理引擎调用时机、传感器数据采样频率以及电源管理策略的约束。本节将深入剖析这三类任务在嵌入式机器学习环境中的具体表现形式，并给出可操作的建模参数与方法。

4.1 周期任务：TinyML中最常见的确定性负载

核心原理：周期任务以固定的时间间隔（周期T）重复触发，每次触发需要在该周期内完成一次推理。在TinyML中，典型的周期任务包括：持续性的环境监测（温度、湿度、空气质量）、可穿戴设备的心率/步频分析、工业振动监测等。这类任务的最大特点是到达时间完全可预测，因此调度器可以提前规划CPU时间片和内存缓冲区。周期任务的实时性约束通常用利用率U = C/T表示，其中C为最坏情况执行时间（WCET）。当多个周期任务叠加时，总利用率必须小于1（单核），否则系统必然过载。

判断方法与建模流程：在TinyML工程中，判断一个任务是否为周期任务，需要观察其触发源。如果触发源是定时器中断或固定频率的传感器采样（如IMU以100Hz输出数据），则属于周期任务。建模时需采集以下参数：

• 周期T：由传感器采样率或业务需求决定，例如语音唤醒模型每50ms运行一次。
• 执行时间C：通过profiling工具（如ARM Cycle Counter）测量模型推理的最坏耗时，需考虑缓存未命中和内存带宽竞争。
• 截止时间D：通常D = T（隐含截止期），但若推理结果用于控制回路，D可能小于T。
• 抖动J：由于中断延迟或DMA传输引起的触发时间偏差，在建模时需预留5%-10%的余量。

// 周期任务建模示例（基于CMSIS-RTOS2）
osTimerId_t infer_timer;
void infer_callback(void *arg) {
    // 触发一次推理任务
    osThreadFlagsSet(infer_thread_id, INFER_TRIGGER);
}
// 创建100ms周期定时器
osTimerNew(infer_callback, osTimerPeriodic, NULL, &timer_attr);
osTimerStart(infer_timer, 100); // 周期T=100ms

案例拆解：以智能手表上的连续心率监测为例。传感器以25Hz采样PPG信号，每40ms产生一组数据。TinyML模型（一个轻量级CNN）在MCU上执行一次推理需要15ms（C=15ms），周期T=40ms，利用率U=37.5%。调度器将心率推理设为最高优先级，因为它是周期任务且截止时间紧迫。系统还运行一个每200ms执行一次的步数计数模型（C=20ms，U=10%）。两个周期任务的总利用率为47.5%，剩余52.5%的CPU时间留给非周期任务和系统空闲。通过固定优先级调度（RMS），心率任务优先级更高，其WCET 15ms远小于周期40ms，因此可调度性得到保证。

4.2 偶发任务：事件驱动但受最小间隔约束

核心原理：偶发任务（Sporadic Task）的到达时间不确定，但存在一个最小到达间隔（T_min），即两次任务触发之间的时间间隔不会小于该值。在TinyML中，偶发任务通常由外部事件触发，例如：关键词唤醒后的语音识别、异常检测触发后的详细分类、蓝牙连接建立后的数据解析。偶发任务与周期任务的关键区别在于：调度器无法预知下一次触发时间，但可以依据T_min进行最坏情况分析。偶发任务的利用率定义为U = C / T_min，这表示在极端情况下（每次都以最小间隔到达）系统需要承受的负载。

判断方法与建模流程：判断偶发任务需要分析事件源的性质。如果事件由物理世界产生（如振动冲击、人体动作），且物理上不可能在极短时间内重复发生，则适合建模为偶发任务。建模步骤包括：

1. 通过实验或数据手册确定最小事件间隔T_min。例如，机械按键的抖动消除后，最小间隔为50ms。
2. 测量事件处理程序的最坏执行时间C，包括数据预处理、推理和后处理。
3. 设定截止时间D，通常为事件发生到响应输出的最大允许延迟。
4. 在调度表中为偶发任务分配一个预算（Budget），防止其突发占用过多CPU。

案例拆解：考虑一个工业预测性维护系统。振动传感器持续监测，但只有当加速度超过阈值（如2g）时，才触发一个偶发的故障分类任务。根据机械特性，两次冲击的最小间隔为200ms（T_min=200ms），分类模型执行时间为30ms（C=30ms），截止时间为150ms（D=150ms）。系统还运行一个每50ms一次的FFT频谱分析周期任务（C=10ms）。调度器采用优先级继承协议：当偶发任务触发时，它被赋予高于周期任务的优先级，但受限于T_min，其最大CPU占用率为15%（30/200）。如果偶发任务在短时间内连续触发多次，调度器会将其放入待处理队列，并利用空闲时间片逐步处理，避免影响周期任务的截止时间。

4.3 非周期任务：无约束的异步事件

核心原理：非周期任务（Aperiodic Task）没有最小到达间隔约束，触发时间完全随机，且两次触发之间的间隔可能为零（即连续触发）。在TinyML中，典型的非周期任务包括：用户通过按键或手势触发的即时推理、通过BLE接收到的远程命令、调试接口的日志输出。非周期任务无法进行可调度性分析，因为其到达模式不可预测。因此，调度策略通常采用后台执行（Background Execution）或服务器机制（Server Mechanism），即只有在所有周期和偶发任务完成后，才执行非周期任务。

判断方法与建模方法：判断非周期任务的关键是确认事件源是否具有物理或协议上的最小间隔保证。如果没有，则视为非周期任务。建模时，不关注其到达率，而是关注：

• 最大执行时间C_max：用于确定需要预留的CPU预算。
• 可容忍延迟：非周期任务通常没有硬截止时间，但可能有软实时要求（如用户界面响应需在100ms内）。
• 优先级：通常设为最低，但可通过优先级提升机制在特定条件下临时提高。

案例拆解：在智能家居中枢设备中，用户通过触摸屏选择不同的场景模式（如“回家模式”、“离家模式”）。每次触摸触发一个非周期的场景识别任务，该任务需要运行一个图像分类模型（C_max=80ms）。系统同时运行着周期性的环境监测任务（T=200ms，C=20ms）和偶发的语音命令识别任务（T_min=500ms，C=50ms）。调度器将非周期任务设为最低优先级，并采用轮询服务器（Polling Server）策略：每100ms检查一次是否有待处理的非周期任务，若有则执行最多50ms。这样既保证了非周期任务的平均响应时间，又不会影响周期任务的截止时间。实测中，用户触摸到场景切换的平均延迟为120ms，满足交互要求。

4.4 任务分类对比与常见误区

常见误区一：将所有事件驱动任务都视为非周期任务。实际上，许多传感器事件（如振动、声音峰值）具有物理上的最小间隔，应建模为偶发任务，以便利用T_min进行可调度性分析，提高系统资源利用率。

常见误区二：忽略周期任务的抖动。在TinyML中，由于中断优先级和DMA竞争，周期任务的触发时间可能偏移。如果建模时忽略抖动，可能导致实际执行时间超过预留的时隙，引发级联延迟。

常见误区三：对非周期任务设置过高优先级。有些开发者为了响应速度，将用户交互任务设为高优先级，这会导致周期任务错过截止时间。正确做法是使用双优先级机制：平时非周期任务为低优先级，当检测到用户交互时，通过一个短时的优先级提升窗口（如50ms）来处理。

常见误区四：建模时只考虑CPU时间，忽略内存带宽和能量。在TinyML中，模型推理不仅消耗CPU，还占用Flash带宽（读取权重）和RAM（中间激活值）。两个任务即使CPU利用率不高，也可能因内存带宽竞争而互相延迟。建议在建模时增加内存利用率M = 模型大小 / 可用RAM和能量利用率E = 单次推理能耗 / 能量预算两个维度。

复盘总结：任务分类是TinyML多模型调度的基石。正确的分类能够帮助开发者选择合适的调度算法（RMS、EDF、服务器机制），进行可调度性验证，并合理分配内存和能量预算。在实际项目中，建议在系统设计初期就建立任务模型表，明确每个任务的类型、周期/最小间隔、WCET、截止时间和优先级。随着系统迭代，通过profiling工具持续更新WCET数据，确保调度分析的有效性。最终，三类任务的协同调度将实现TinyML设备在有限资源下的高效、稳定运行。