《Sensors》:A CPU–NPU Heterogeneous Edge Fault Diagnosis Framework for Industrial Sensor Data
编辑推荐:
基于工业传感器的故障诊断通常需要在边缘设备上进行连续数据采集、本地数据处理和及时的模型推理。尽管基于深度学习的诊断方法已取得良好性能,但许多现有方法依赖于云中心的处理流水线,这引入了通信开销和潜在的数据隐私问题。本文提出了一种面向工业传感器数据的CPU–NPU
基于工业传感器的故障诊断通常需要在边缘设备上进行连续数据采集、本地数据处理和及时的模型推理。尽管基于深度学习的诊断方法已取得良好性能,但许多现有方法依赖于云中心的处理流水线,这引入了通信开销和潜在的数据隐私问题。本文提出了一种面向工业传感器数据的CPU–NPU异构边缘故障诊断框架。该框架运行于RK3588本地边缘设备上,包含基于SQLite和环形缓冲区(RingBuffer)的数据管理、滑动窗口生成、微批次(micro-batch)构建以及模型推理。中央处理器(CPU)负责数据访问与缓冲、预处理和微批次准备,而神经网络处理器(NPU)使用RKNN运行时环境执行故障诊断模型。通过在本地进行推理,该框架减少了原始传感器数据的持续传输,并支持在资源受限的边缘设备上进行实时故障诊断。实验结果表明,在模型转换后,基于开放神经网络交换格式(ONNX)的CPU推理与基于RKNN的NPU推理之间具有高度一致性。此外,研究人员系统评估了不同数据输入路径和微批次配置的影响。研究人员还从延迟、吞吐量和能效方面,对服务器级CPU/GPU执行与嵌入式NPU部署进行了跨平台比较。结果表明,基于环形缓冲区的流式输入显著降低了数据访问开销,而NPU加速的效果取决于模型结构和微批次大小。跨平台结果进一步展示了RK3588平台的能效优势,使其更适用于资源受限边缘场景的实际部署。这些发现为在异构边缘设备上部署故障诊断模型提供了实用见解。
**论文解读:面向工业传感器数据的CPU–NPU异构边缘故障诊断框架**
**研究背景与现存问题**
工业设备通常通过高频传感器数据进行状态监测,及时故障诊断对设备安全和维护至关重要。然而,工业设备在运行中可能出现磨损和性能退化,导致故障和安全事故。传统依赖专家经验的方法难以应对复杂工况和实时监测需求。工业设备运行复杂,数据主要为高采样频率、大体积的时序传感器数据,给智能故障诊断带来挑战。轴承作为关键部件,其状态直接影响系统可靠性。近年来,基于深度学习的方法(如卷积神经网络(CNN)、循环神经网络(RNN)和Transformer)在轴承故障诊断中取得了良好性能,但这些模型通常部署在云端,存在通信延迟、数据隐私风险和带宽限制等问题。边缘计算的发展使得将计算资源部署到靠近设备端成为可能,但边缘设备资源受限,部署大型模型困难。现代边缘设备集成了神经网络处理器(NPU),为深度学习推理提供专用硬件加速,但如何设计数据访问、预处理、批处理与硬件加速推理的协同流程仍存在问题。为此,研究人员开展此项研究,旨在设计一种CPU–NPU异构边缘故障诊断框架,实现资源受限条件下的本地推理,并将论文发表在《Sensors》上。
**研究内容与结论**
研究人员开发了一种CPU–NPU异构边缘故障诊断框架,框架运行于RK3588边缘设备上。CPU负责传感器数据访问、缓冲、滑动窗口生成和微批次构建,NPU通过RKNN运行时执行转换后的故障诊断模型。研究人员在CWRU和MFPT两个公开轴承故障数据集上,部署了CNN、RNN和时域卷积网络(TCN)三种模型,从模型转换一致性、数据访问开销、批次推理可扩展性和端到端流水线性能四个方面进行了评估。实验结果表明,转换后的RKNN模型与基于ONNX的CPU推理相比,保持了可接受的诊断性能和较高的预测一致性;基于环形缓冲区(RingBuffer)的流式输入相比SQLite分段查询显著降低了数据访问开销;NPU加速对RNN和TCN模型在较大微批次下效果更明显;跨平台对比显示,RK3588平台在能效上具有优势,更适合资源受限的边缘场景。
**主要关键技术方法**
该研究采用以下关键技术方法:(1)CPU–NPU异构计算架构,CPU负责数据管理与预处理,NPU执行模型推理;(2)两种数据输入路径:基于SQLite的历史数据路径(支持逐窗口查询和分段查询)和基于环形缓冲区的流式输入路径,用于在线推理;(3)滑动窗口生成与微批次构建,通过算法控制窗口提取和批次累积;(4)模型转换流程:将PyTorch训练的模型导出为ONNX格式,再转换为RKNN格式,通过RKNN运行时在NPU上执行;(5)性能评估方法:包括模型转换一致性(准确率、宏F1分数、类别一致性)、数据访问开销、推理延迟、吞吐量、能效等指标。样本队列来源为CWRU轴承故障数据集(10类分类,7920训练样本,1980测试样本)和MFPT轴承故障数据集(3类分类,8400训练样本,2100测试样本)。
**研究结果**
**5.1 模型转换一致性**:通过对比ONNX-CPU和RKNN-NPU推理,CNN和TCN模型在CWRU和MFPT数据集上均保持高一致性,准确率和宏F1分数几乎无变化;RNN模型出现少量不一致预测,但经配对McNemar检验无显著差异。结果表明转换流程能够保持可接受的诊断性能。
**5.2 数据访问与窗口生成开销**:比较三种输入路径(SQLite逐窗口查询、SQLite分段查询、RingBuffer流式输入),RingBuffer流式输入在两种数据集上均实现最低总开销,避免了重复数据库查询,适合在线推理场景。SQLite分段查询比逐窗口查询开销更低。
**5.3 批次推理可扩展性**:在不同微批次大小(128-2048)下,CNN模型在CPU和NPU上延迟相近,NPU加速效果有限;RNN和TCN模型在较大批次下NPU延迟明显降低,吞吐量提升,表明NPU加速效果依赖于模型结构和批次大小;硬件利用率数据显示NPU推理时CPU利用率显著降低(小于10%),NPU利用率在15-30%之间。
**5.4 端到端流水线性能**:三种配置(CPU+SQLite、NPU+SQLite、NPU+RingBuffer)中,NPU+RingBuffer在三种模型上均实现最低端到端延迟,RingBuffer减少了CPU侧数据准备开销;峰值内存消耗因模型而异,NPU部署引入运行时内存开销但部分配置下内存更稳定。
**5.5 跨平台推理性能与能效**:与Intel Xeon CPU和NVIDIA A100 GPU相比,RK3588 NPU延迟和吞吐量较低,但功耗极低(估计8W),因此能效(每瓦吞吐量)具有竞争力,更适合资源受限边缘场景。
**总结与讨论**
讨论部分指出,模型转换一致性结果证明CNN、RNN、TCN在RK3588 NPU上可保持可接受的诊断性能;批次可扩展性显示NPU加速效果因模型而异,需考虑模型结构和微批次配置;在线部署时大微批次可能引入额外等待时间,需根据采样率和响应时间要求选择批次大小;CPU侧数据准备影响端到端延迟,输入侧缓冲和内存窗口生成可降低开销。研究存在局限:仅基于一个RK3588平台和两个数据集,环形缓冲区为简单实现,未来需在更多工业数据集、不同边缘平台和更复杂模型上验证。
**结论**:本文开发了一种面向工业传感器数据的CPU–NPU异构边缘故障诊断框架。在该框架中,CPU执行本地数据访问、缓冲、滑动窗口生成和微批次准备,NPU通过RKNN运行时执行转换后的RKNN故障诊断模型。在基于RK3588的边缘设备上部署了CNN、RNN和TCN模型,并在CWRU和MFPT数据集上从模型转换一致性、数据访问开销、微批次推理可扩展性和端到端流水线性能方面进行了评估。实验结果表明,转换后的RKNN模型相比基于ONNX的CPU推理可保持可接受的诊断性能。基于环形缓冲区的流式输入表明,输入侧缓冲和内存窗口生成可降低CPU侧数据准备开销,而NPU加速在较大微批次下对RNN和TCN模型更有效。在CWRU和MFPT数据集上观察到相似的总体延迟趋势,表明该框架的优势不限于单一数据集或模型架构。这些结果表明,输入路径和微批次配置均影响边缘部署中的延迟、吞吐量和CPU侧工作负载。总体而言,所提出的框架为在资源受限的CPU–NPU边缘设备上进行本地故障诊断提供了有用参考。