4、数据流处理基础：数据流的概念、窗口化、滑动窗口、实时处理与批处理的区别

TinyML振动异常检测的工程落地，本质上是对传感器持续产生的时序数据流进行实时或近实时的状态判别。与传统的“先采集、后分析”离线模式不同，嵌入式端的数据流处理要求我们在内存受限、算力有限、功耗敏感的条件下，以流式方式完成数据的接收、切分、特征提取和推理。理解数据流的基本概念、窗口化策略以及实时处理与批处理的本质差异，是设计高效振动检测系统的第一道门槛。本章将围绕这四个核心主题展开，帮助你在算法选型和系统架构设计时建立清晰的工程判断。

4.1 数据流的核心概念与TinyML场景特征

数据流（Data Stream）是指数据以连续、无限、随时间有序到达的序列形式存在。在振动检测场景中，加速度计以固定采样率（如 1kHz 或 3.2kHz）持续输出三轴加速度值，这些数值构成了典型的数据流。与静态数据集不同，数据流具有三个关键特性：无限性（理论上永不终止）、时效性（越新的数据价值越高）、易失性（无法全部存储，必须即时处理或选择性保存）。在TinyML设备上，内存通常只有几十KB到几百KB，因此不可能缓存全部历史数据，必须采用“边到边处理”的策略。

从工程角度看，振动数据流还具备以下特征：

• 高采样率与高维度：三轴加速度计在1kHz采样下每秒产生3000个数值，若每个数值以16位存储，每秒数据量约6KB，一分钟即360KB，远超MCU内存容量。
• 周期性成分明显：旋转机械的振动信号往往包含与转速相关的基频及谐波分量，这为频域特征提取提供了物理基础。
• 非平稳性：设备启停、负载变化、故障演化都会导致振动信号的统计特性随时间改变，要求处理算法具备适应性。

理解数据流的本质，有助于我们认识到：在TinyML振动检测中，“存储-分析”的传统范式必须让位于“流式-增量”的新范式。这意味着算法设计、内存分配、功耗管理都要围绕“持续运行”这一前提展开。

4.2 窗口化：将无限流切分为有限处理单元

窗口化（Windowing）是将无限数据流切分为有限长度数据块的核心技术。在振动检测中，窗口既是特征提取的基本单位，也是模型推理的输入单元。一个典型的窗口包含N个连续采样点，例如在1kHz采样率下，256个采样点对应256ms的时间跨度。窗口大小的选择直接影响检测的实时性和频率分辨率。

窗口大小的确定原则：

1. 频率分辨率需求：FFT的频率分辨率 = 采样率 / 窗口长度。若需要区分1Hz的相邻频率成分，在1kHz采样率下至少需要1000个采样点（1秒窗口）。
2. 故障特征周期：窗口应至少覆盖2-3个故障特征周期。例如轴承外圈故障特征频率为50Hz，则窗口至少应包含40ms（2个周期），建议80ms以上。
3. 实时性约束：窗口越长，首次检测延迟越大。对于需要快速响应的保护系统，窗口不宜超过500ms。
4. 内存限制：窗口数据需要暂存于RAM中，三轴数据窗口大小 = 窗口长度 × 3轴 × 2字节。256点窗口占用1.5KB，1024点窗口占用6KB。

4.3 滑动窗口的实现机制与内存管理

滑动窗口的典型实现方式是环形缓冲区（Ring Buffer）。在MCU上，我们预先分配一块连续内存作为缓冲区，通过读写指针的循环移动实现数据的覆盖更新。以256点窗口、64点步长为例：

// 环形缓冲区实现示例（伪代码）
#define WINDOW_SIZE 256
#define STEP_SIZE 64
int16_t buffer[WINDOW_SIZE];
uint16_t write_idx = 0;

// 每次采集到STEP_SIZE个新样本后调用
void update_window(int16_t new_samples[STEP_SIZE]) {
    for (int i = 0; i < STEP_SIZE; i++) {
        buffer[write_idx] = new_samples[i];
        write_idx = (write_idx + 1) % WINDOW_SIZE;
    }
    // 此时buffer中从write_idx开始的WINDOW_SIZE个数据即为最新窗口
    // 注意：实际使用时需按顺序读取，或使用双缓冲避免读写冲突
}

滑动窗口的关键优势在于时间连续性。当窗口以步长S滑动时，相邻两个窗口共享（W-S）个重叠样本。这种重叠确保了特征序列的平滑变化，避免因窗口边界导致的特征突变。例如，当设备转速缓慢上升时，滑动窗口能捕捉到振动幅值的渐进变化，而固定窗口则可能产生阶梯状跳变。

在内存管理上，需要注意：

• 对齐问题：若使用DMA进行数据搬运，缓冲区地址需按DMA要求对齐（通常4字节或8字节对齐）。
• 缓存一致性：在带Cache的高性能MCU上，需注意DMA与CPU之间的缓存同步问题。
• 低功耗设计：窗口滑动过程中，CPU可以进入休眠，由DMA完成数据搬运，仅在窗口满时唤醒执行特征提取和推理。

4.4 实时处理与批处理的本质区别

实时处理（Real-time Processing）与批处理（Batch Processing）在TinyML振动检测中代表两种截然不同的系统设计哲学。理解它们的区别，有助于我们根据应用场景做出正确的架构选择。

在TinyML振动检测系统中，实时处理是主路径，批处理是辅助路径。实时处理负责持续监测和即时报警，而批处理则用于定期生成诊断报告、更新模型参数或进行深度频谱分析。两者可以共存于同一系统中：MCU上的实时推理负责快速判定，而边缘网关或云端服务器上的批处理则进行更精细的分析。

4.5 案例拆解：电机轴承故障监测的数据流设计

我们以一个实际的电机轴承故障监测项目为例，完整展示数据流处理的设计过程。

项目背景与约束：某工厂的离心泵电机（转速2970rpm，约49.5Hz）需要加装振动监测系统。系统使用STM32L4系列MCU（主频80MHz，RAM 64KB），外接三轴加速度计（采样率4kHz，量程±16g）。要求：检测轴承外圈故障（特征频率约3.5倍转频，即173Hz），报警延迟不超过200ms，误报率低于1次/月。

初始现象与目标：电机在正常运行时的振动加速度RMS值约0.8g，轴承早期故障时RMS值升至1.5g，且173Hz处出现明显峰值。目标是在RMS值超过1.2g或173Hz幅值超过0.3g时触发报警。

关键参数计算：

• 采样率fs = 4kHz，窗口长度W = 1024点（256ms），频率分辨率 = 4000/1024 ≈ 3.9Hz，可清晰分辨173Hz分量。
• 滑动步长S = 256点（64ms），等效检测周期64ms，满足200ms延迟要求。
• 内存占用：三轴窗口数据 = 1024 × 3 × 2字节 = 6KB，加上特征值缓存和模型参数，总RAM占用约15KB，在64KB预算内。

实施步骤：

1. 配置ADC以4kHz采样率连续采样三轴数据，通过DMA搬运至环形缓冲区。
2. 每采集256个新样本（64ms），触发一次中断，执行窗口更新。
3. 从环形缓冲区提取最新1024点窗口数据，计算RMS值和FFT（仅需计算0-500Hz范围）。
4. 将RMS值和173Hz幅值输入轻量级决策树模型（或阈值判断），输出正常/异常/预警状态。
5. 若判定为异常，立即通过GPIO触发报警灯，并通过UART上报状态。

结果对比与复盘：系统实际运行3个月，成功捕获2次轴承早期故障（均在RMS值超过1.2g后64ms内报警），无误报。相比原有人工巡检方案（每2小时一次），故障发现时间从平均1.5小时缩短至200ms以内。复盘发现，滑动窗口的重叠设计使得特征曲线平滑，避免了因窗口边界导致的误判；而固定窗口方案在相同条件下产生了约3次/月的误报，原因是窗口切换时特征值跳变过大。

4.6 常见误区与总结复盘

在数据流处理的实际工程中，以下误区值得特别注意：

• 误区一：窗口越大越好。虽然大窗口提供更好的频率分辨率，但增加了内存占用和计算延迟。在TinyML场景中，应优先满足实时性约束，再考虑频率分辨率。
• 误区二：忽略窗口重叠的计算开销。滑动窗口虽然检测效果好，但每次滑动都需要重新计算特征。若步长过小（如1个样本），计算量将急剧增加。建议步长不小于窗口长度的10%。
• 误区三：将批处理算法直接移植到流式环境。例如，标准的FFT算法需要完整窗口数据，而流式FFT（如滑动DFT）可以增量更新，但实现复杂度更高。在资源受限时，可考虑分帧FFT或Goertzel算法。
• 误区四：忽视数据流的时间戳管理。在多传感器同步或数据上传时，时间戳不一致会导致特征错位。建议在数据流中嵌入采样计数或时间戳字段。