一、嵌入式异常检测概述

什么是异常检测

异常检测，说白了就是让系统自己发现「不对劲」的地方。

我习惯这么定义它：异常检测是一种通过监控系统行为，识别出与正常模式显著偏离的技术。你想想看，一个嵌入式设备正常工作时，它的CPU占用率、内存使用、传感器读数、通信频率，都有一个大致的范围。一旦某个指标跳出这个范围，我们就说——嗯，出问题了。

举个例子。我在做智能电表项目时，设备平时每5秒上报一次数据。突然有一天，它开始每0.5秒上报一次。表面上看数据还在传，但频率变了。这就是异常。异常检测要做的，就是抓住这种「不对劲」。

为什么嵌入式设备需要异常检测

这个问题，我当年刚入行时也问过自己。后来踩了几个坑，才真正明白。

第一，嵌入式设备往往无人值守。 你想想看，一个部署在野外的传感器节点，或者一个工厂流水线上的PLC，谁会24小时盯着它？没人。所以设备必须自己学会「喊救命」。

第二，嵌入式资源有限，扛不住大故障。 我见过一个案例：某智能门锁因为内存泄漏，连续运行3天后死机。用户被锁在门外，投诉电话打爆了售后。如果当时有异常检测，提前发现内存占用持续增长，就能在死机前重启或报警。

第三，安全攻击越来越针对嵌入式设备。 从Mirai僵尸网络到各种IoT漏洞，攻击者盯上的正是那些「没人管、跑得慢、好欺负」的嵌入式设备。异常检测是最后一道防线。

场景	没有异常检测	有异常检测
工业PLC	停机停产，损失数万	提前预警，安排维护
智能门锁	用户被锁，投诉退款	远程重启，避免投诉
车载ECU	行车安全风险	降级运行，保障安全

常见异常类型

嵌入式设备的异常，我一般分成三大类。每一类我都亲手处理过，印象很深。

1. 硬件故障

硬件故障是最「实在」的异常。坏了就是坏了。

• 传感器漂移：温度传感器读数慢慢偏离真实值。我在做冷链监控时遇到过，一个温度探头用了半年，读数比实际高了3度。要不是异常检测发现趋势异常，整批疫苗都得报废。
• 存储介质老化：Flash的坏块越来越多，写入速度变慢。我曾经有个项目，设备运行一年后，日志写入时间从5ms涨到了200ms。这就是典型的硬件退化。
• 电源波动：电压不稳，导致MCU频繁复位。这种异常往往伴随着「设备间歇性失联」的症状。

2. 软件错误

软件错误比硬件更隐蔽。硬件坏了你还能摸到，软件坏了你只能看日志。

• 内存泄漏：每次执行某个功能，就泄漏几十个字节。日积月累，系统崩溃。我记得有个项目，一个定时器回调函数里忘了释放malloc的内存，跑了两个月才出问题。排查起来极其痛苦。
• 死锁/活锁：多任务系统中，两个任务互相等待对方释放资源。表现就是系统「卡住」了，但CPU还在跑。
• 看门狗复位：任务超时，看门狗没来得及喂。这种异常往往意味着某个任务执行时间超出了预期。

3. 安全攻击

安全攻击是这几年越来越常见的异常类型。说实话，十年前我做嵌入式时，很少考虑安全问题。现在不一样了。

• 暴力破解：短时间内大量登录尝试。我在一个智能网关项目里见过，有人用脚本每秒尝试50次SSH登录。正常用户谁会这么干？
• 异常通信：设备突然向未知IP发送大量数据。这往往是中了木马，被当成肉鸡了。
• 固件篡改：攻击者通过漏洞刷入了恶意固件。检测方法很简单——校验固件哈希值。如果哈希对不上，说明固件被动了手脚。

你可能会问：嵌入式设备那么小，谁会来攻击？

答案是：攻击者不挑食。一个智能灯泡被控，可以成为DDoS攻击的帮凶；一个工业传感器被篡改，可以导致整个生产线误判。嵌入式设备是物联网的「末梢神经」，一旦被控，后果可能比PC被控更严重。

异常检测的挑战

说了这么多，我得泼盆冷水——嵌入式异常检测并不容易。

资源限制：MCU的算力和内存都有限。你不能在STM32上跑一个深度学习模型来做异常检测。不现实。

误报率：检测太灵敏，天天报警，运维人员会疯掉。检测太迟钝，真出事了又抓不到。这个平衡很难把握。

环境变化：设备部署在不同环境中，正常行为可能完全不同。一个在北极的传感器和一个在沙漠的传感器，温度读数能一样吗？

好了，这一章我们聊了什么是异常检测、为什么需要它、以及常见的异常类型。下一章，我会带你看看具体的检测方法——从最简单的阈值检测，到稍微复杂一点的统计方法。到时候我会拿实际代码来演示，保证你能跟着做出来。