企业官网建设流程全解析

论文题目：Edge Computing on IoT for Machine Signal Processing and Fault Diagnosis: A Review（面向机器信号处理与故障诊断的 IoT 边缘计算：综述）

期刊：IEEE Internet of Things Journal，2023

摘要：边缘计算是一种新兴计算范式，它将计算与分析任务下沉到物联网（IoT）边缘设备，以提升计算效率、减少信号传输对通信信道的占用，并降低云服务器的存储与计算负担。这些特点使其成为基于 IoT 的机器信号处理与故障诊断的重要技术。本文从基本概念、最新方法、案例研究和未来研究方向四个方面，对面向信号处理型机器故障诊断的边缘计算方法进行了综述。文章重点讨论了典型故障诊断流程中适用于边缘端的轻量化算法与专用硬件平台，包括信号采集、信号预处理、特征提取和模式识别四个环节。该综述旨在帮助理解边缘计算的框架、方法和应用，以满足 IoT 场景下机器实时信号处理、低时延故障诊断和高效预测性维护的需求。

源码/案例代码：
EnCodec：GitHub - facebookresearch/encodec: State-of-the-art deep learning based audio codec supporting both mono 24 kHz audio and stereo 48 kHz audio. · GitHub
STM32 Case Study：GitHub - Lu-JF/STM32CaseStudy: The case study of the edge computing system based on STM32 · GitHub
Raspberry Pi Case Study：GitHub - Lu-JF/RaspberryPiCaseStudy: The case study of the intenlligent edge computing system based on RaspberryPi and deep learning · GitHub

一、为什么机器故障诊断需要边缘计算

机器状态监测本质上是一个“信号 → 信息 → 决策”的过程。温度、润滑油成分等低频状态量通常以秒到小时为更新周期，而振动、声音、声发射、电压、电流和磁信号等波形数据的采样频率可以达到 kHz 甚至 MHz。随着一台设备上的传感器数量不断增加，把所有原始数据都上传到云端，会同时带来带宽占用、服务器存储与计算压力，以及不可避免的传输和处理时延。

这也是本文讨论边缘计算的出发点：不是否定云计算，而是把必须快速完成的处理前移到传感器附近。原始信号可以在边缘节点先完成清洗、滤波、压缩、特征提取甚至故障识别，只把筛选后的数据、特征和结果上传云端；云端继续负责数据挖掘、模型训练、存储与备份，再把更新后的模型或控制指令部署回边缘节点。

论文 Figure 3（PDF 第 4 页）：边缘计算框架——原始数据在分布式边缘节点就近处理，仅将筛选后的数据和特征上传云端。

这张图最值得看的不是“云”和“边”的位置，而是计算任务的重新分配。越靠近传感器，系统越强调低时延和即时响应；越靠近云端，越适合承担更大规模的存储、训练和跨节点分析。作者将边缘计算对机器诊断的优势概括为五点：降低诊断时延、减少云端资源消耗、改善数据隐私、让诊断与控制在同一处理器上闭环执行，以及通过联网节点实现灵活扩展。

因此，边缘计算真正解决的问题不是“算力够不够”，而是哪些任务必须在本地算、哪些数据值得上传、在有限功耗和存储下怎样最快得到可靠诊断结果。

二、边缘端不是“把云算法搬下来”：核心是算法—硬件协同

边缘设备通常受制于尺寸、功耗、内存和成本，服务器上可直接运行的算法并不能原样部署。论文强调，算法上边缘之前要做轻量化设计，同时根据计算负载选择合适的平台。

论文 Table II（PDF 第 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 5（PDF 第 12 页）：边缘节点上的特征提取方法汇总，以及算法与硬件平台的对应关系。

论文把边缘特征提取归纳为频谱分析、波形分析、信号滤波和统计特征四类。RMS、FFT、IIR 等低复杂度算法可以放在低成本 MCU 上直接运行；时频分析、DWT、WPT、Pearson 相关等计算负担较大的方法，则更适合 Raspberry Pi、DSP、FPGA 或 GPU。

这里的一个关键结论是：“更复杂的特征”并不自动意味着“更适合边缘诊断”。对于现场设备，硬件是否需要操作系统、待机功耗、外围电路复杂度、价格和电池寿命都必须一起考虑。边缘端更像一个受严格资源预算约束的计算系统，而不是缩小版服务器。

3.4 模式识别：从经典 ML 到轻量化 DL

论文 Table VIII + Figure 6（PDF 第 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 IX（PDF 第 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 X（PDF 第 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 XI（PDF 第 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；最后根据系统允许的响应时间决定哪些任务必须在边缘闭环、哪些任务可以留给云端。

从工程角度看，真正高质量的边缘诊断系统往往不是“精度最高”的系统，而是在足够准确的前提下，能够长期稳定地以更低功耗、更小通信量和更低时延完成现场决策的系统。这也是本文三组案例共同说明的核心：当算法设计和硬件平台真正协同起来，边缘计算才能从概念变成可部署的机器智能。