3、实时性概念：实时性定义、硬实时与软实时、端侧推理实时性关键指标

在HIL（硬件在环）验证TinyML端侧推理任务时，工程师最常遇到的困惑是：模型精度明明达标，为什么系统在真实工况下表现不稳定？这往往源于对"实时性"的理解停留在直觉层面。实时性不是"快"的同义词，而是对时间确定性（Temporal Determinism）的严格约束。本章将系统梳理实时性的定义、硬实时与软实时的本质区别，以及端侧推理场景下必须关注的三大关键指标——延迟、吞吐量与抖动，为后续章节的HIL测试用例设计奠定理论基础。

上图展示了实时性概念的核心框架：实时性定义是基础，硬实时与软实时是两种不同的约束类型，而延迟、吞吐量、抖动则是衡量端侧推理实时性的三个可量化维度。在HIL测试中，我们需要同时关注这三个指标，因为它们相互影响、相互制约。例如，提高吞吐量（增加批处理大小）可能会导致单次推理延迟增加；而降低抖动（采用更保守的调度策略）可能会牺牲一定的吞吐量。理解这些权衡关系，是设计有效HIL测试方案的前提。

3.1 实时性定义：从"快"到"确定性"

实时性（Real-Time）在计算机科学中的严格定义是：系统能够在规定的时间界限（Deadline）内完成特定任务，并且这种能力是可验证、可预测的。这里的关键词不是"快"，而是"确定性"（Determinism）。一个系统即使平均处理速度很快，但如果最坏情况下的响应时间不可控，它仍然不能被称为实时系统。

在TinyML端侧推理场景中，实时性意味着：从传感器数据采样开始，到推理结果输出并作用于执行器，整个过程必须在预定的时间窗口内完成。这个时间窗口通常由应用场景决定——电机控制可能需要1ms级别的响应，而工业缺陷检测可能允许100ms的延迟。HIL测试的核心任务之一，就是验证这种时间约束是否在所有工况下都能满足。

3.1.1 实时性的三个层次

从工程实践角度，实时性可以分解为三个层次，每个层次都有不同的验证重点：

• 硬件层实时性：MCU/MPU的时钟频率、中断响应时间、DMA传输延迟、缓存命中率等。这些是底层硬件特性，通常由芯片厂商提供数据手册，但实际表现受电路设计、电源质量、温度等因素影响，需要通过HIL测试实测。
• 软件层实时性：RTOS的任务调度策略、中断嵌套优先级、互斥锁等待时间、内存分配延迟等。TinyML推理框架（如TensorFlow Lite Micro）的运行机制也会引入不确定性，例如动态内存分配可能导致延迟波动。
• 应用层实时性：从传感器读取到推理输出再到执行器驱动的完整链路延迟。这是用户可感知的端到端延迟，也是HIL测试最关注的指标。

3.1.2 实时性判断方法

在HIL测试中，判断一个TinyML系统是否满足实时性要求，通常遵循以下流程：

1. 定义截止期：根据应用需求确定最大允许延迟（如10ms）。
2. 测量实际延迟分布：通过HIL平台注入不同负载，记录每次推理的完成时间。
3. 计算统计特征：获取平均延迟、P95延迟、P99延迟、最大延迟和标准差。
4. 对比截止期：如果最大延迟 ≤ 截止期，则满足硬实时要求；如果P95 ≤ 截止期但最大延迟超标，则可能满足软实时要求。
5. 压力测试：在CPU满载、内存紧张、中断频繁等极端条件下重复测试，确认WCET是否仍然满足要求。

3.2 硬实时与软实时：约束强度的分水岭

硬实时（Hard Real-Time）和软实时（Soft Real-Time）的根本区别在于：错过截止期的后果严重程度。这个区别直接决定了HIL测试的通过标准和测试方法。

对比维度	硬实时	软实时
错过截止期的后果	系统失效、安全事故、财产损失	性能下降、体验变差、数据丢弃
典型应用	安全气囊、刹车控制、飞行器姿态控制	视频监控、语音助手、工业视觉检测
HIL测试通过标准	100%测试用例满足截止期，零容忍	允许少量超时（如<1%），但需统计分布
设计策略	静态优先级调度、资源预留、WCET分析	动态调度、尽力而为、降级策略
验证方法	形式化验证+穷举测试	统计测试+压力测试

3.2.1 硬实时系统的HIL验证要点

对于硬实时TinyML系统（例如用于电机堵转检测的边缘AI），HIL测试必须采用确定性验证方法：

• 确定性调度验证：确认推理任务在RTOS中是否使用固定优先级，且高优先级任务不会被低优先级任务阻塞。
• 中断延迟测量：使用逻辑分析仪或示波器测量从中断触发到ISR开始执行的时间，确认小于系统设计值。
• 最坏情况注入：在HIL测试中人为制造最恶劣条件（如所有外设同时中断、内存碎片化），验证系统仍能满足截止期。

3.2.2 软实时系统的HIL验证要点

软实时系统（如基于TinyML的工业质检相机）允许偶尔的超时，但需要量化超时概率：

• 延迟分布统计：记录至少1000次推理延迟，计算P95、P99和最大延迟。
• 超时率评估：定义允许的超时比例（如0.1%），在HIL测试中统计实际超时率。
• 降级策略验证：当系统检测到持续超时时，是否能够自动降低推理频率或切换至简化模型。

3.3 端侧推理实时性关键指标：延迟、吞吐量、抖动

在HIL验证TinyML端侧推理时，延迟、吞吐量和抖动是三个必须同时测量的核心指标。它们从不同维度刻画了系统的实时性能，且相互之间存在复杂的耦合关系。

3.3.1 延迟（Latency）：单次推理的时间成本

延迟定义为从输入数据到达推理引擎到输出结果可用的时间间隔。在端侧推理中，延迟通常包括以下组成部分：

总延迟 = 传感器采样延迟 + 数据预处理延迟 + 模型推理延迟 + 后处理延迟 + 输出传输延迟

在HIL测试中，我们需要分别测量每个环节的延迟，并找出瓶颈所在。例如，一个图像分类任务的总延迟为15ms，其中传感器采样占2ms，预处理占3ms，模型推理占8ms，后处理占1ms，输出传输占1ms。此时，优化重点应放在模型推理环节。

延迟的统计特征比单一数值更有价值：

• 平均延迟（Mean Latency）：反映系统整体性能水平，但容易受极端值影响。
• P95/P99延迟：反映大多数情况下的体验，P99延迟是软实时系统的重要设计指标。
• 最大延迟（Max Latency）：决定硬实时系统是否满足截止期。

3.3.2 吞吐量（Throughput）：单位时间的处理能力

吞吐量表示系统在单位时间内能够完成的推理次数，常用FPS（Frames Per Second）或IPS（Inferences Per Second）表示。在TinyML场景中，吞吐量受以下因素影响：

• 模型计算量：MACs（乘加运算次数）越大，吞吐量越低。
• 硬件算力：MCU的主频、是否支持SIMD指令、NPU的MAC阵列大小。
• 批处理大小：批量推理可以提高吞吐量，但会增加单次延迟。
• 内存带宽：模型参数和中间特征图的读写速度。

在HIL测试中，吞吐量测试通常采用"持续运行法"：让系统连续处理输入数据流，记录在固定时间窗口（如60秒）内完成的推理次数，然后计算吞吐量。需要注意的是，吞吐量测试必须在系统满载条件下进行，否则结果会偏乐观。

3.3.3 抖动（Jitter）：时间确定性的度量

抖动定义为延迟的波动程度，通常用标准差（σ）或最大偏差（Max-Min）表示。低抖动意味着系统的时间行为高度可预测，这对于控制类应用至关重要。例如，一个PID控制回路如果推理延迟在5ms到15ms之间波动，即使平均延迟只有8ms，也可能导致控制震荡。

抖动的来源包括：

• 调度抖动：RTOS任务调度的时间不确定性。
• 缓存抖动：CPU缓存命中率变化导致的执行时间波动。
• 内存分配抖动：动态内存分配（malloc/free）的时间不确定性。
• 中断干扰：外部中断抢占CPU导致推理暂停。

3.3.4 三指标联合评估方法

在HIL测试中，不能孤立地优化单一指标。以下是一个联合评估的实用流程：

1. 确定应用需求：明确截止期（如20ms）、最小吞吐量（如30FPS）、最大抖动（如±2ms）。
2. 建立测试基准：在HIL平台上配置与目标硬件相同的MCU/NPU环境。
3. 多工况测试：分别在空闲、50%负载、满载条件下测量延迟、吞吐量和抖动。
4. 绘制性能曲线：以吞吐量为横轴，延迟为纵轴，绘制延迟-吞吐量曲线，观察拐点位置。
5. 抖动分析：计算不同负载下的抖动标准差，确认是否在可接受范围内。
6. 联合判定：只有当三个指标同时满足要求时，系统才通过HIL验证。

3.4 实战案例：工业缺陷检测TinyML系统的实时性验证

某电子制造企业计划部署一套基于TinyML的PCB缺陷检测系统，使用STM32H743（Cortex-M7, 480MHz）作为主控，搭载OV5640摄像头（30FPS输出），运行一个二值分类模型（输入96×96×3，模型大小约200KB）。系统要求：从摄像头采集到输出检测结果的总延迟 ≤ 50ms，吞吐量 ≥ 25FPS，抖动 ≤ ±5ms。

3.4.1 初始测试现象

在HIL测试平台上进行初步验证时，发现以下问题：

• 平均延迟为38ms，满足要求；但P99延迟达到62ms，超出50ms截止期。
• 吞吐量在空闲条件下为28FPS，但在系统同时处理UART通信和LED控制时降至22FPS。
• 抖动标准差为4.2ms，接近但未超过±5ms的限制。

3.4.2 分析过程

通过HIL平台的性能分析工具，我们采集了详细的延迟分布数据：

延迟分解（单位：ms）：
- 摄像头DMA传输：2.1 ± 0.3
- 图像预处理（缩放+格式转换）：5.8 ± 1.2
- 模型推理（TFLite Micro）：28.5 ± 3.8
- 后处理（阈值判断）：1.2 ± 0.2
- 结果输出（GPIO+UART）：0.4 ± 0.1
- 总延迟：38.0 ± 4.2

进一步分析发现，P99延迟超标的主要原因是：当UART中断频繁发生时，模型推理被多次打断，导致推理时间从平均28.5ms增加到45ms以上。此外，图像预处理环节使用了动态内存分配（malloc），在内存碎片化时延迟从5.8ms增加到12ms。

3.4.3 优化措施

针对上述问题，我们采取了以下优化措施：

1. 中断优先级调整：将UART中断优先级从高优先级（3）降至低优先级（7），确保推理任务不被频繁打断。
2. 静态内存分配：将图像预处理中的动态内存分配改为静态缓冲区，消除内存碎片化问题。
3. 推理任务优先级提升：在RTOS中将推理任务设为最高优先级（除ISR外），确保推理过程不被其他任务抢占。
4. DMA双缓冲：使用DMA双缓冲机制，让摄像头数据采集与推理并行执行，减少等待时间。

3.4.4 优化后结果

指标	优化前	优化后	变化
平均延迟	38.0ms	31.2ms	-17.9%
P99延迟	62ms	43ms	-30.6%
最大延迟	78ms	47ms	-39.7%
吞吐量（满载）	22FPS	27FPS	+22.7%
抖动标准差	4.2ms	2.1ms	-50%

优化后，所有指标均满足设计要求：P99延迟43ms < 50ms截止期，满载吞吐量27FPS > 25FPS要求，抖动标准差2.1ms < 5ms限制。系统通过了HIL验证。

3.4.5 复盘与经验

这个案例揭示了几个关键经验：

• 平均延迟具有欺骗性：如果只看平均延迟38ms，会误以为系统满足要求，但P99延迟暴露了真实风险。
• 中断管理是实时性的大敌：在TinyML系统中，频繁的中断会严重破坏推理任务的时间确定性。
• 动态内存分配应避免：在实时推理路径中，任何malloc/free操作都可能引入不可预测的延迟。
• HIL测试必须模拟真实负载：仅在空闲条件下测试无法发现吞吐量下降的问题。

3.5 常见误区与总结

在HIL验证TinyML端侧推理实时性时，工程师常犯以下错误：

• 误区一：只测平均延迟。平均延迟无法反映最坏情况，必须同时测量P95/P99和最大延迟。
• 误区二：忽略抖动。即使平均延迟满足要求，高抖动也会导致控制类应用不稳定。
• 误区三：在理想条件下测试。HIL测试必须模拟真实工况，包括中断负载、内存压力、温度变化等。
• 误区四：将吞吐量与延迟割裂。高吞吐量往往以牺牲延迟为代价，需要联合优化。
• 误区五：忽视硬件差异。同一模型在不同MCU上的实时性能差异可能超过10倍，HIL测试必须使用目标硬件。

总结而言，实时性是TinyML端侧推理系统设计的核心约束之一。在HIL验证中，我们需要从"时间确定性"的角度出发，同时关注延迟、吞吐量和抖动三个指标，并通过压力测试找出系统的最坏情况。硬实时系统需要零容忍的验证策略，而软实时系统则需要统计化的超时率评估。只有建立完整的实时性验证体系，才能确保TinyML系统在真实工况下可靠运行。