论文题目Edge Computing on IoT for Machine Signal Processing and Fault Diagnosis: A Review面向机器信号处理与故障诊断的 IoT 边缘计算综述期刊IEEE Internet of Things Journal2023摘要边缘计算是一种新兴计算范式它将计算与分析任务下沉到物联网IoT边缘设备以提升计算效率、减少信号传输对通信信道的占用并降低云服务器的存储与计算负担。这些特点使其成为基于 IoT 的机器信号处理与故障诊断的重要技术。本文从基本概念、最新方法、案例研究和未来研究方向四个方面对面向信号处理型机器故障诊断的边缘计算方法进行了综述。文章重点讨论了典型故障诊断流程中适用于边缘端的轻量化算法与专用硬件平台包括信号采集、信号预处理、特征提取和模式识别四个环节。该综述旨在帮助理解边缘计算的框架、方法和应用以满足 IoT 场景下机器实时信号处理、低时延故障诊断和高效预测性维护的需求。源码/案例代码EnCodecGitHub - facebookresearch/encodec: State-of-the-art deep learning based audio codec supporting both mono 24 kHz audio and stereo 48 kHz audio. · GitHubSTM32 Case StudyGitHub - Lu-JF/STM32CaseStudy: The case study of the edge computing system based on STM32 · GitHubRaspberry Pi Case StudyGitHub - Lu-JF/RaspberryPiCaseStudy: The case study of the intenlligent edge computing system based on RaspberryPi and deep learning · GitHub一、为什么机器故障诊断需要边缘计算机器状态监测本质上是一个“信号 → 信息 → 决策”的过程。温度、润滑油成分等低频状态量通常以秒到小时为更新周期而振动、声音、声发射、电压、电流和磁信号等波形数据的采样频率可以达到 kHz 甚至 MHz。随着一台设备上的传感器数量不断增加把所有原始数据都上传到云端会同时带来带宽占用、服务器存储与计算压力以及不可避免的传输和处理时延。这也是本文讨论边缘计算的出发点不是否定云计算而是把必须快速完成的处理前移到传感器附近。原始信号可以在边缘节点先完成清洗、滤波、压缩、特征提取甚至故障识别只把筛选后的数据、特征和结果上传云端云端继续负责数据挖掘、模型训练、存储与备份再把更新后的模型或控制指令部署回边缘节点。论文 Figure 3PDF 第 4 页边缘计算框架——原始数据在分布式边缘节点就近处理仅将筛选后的数据和特征上传云端。这张图最值得看的不是“云”和“边”的位置而是计算任务的重新分配。越靠近传感器系统越强调低时延和即时响应越靠近云端越适合承担更大规模的存储、训练和跨节点分析。作者将边缘计算对机器诊断的优势概括为五点降低诊断时延、减少云端资源消耗、改善数据隐私、让诊断与控制在同一处理器上闭环执行以及通过联网节点实现灵活扩展。因此边缘计算真正解决的问题不是“算力够不够”而是哪些任务必须在本地算、哪些数据值得上传、在有限功耗和存储下怎样最快得到可靠诊断结果。二、边缘端不是“把云算法搬下来”核心是算法—硬件协同边缘设备通常受制于尺寸、功耗、内存和成本服务器上可直接运行的算法并不能原样部署。论文强调算法上边缘之前要做轻量化设计同时根据计算负载选择合适的平台。论文 Table IIPDF 第 5 页典型边缘计算硬件平台及其适用计算任务。作者给出的硬件选择逻辑非常清楚低成本、低功耗的 STM32 MCU 自带 DSP 指令能够执行卷积、FFT 等经典信号处理适合传统振动分析和实时控制Jetson 一类 GPU 具备更强的并行计算与深度学习加速能力更适合对时延敏感的 DNN 推理Raspberry Pi 则处在两者之间具备完整操作系统和较好的性价比适合把在 PC 上开发好的算法快速迁移到边缘端。这里存在一个贯穿全文的权衡关系算法复杂度 ↑ → 诊断表达能力可能 ↑但计算时间、内存、功耗和成本也会 ↑。因此边缘诊断的设计不能只看准确率。一个模型即使在服务器上表现很好如果边缘节点无法在规定时间内执行或者需要过高功耗那么它仍然不适合现场系统。论文后续几乎所有方法与案例都围绕“算法复杂度—硬件资源—实时性”这条主线展开。三、从采集到识别边缘故障诊断的四级流水线典型的机器信号诊断流程可以拆成四步信号采集与传输 → 信号预处理 → 特征提取 → 模式识别。边缘计算的价值不是只加速最后一个 AI 模型而是可以贯穿整条流水线。3.1 信号采集与无线传输先控制数据从哪里来、来多少对于电池供电的 IoT 节点传感器类型、采样频率和信号长度直接决定续航与数据规模。低功耗 MEMS 传感器已经可以在很小体积下集成模拟调理、ADC 和数字接口并通过 USART、IIC、SPI 等接口与 MCU 通信。论文特别强调采样策略。传统做法按照奈奎斯特准则覆盖整个频带但某些故障只关心特定共振频带这时可以结合带通滤波和欠采样减少数据量。文中引用的一个轴承监测方案将采样频率和信号长度降低到传统方法的大约1/8。无线通信同样需要在数据率、距离、功耗与价格之间折中BLE、Wi-Fi、ZigBee、LTE 等并不存在统一最优解。3.2 信号预处理不是“把波形变漂亮”而是提升可诊断性原始机器信号往往被机械噪声和电气干扰污染。IIR 滤波、包络分析、随机共振等低计算量方法比较适合 MCU而小波、经验模态分解、变分模态分解等方法计算量更高需要进一步轻量化或换用更强的平台。另一条重要路线是压缩。Speex、Opus 等音频编码器已经被迁移到振动信号其中一些工作实现了约16×的压缩也有边缘状态监测方法在不牺牲决策特异性或敏感性的前提下将传输数据量降低约1000 倍。论文还讨论了 SoundStream、EnCodec 这类神经网络编解码器以及压缩感知但也提醒机器信号通常噪声重、随机性强压缩不能只追求压缩比还要保证故障特征没有被一起“压掉”。3.3 特征提取低算力 MCU 与高算力平台各有边界论文 Table VII Figure 5PDF 第 12 页边缘节点上的特征提取方法汇总以及算法与硬件平台的对应关系。论文把边缘特征提取归纳为频谱分析、波形分析、信号滤波和统计特征四类。RMS、FFT、IIR 等低复杂度算法可以放在低成本 MCU 上直接运行时频分析、DWT、WPT、Pearson 相关等计算负担较大的方法则更适合 Raspberry Pi、DSP、FPGA 或 GPU。这里的一个关键结论是“更复杂的特征”并不自动意味着“更适合边缘诊断”。对于现场设备硬件是否需要操作系统、待机功耗、外围电路复杂度、价格和电池寿命都必须一起考虑。边缘端更像一个受严格资源预算约束的计算系统而不是缩小版服务器。3.4 模式识别从经典 ML 到轻量化 DL论文 Table VIII Figure 6PDF 第 15–16 页机器故障模式识别模型在 MCU、SBC、GPU、FPGA、VLSI 等平台上的部署情况。经典机器学习模型参数少、计算量低因此 BPNN、随机森林、SVM、逻辑回归等都能在 MCU、PLC 或单板机上运行。深度学习则需要更明显的压缩与优化。论文总结了三类常见做法减少网络层数与参数量、把浮点参数转换为整数或二值/逻辑表示以及在运行时动态优化变量以降低内存占用。综述中的案例能看出这种取舍ADEPOS 在特定轴承预测性维护任务上实现了8.8× 更少的神经元和平均 6.65× 的能耗节省一个 FPGA 上的卷积自编码器被压缩到不足 1 万参数固定点计算下准确率仍高于 85%另一个部署在 Raspberry Pi 上的残差多尺度 CNN 模型文件约 11 MB准确率达到 99.46%单次推理约 178.52 ms。作者的结论不是“越深越好”而是模型需要在 FLOPs、延迟、功耗与精度之间重新优化。四、三组案例论文真正有价值的工程证据相比单纯罗列文献这篇综述最有用的部分是三个带代码的案例它们分别对应预处理、特征提取和模式识别并把“算法能不能落到边缘硬件”直接量化出来。4.1 EnCodec高压缩比是否会毁掉故障特征论文 Figure 7 Table IXPDF 第 16 页EnCodec 对轴承故障振动信号的压缩结果以及 Raspberry Pi 上不同信号长度的压缩/解压时间。作者在 Raspberry Pi 上处理采样频率 24 kHz、时长 1 s 的轴承振动信号外圈故障特征频率 () 为 75 Hz。原始信号 SNR 为−1.38 dB约 16× 压缩后下降到−13.93 dB约 32× 压缩后进一步降到−17.74 dB。也就是说EnCodec 明显是有损压缩而且压缩比越大背景噪声越重。但关键现象是即使故障特征被噪声显著淹没() 仍能用于识别故障类型。这说明边缘压缩不一定要求“完美恢复原始波形”更实际的目标是保留足够的诊断信息。Table IX 进一步显示4800 点信号在 Raspberry Pi 上压缩约0.332 s、解压约0.333 s具备实际应用潜力。4.2 STM32H743经典信号处理能否在 MCU 上闭环实时执行论文 Figure 8–9 Table XPDF 第 17 页多传感器变速电机故障诊断流程、LCD 实时结果与各算法执行时间。这一案例同步采集漏磁与振动信号通过漏磁信号估计转角再对振动信号进行等角度重采样最后使用随机共振增强并计算包络阶次谱。所有算法运行在400 MHz 的 STM32H743上帧长为 4096 点。Table X 给出的时间非常有参考价值漏磁滤波 7.0 ms、转角计算 39.2 ms、振动重采样 5.3 ms、随机共振增强 10.0 ms、包络谱计算 41.7 ms、LCD 结果传输 1.9 ms总时间约105 ms。其中两个最耗时步骤都涉及 FFT。这个案例证明在合理选择算法后低成本 MCU 并不只是“采数据”它完全可以承担变速条件下的在线特征提取与现场故障诊断。4.3 Raspberry Pi 改进 CNN深度学习边缘推理能做到什么程度论文 Figure 10–11 Table XIPDF 第 18 页转子质量检测硬件流程、LCD 推理结果以及不同 DL 模型在边缘节点上的比较。第三个案例把离线训练好的 CNN 部署到 Raspberry Pi对 9 类转子缺陷进行实时识别。前端由 STM32H743 提取电压信号的峭度时间序列再传给 Raspberry Pi 执行 CNN 推理。Table XI 中改进 CNN 的训练/验证/测试准确率分别为100% / 97% / 94%模型大小只有7 MB单帧推理约170 ms。作为对照GoogLeNet 的模型大小为 68 MB推理时间达到 876 ms测试准确率为 72%。这组结果说明边缘 AI 的关键不是把一个“大模型”直接移植过去而是针对现场任务重新设计结构让模型规模、推理时间和诊断效果同时进入可接受区间。五、下一步往哪里走边缘计算还缺什么论文最后给出五个值得继续推进的方向。首先是RUL剩余寿命预测。现有预测往往以分钟到小时为数据更新周期但某些裂纹或故障可能快速恶化。边缘计算可以提高更新频率不过它仍受两个问题限制完整寿命周期数据难获得以及大模型需要在短周期内持续更新对 24 h 稳定运行的硬件提出更高要求。第二是联邦学习与分布式训练。不同工厂或设备的数据往往不能直接共享而边缘节点可以在本地完成部分模型训练再聚合参数从而兼顾知识共享、训练效率和隐私。第三是异常检测与动态控制。论文举例一个 3000 rpm 的电机在边缘端部署神经网络故障检测后可以在约250 ms内停机。对于真正涉及安全的工业系统“识别故障”最终必须进一步连接到“立即控制”。第四是异构计算与神经形态/存内计算。未来边缘芯片会越来越强调高性能核、低功耗核、GPU/NPU 等不同计算单元的动态调度存内计算和神经形态硬件则试图减少数据在存储与处理单元之间反复搬运带来的能耗。第五是AI 与下一代计算架构融合。论文讨论了云—雾—边协同、量子计算、Serverless 以及区块链。它们的共同目标并不是堆更多概念而是继续改善计算效率、数据安全、隐私和跨节点协作能力。六、总结与思考如果把这篇综述压缩成一句话边缘故障诊断不是“在树莓派上跑一个模型”而是把采集、预处理、特征提取、模式识别、通信与控制作为一个整体在资源受限的硬件上重新分配计算。这篇文章最值得记住的不是某一种 MCU、某一个 CNN甚至也不是某个具体压缩比而是它提供了一套工程化思路先判断原始信号的数据率和噪声水平再决定哪些预处理必须前移再根据算法复杂度选择 MCU、SBC、FPGA 或 GPU最后根据系统允许的响应时间决定哪些任务必须在边缘闭环、哪些任务可以留给云端。从工程角度看真正高质量的边缘诊断系统往往不是“精度最高”的系统而是在足够准确的前提下能够长期稳定地以更低功耗、更小通信量和更低时延完成现场决策的系统。这也是本文三组案例共同说明的核心当算法设计和硬件平台真正协同起来边缘计算才能从概念变成可部署的机器智能。