3、告警系统需求分析：告警场景分类与功能/非功能需求
TinyML边缘告警系统的核心价值在于：在资源受限的嵌入式设备上，通过轻量级机器学习模型实现本地化的实时感知与决策，并将告警结果通过通信模块上报。要设计出真正可落地的系统，首先必须完成需求分析——明确系统要识别哪些异常、在什么约束条件下工作、以及如何权衡实时性、功耗与可靠性。本章将系统梳理告警场景的分类方法，并深入拆解功能需求与非功能需求，为后续的模型选型、任务调度和通信协议设计奠定基础。
3.1 告警场景分类：从感知对象到决策逻辑
告警场景的分类决定了传感器选型、模型输入特征、推理频率和通信策略。在TinyML边缘告警系统中，场景分类的核心依据是感知对象的物理量变化模式和告警触发的语义。不同场景对实时性、误报容忍度和功耗预算的要求差异显著，因此分类是需求分析的第一步。
3.1.1 异常检测：面向连续物理量的状态偏离
异常检测关注设备或环境在正常运行状态下的统计偏离。典型应用包括工业电机温度超限、管道压力波动、环境温湿度突变等。这类场景的特点是：数据为连续时间序列，正常状态有明确的统计分布（均值、方差），异常表现为分布偏移或趋势突变。在TinyML实现中，通常采用轻量级自编码器或孤立森林模型，输入为滑动窗口内的传感器采样序列，输出为异常分数。关键设计参数包括窗口长度（通常为50-200个采样点）、异常阈值（通过训练集分位数确定）和检测延迟容忍度（一般允许1-5秒）。
3.1.2 入侵检测：面向空间事件的即时响应
入侵检测关注空间中的突发性事件，如人体闯入、车辆越界、动物入侵等。与异常检测不同，入侵检测要求极高的时间敏感性和较低的误报率。传感器通常采用PIR（被动红外）、毫米波雷达或摄像头（经量化后的低分辨率图像）。模型需要区分“人”与“动物”、“车辆”与“树木晃动”等易混淆目标。在边缘设备上，常用MobileNetV2或微型YOLO的量化版本，推理帧率需达到5-10 FPS以上。通信策略上，入侵告警通常要求立即上报，且需要附带置信度分数和事件时间戳。
3.1.3 设备监控：面向长期趋势的预测性维护
设备监控侧重于长期健康状态评估，而非瞬时异常。典型场景包括电机轴承磨损、电池容量衰减、光伏板效率下降等。这类场景的数据采样频率较低（每分钟或每小时一次），但需要长期存储趋势数据。TinyML模型通常执行回归或分类任务，输出设备健康指数（0-100）或剩余使用寿命（RUL）区间。告警触发条件往往是“健康指数连续N次低于阈值”或“趋势斜率超过设定值”，而非单次超限。通信上，设备监控告警可以容忍分钟级延迟，但要求数据完整性和可追溯性。
| 维度 | 异常检测 | 入侵检测 | 设备监控 |
|---|---|---|---|
| 感知对象 | 连续物理量（温度、振动） | 空间事件（人体、车辆） | 设备状态（磨损、衰减） |
| 数据特征 | 时间序列，统计分布 | 图像/雷达点云，空间特征 | 低频采样，长期趋势 |
| 典型模型 | 自编码器、孤立森林 | 量化CNN、微型YOLO | LSTM、线性回归 |
| 推理频率 | 1-10 Hz | 5-30 FPS | 0.01-0.1 Hz |
| 告警延迟容忍 | 1-5秒 | <1秒 | 分钟级 |
| 误报代价 | 中等（需人工确认） | 高（安全事件） | 低（可复查趋势） |
3.2 功能需求：从数据采集到告警上报的完整链路
功能需求定义了系统必须做什么，是系统设计的“功能清单”。在TinyML边缘告警系统中，功能需求贯穿数据采集、预处理、推理、决策、通信五个环节。每个环节都有其特定的设计约束和实现要点。
3.2.1 数据采集与预处理功能
系统必须支持多类型传感器接入（数字/模拟、I2C/SPI/GPIO），并具备基本的信号调理能力。预处理功能包括：去直流偏置、带通滤波（如50Hz工频陷波）、归一化（将原始ADC值映射到0-1范围）、以及滑动窗口缓存。在资源受限的MCU上，预处理需使用定点运算或查表法替代浮点运算。例如，对于加速度计数据，可使用IIR滤波器（一阶低通，截止频率5Hz）来消除高频噪声，代码实现如下：
// 一阶IIR低通滤波器，截止频率约5Hz，采样率100Hz
float alpha = 0.24f; // alpha = 1/(1+2*PI*5/100)
float filtered = alpha * raw + (1 - alpha) * prev_filtered;
// 定点化：alpha用Q15格式表示，避免浮点运算
int16_t alpha_q15 = 7864; // 0.24 * 32768
int32_t acc = (int32_t)alpha_q15 * raw + (32768 - alpha_q15) * prev;
filtered = (int16_t)(acc >> 15);3.2.2 本地推理与告警决策功能
系统需在设备端完成模型推理，输出分类标签或异常分数。推理结果需经过决策逻辑转换为告警事件。决策逻辑包括：阈值比较（分数>0.8触发）、滞回比较（避免临界抖动）、以及时间窗口确认（连续3次超限才告警）。告警事件应包含：事件ID、时间戳（32位Unix时间）、传感器读数摘要、模型置信度。事件需暂存于本地环形缓冲区（容量8-16条），等待通信模块上报。
3.2.3 通信上报与重传功能
通信模块需支持至少一种无线协议（LoRa、NB-IoT、BLE或Wi-Fi），并实现可靠传输。功能上需包含：告警事件队列管理（FIFO）、确认机制（ACK/NACK）、超时重传（最多3次）、以及批量上报（当多条告警积压时合并为一帧）。对于低功耗广域网（LPWAN），还需支持下行命令（如远程修改阈值、触发设备自检）。通信协议设计需考虑MTU限制（如LoRa单帧最大256字节），告警数据需进行二进制编码压缩。
- 支持3路模拟输入（12位ADC，采样率1kHz）和1路数字PIR输入
- 内置滑动窗口（128点）特征提取：均值、峰值、方差、过零率
- 模型推理：量化MobileNetV2（输入32x32灰度图），推理时间<80ms
- 告警事件缓存：16条，每条64字节，掉电不丢失（写入外部Flash）
- LoRa通信：SF7/125kHz，上报间隔可配置（1分钟~24小时）
- 支持远程参数配置：阈值、采样率、上报周期（下行链路）
3.3 非功能需求：实时性、功耗与可靠性的三角平衡
非功能需求定义了系统做得怎么样，是系统架构和资源分配的核心依据。在TinyML边缘告警系统中，实时性、功耗和可靠性三者相互制约，必须根据具体场景确定优先级。
3.3.1 实时性需求分析
实时性指标包括：端到端延迟（从事件发生到云端收到告警的时间）、推理延迟（传感器采样到模型输出）、通信延迟（数据发出到服务器确认）。对于入侵检测，端到端延迟需控制在2秒内；对于设备监控，可放宽至30秒。实时性预算分配建议：传感器采样+预处理占20%，模型推理占30%，通信占50%。若通信延迟过高（如LoRa的空中传播时间约100-500ms），可考虑“先本地缓存+批量上报”策略，但需在延迟和功耗间权衡。
3.3.2 功耗需求分析
功耗是电池供电设备的核心约束。需区分平均功耗（决定电池寿命）和峰值功耗（决定电源电路设计）。典型TinyML设备的功耗预算：MCU睡眠模式5μA，传感器工作模式2mA，LoRa发射模式120mA（持续0.5秒）。若设备每天触发10次告警，每次通信消耗0.06mAh，则通信功耗占比极小；但若设备持续监听（如入侵检测），传感器+MCU的待机功耗将占主导。功耗优化策略包括：事件驱动采样（无事件时进入深度睡眠）、动态电压频率调节（DVFS）、以及通信模块的占空比控制。
3.3.3 可靠性需求分析
可靠性涵盖数据可靠性（不丢包、不损坏）、系统可靠性（不死机、可自恢复）和告警准确性（低误报率、低漏报率）。在边缘设备上，需实现看门狗定时器（WDT）、Flash磨损均衡、以及通信链路的CRC校验。告警准确性需通过模型训练和阈值调优来保证，但需注意：降低误报率（提高阈值）可能导致漏报率上升，需根据场景设定可接受的误报率（如入侵检测误报率<1次/天）。
| 非功能需求 | 指标定义 | 典型目标值 | 主要影响 |
|---|---|---|---|
| 实时性 | 端到端告警延迟 | <2秒（入侵） | 通信协议、推理速度 |
| 功耗 | 平均电流（@3.3V） | <50μA（待机） | 睡眠模式、采样策略 |
| 可靠性 | 告警上报成功率 | >99%（3次重传） | 通信质量、重传机制 |
| 准确性 | 误报率/漏报率 | 误报<1次/天 | 模型质量、阈值设置 |
3.4 案例拆解：智能电表箱入侵检测系统需求分析
某电力公司需要在城市配电箱中部署边缘告警设备，用于检测非法开启、电缆盗割和内部过热。设备采用电池供电（3.6V锂电池，容量19Ah），要求工作寿命≥3年，告警延迟<5秒，误报率<0.5次/天。
场景分类与需求映射：该场景同时涉及入侵检测（非法开启）和设备监控（温度异常）。因此，系统需融合PIR传感器（检测人体接近）、门磁开关（检测箱门状态）和NTC温度传感器（检测过热）。PIR和门磁触发时，系统立即唤醒MCU执行推理；温度数据则每5分钟采样一次，进行趋势分析。
功能需求细化：
- 数据采集：PIR数字输入（GPIO中断）、门磁开关（GPIO电平）、NTC模拟输入（12位ADC，采样率10Hz，持续5秒）
- 推理任务：使用2层全连接网络（输入16维特征，隐藏层8节点，输出2类：正常/入侵），模型大小约2KB，推理时间<10ms
- 告警决策：PIR+门磁同时触发时立即告警；温度连续3次超过75℃时告警
- 通信：LoRa SX1276，SF7/125kHz，发射功率14dBm，单帧64字节
非功能需求权衡：实时性方面，PIR中断响应<50ms，推理+决策<20ms，LoRa发送+ACK确认约300ms，总延迟<1秒，满足要求。功耗方面，待机电流设计为15μA（MCU睡眠+PIR待机），事件触发时工作电流30mA（持续2秒），每天假设触发5次，则日均功耗为：15μA×86400s + 30mA×10s = 1.3mAh + 0.083mAh ≈ 1.38mAh，电池寿命约13.7年（理论值），满足3年要求。可靠性方面，LoRa通信采用CRC16校验+最多3次重传，实测上报成功率99.2%。
实施结果与复盘：部署50台设备运行6个月后，共上报告警127次，其中真实入侵事件9次，误报3次（均为PIR被蜘蛛网遮挡触发），误报率0.017次/天，远优于目标。复盘发现：温度传感器采样频率可降低至每10分钟一次以进一步省电；PIR灵敏度需增加数字滤波（连续2次触发才有效）以减少误报。
- 误区1：将所有告警场景统一处理，导致实时性要求高的场景（入侵）被低频采样拖累，而低频场景（设备监控）被高频推理浪费功耗。
- 误区2：只关注推理功耗，忽略通信功耗。实际上，LoRa发射1秒的功耗相当于MCU运行数小时，通信策略（批量上报、占空比控制）往往比模型优化更省电。
- 误区3：误报率与漏报率未做场景化权衡。在安全防护场景中，漏报的代价远高于误报，应适当降低阈值；而在设备监控场景中，误报会导致不必要的人工巡检，应提高阈值。
- 误区4：忽略“告警风暴”问题。当设备连续触发大量告警时，通信队列溢出会导致最新告警丢失，需设计优先级丢弃策略（保留高优先级事件）。
3.5 总结复盘：需求分析驱动系统设计
告警系统需求分析的核心产出物是需求规格说明书，它直接决定了后续的硬件选型、模型设计、通信协议和电源管理策略。本章强调三个关键结论：第一，告警场景分类是需求分析的起点，不同场景的实时性、功耗和可靠性指标差异巨大，必须分别定义；第二，功能需求需覆盖数据采集到通信上报的完整链路，任何环节的缺失都会导致系统不可用；第三，非功能需求是系统架构的约束条件，实时性、功耗和可靠性三者需要根据实际场景进行权衡，不存在“最优解”，只有“最适解”。在实际项目中，建议使用需求追踪矩阵，将每个功能需求与非功能需求映射到具体的硬件模块和软件任务，确保设计无遗漏。