会员专区

MCP接入振动诊断之后：预测性维护如何变成可审计的工业智能体

, , , , ,

摘要：predictive-maintenance-mcp把FFT、包络分析、轴承故障频率、异常检测、严重度和RUL封装为34个工具与3个提示模板。本文分析智能体编排、证据链、专家审核和生产落地边界。

MCP编排振动分析与设备故障诊断工作流 ## 导语

大模型进入工业运维后，最容易被误解的一件事，是把“会调用诊断工具”说成“模型学会了诊断”。LGDiMaggio/predictive-maintenance-mcp 提供了一个很好的观察样本：它不是用大模型替代 FFT、包络解调、异常检测或寿命模型，而是把这些能力封装成 Model Context Protocol（MCP）工具，让 Claude、GPT 或本地 Ollama 等模型通过自然语言组织分析流程、补齐参数、汇总证据并生成报告。

截至 2026 年 8 月 10 日，项目主分支版本为 0.12.0。README、Changelog 和测试固化的工具清单共同表明，其当前 MCP 接口面为 37 个端点，即 34 个 tools、3 个 prompts、0 个 resources。需要指出的是，pyproject.toml 的项目描述仍写着“52 endpoints”，属于元数据未同步，不能据此采用旧数字。这一细节也提醒工业用户：即使项目建立了接口漂移测试，文档和发布元数据治理仍需持续校核。

一、它真正解决的是“编排断点”，而不是诊断原理

传统振动诊断的难点并不只在算法。现场工程师往往要在采集文件、设备手册、轴承型号、转速、采样率、单位、频谱软件、阈值表和报告模板之间来回切换。predictive-maintenance-mcp 的核心价值，是用 MCP 把这些步骤暴露为可发现、可参数化调用的工具：加载信号，查询元数据，做 FFT、PSD、STFT 和包络分析，计算轴承特征频率，匹配故障峰，评估振动严重度，训练异常模型，分析趋势，估计 RUL，最后生成 HTML、PDF 或 DOCX 报告。

MCP 在这里更像“工业智能体的工具总线”。官方 MCP 文档将 tools 定义为可执行函数、prompts 定义为可复用交互模板；协议本身只负责上下文与能力交换，并不规定 LLM 如何推理，更不保证诊断正确。项目的 3 个 prompts——diagnose_bearing、diagnose_gear、quick_diagnostic_report——本质上是流程脚手架，帮助模型按决策树调用工具，而不是新增三种诊断算法。

因此，合理的定位是：MCP 负责意图理解、参数路由、流程编排、结果归并和交互解释；确定性的信号处理与诊断计算仍由服务端代码完成。 这比让 LLM 直接“看一串波形数字后下结论”可靠得多，也更容易审计、测试和替换算法模块。

二、从波形到证据：振动分析链如何闭环

项目按 ISO 13374 六块架构组织代码，覆盖采集、处理、状态检测、健康评估、预测和决策支持。一次典型链路可概括为：

  1. load_signal 读取 CSV、WAV、MAT、NPY 或 Parquet，并登记采样率、单位、时长和来源；
  2. analyze_statistics 计算 RMS、峭度、峰值因子等时域特征，先判断能量和冲击性；
  3. analyze_fft 查看稳定周期成分，识别 1×、2×转频及谐波；
  4. compute_power_spectral_density 用 Welch 方法估计功率分布，compute_spectrogram_stft 查看随时间变化的频率能量；
  5. analyze_envelope 对高频共振带带通滤波，再利用 Hilbert 包络解调，将滚动体撞击激起的高频共振还原成低频重复冲击规律；
  6. check_bearing_faults 将包络谱峰与理论故障频率及其谐波匹配；
  7. assess_severity、异常模型和综合诊断管线形成多证据判断，再生成建议与报告。

这里必须区分频谱和包络谱。普通 FFT 擅长显示转频、不平衡、对中不良、松动及明显谐波；早期轴承局部缺陷产生的是短促冲击，能量可能散布在结构共振带，直接 FFT 中未必突出。包络分析先选取承载冲击信息的高频带，再解调冲击重复频率，因此更适合寻找轴承故障节律。项目默认包络带为 500—5000 Hz，并会受 Nyquist 频率约束；但真实设备的最佳共振带取决于传感器安装、结构传递路径和转速负载，不能把默认值当作通用标准答案。

项目示例数据的轴频为 25 Hz，给出的 FTF、BSF、BPFO、BPFI 分别约为 14.84、63.91、81.13、118.88 Hz。它们分别对应保持架、滚动体自转、外圈通过和内圈通过频率。理论值由滚动体数量、滚动体直径、节圆直径、接触角和转速决定；实际谱峰会因滑移、转速波动、载荷和分辨率发生偏移，所以代码按容差匹配，并检查 2×、3×等谐波。当前实现把“基频加多个谐波”标为更强证据，但明确将 evidence_strength 定义为分级证据，而非故障概率。

振动信号经过频谱、包络、故障证据、异常检测、剩余寿命和MCP编排形成可审计诊断链
振动诊断与审计决策链：算法负责计算，智能体负责调用与解释，专家负责最终决策

三、signal_id：一个小设计，决定能否稳定编排

0.9.0 之后，项目把 signal_id 设为贯穿加载、分析、诊断、预测和报告的统一句柄。信号只加载一次，进入带容量上限的本地内存仓库，后续工具不再反复传文件名或重读大文件。默认 ID 由数据目录下的相对路径派生，减少同名文件冲突；重复加载需显式 overwrite=True。

这对工业智能体很重要。自然语言会出现“刚才那条泵端信号”“把它和基线比较”等指代，而算法接口需要稳定、唯一、可追踪的对象标识。signal_id 相当于一次诊断会话中的数据主键，可把原始文件、元数据、特征、模型版本和报告串成审计链。

但它目前主要是进程内仓库句柄，并不等于企业级资产身份。生产落地还需要把它映射到资产层级、测点、方向、传感器序列号、工况、采集时间、校准状态和数据版本；否则“同一台设备的同一测点”无法形成长期可比序列，RUL 也无从谈起。

四、异常检测、严重度与“风险”不是同一个概念

项目的异常检测链采用健康数据分段，提取时域特征，经 StandardScaler 标准化和 PCA 降维，再训练 One-Class SVM 或 Local Outlier Factor。默认分段为 0.1 秒、50% 重叠；可选故障样本只用于调参，而不是把算法变成监督分类器。预测输出会汇总异常段比例、分数分位数和最差片段，避免把超长数组全部交给 LLM。

这种方法适合回答“当前状态是否偏离已知健康分布”，却不能直接回答“是什么故障”。基线若只覆盖单一转速、负载和环境，工况切换就可能被误报为异常；健康样本被早期缺陷污染，又会造成漏报。项目附带的 20 条信号由 3 条健康基线、7 条内圈故障和 10 条外圈故障组成，训练集 14 条、测试集 6 条，采样率为 48,828 或 97,656 Hz，时长为 3 或 6 秒。它适合演示工作流和回归测试，但规模、故障覆盖和工况多样性都不足以证明跨设备泛化。

assess_severity 则把宽带振动速度 RMS 映射到严重度区域。当前代码沿用 ISO 10816-3:2009 的 A—D 边界，同时注明 ISO 20816-3:2022 已合并 A/B 区域；还会在单位未声明、功率低于适用范围或采样率不足时拒绝给出结论，而不是猜测单位。这种“结构化拒绝”值得肯定，因为 g、m/s² 与 mm/s 混淆足以让严重度判断完全失真。

然而，严重度不是风险。资产风险至少还要结合失效后果、人员与过程安全、生产损失、冗余能力、备件周期、劣化速度和证据可信度。项目综合管线以 ISO 区域、转频特征、轴承频率和异常结果累计证据点，输出 none/weak/moderate/strong；这是一套透明的启发式汇总，不是经现场标定的风险概率模型。生产系统不应把“strong evidence”自动翻译成“90% 会失效”，也不应仅凭 Zone C/D 自动下停机指令。

五、RUL 的可贵之处，是知道什么时候不该算

项目提供线性、指数和 Kalman 三种 RUL 路径。线性与指数模型把随时间采集的退化指标外推到失效阈值；Kalman 模型以“退化水平—退化速率”为状态，并给出近似区间。代码特别说明：线性/指数拟合的 fit_r_squared 只是历史数据拟合优度，不是 RUL 正确概率；Kalman 的 precision_heuristic 和 95% 区间也未经覆盖率验证，只宜作为量级参考。

更重要的是，0.9.0 已删除用单条稳态记录内部片段外推寿命的做法，并要求至少 3 个带时间戳的重复测量。单次录波内部的波动反映段间噪声或短时工况，不等于数周、数月尺度的劣化趋势。若只有单条信号，系统应调用 analyze_signal_trend 做录波内趋势筛查，而不是制造“还剩 127 小时”式伪精确结论。

即便有多次测量，RUL 仍依赖人为设定的失效阈值、特征单调性和工况可比性。对维修决策而言，更稳妥的输出应是情景区间和触发条件，例如“在当前增长率、同工况和阈值不变前提下，预计 20—35 天触线；若负载升高需重算”，并保留原始趋势、模型版本及专家批注。

六、本地数据与专家在环：隐私优势不能被绝对化

项目采用本地 MCP server：原始波形、模型和报告可留在用户机器上，分析函数在本地运行，LLM通常接收结构化结果而非整段原始波形；也可配合 Ollama 形成隔离部署。这对工业数据主权很有吸引力。

但“本地运行”不应被简化为“任何数据都不会出厂”。如果上层使用云端 LLM，工具返回的特征、诊断文字、设备名称、手册摘录或报告内容仍可能进入模型上下文。企业部署需明确字段级出域策略：原始波形禁止出域，资产名称脱敏，手册按页授权，工具结果限长，报告落本地对象存储，并对所有调用、参数、模型和人工确认留痕。

专家在环也不能只写在免责声明里。建议至少设置三道门：一是参数门，采样率、单位、转速、轴承几何、测点方向和工况不全时拒绝定性；二是证据门，单一指标仅提示复测，多源证据一致才进入维修建议；三是执行门，停机、工单、备件采购和控制系统写操作必须由授权人员确认。LLM可以解释“为什么建议复测”，但最终责任主体仍是设备可靠性工程师和现场运维组织。

七、从开源演示到生产系统：推荐的落地架构

一个可控的生产架构可分为六层：

  • 采集层：传感器、边缘采集器和状态监测系统，负责同步采样、抗混叠、校准和测点治理；
  • 数据层：时序库或对象存储，统一资产、测点、工况、时间戳和版本；
  • 算法层：将项目的 FFT、PSD、STFT、包络、特征、异常检测和 RUL 模块容器化，算法版本可追溯；
  • MCP 编排层：暴露只读分析工具与受控报告工具，限制路径、文件大小、运行时长和返回字段；
  • 智能体层：负责意图识别、手册检索、工具链选择、冲突解释和报告草拟，不直接篡改算法结果；
  • 治理与业务层：专家复核、告警分级、CMMS/EAM 工单、审计日志、回放评估和模型监控。

上线顺序应从“影子模式”开始：先让系统分析历史数据但不影响决策，再与振动专家盲评比较，统计按资产和工况分层的误报率、漏报率、故障定位准确率、提前量和复测率；之后只开放报告辅助，最后才考虑受控工单建议。README 中的 MQTT/Kafka 流式接入、车队仪表盘和 SAP/Maximo/Infor 集成仍列在路线图，不能写成现成功能。

产业上，这类项目最有价值的方向不是打造一个“万能振动大模型”，而是形成可组合的工业诊断工具协议：企业可把成熟的商业诊断算法、内部阈值、知识库和审批流程放在 MCP 后面，由不同智能体复用。其竞争力将取决于工具契约、数据治理、证据可追溯和现场验证，而不只是自然语言体验。

结论

predictive-maintenance-mcp 展示了一条务实路线：让 LLM 成为工业诊断流程的编排者与解释者，让传统信号处理、统计学习和规则引擎继续承担可验证计算。统一 signal_id、拒绝猜测单位、区分证据强度与概率、拒绝单录波 RUL、保留本地处理，都是值得借鉴的工程选择。

但它目前更适合作为开源技术样机、教学工具和企业 PoC 起点，而非已经过生产验证的预测性维护平台。项目样例来自公开轴承试验数据，20 条信号和当前测试覆盖只能证明软件流程在既定场景可运行，不能证明在不同机型、测点、工况和故障阶段下达到可接受的误诊水平。真正的产业门槛仍是长期高质量历史数据、资产语义、算法验证、责任边界和专家闭环。MCP降低了编排成本，却不会替企业完成这些艰难工作。

参考资料

  1. 项目 README：https://github.com/LGDiMaggio/predictive-maintenance-mcp
  2. 项目架构文档：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/docs/architecture.md
  3. 项目 Changelog：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/CHANGELOG.md
  4. 固化的 MCP 工具清单：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/tests/fixtures/tool_inventory.json
  5. 示例数据说明：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/data/README.md
  6. 轴承故障检测实现：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/src/diagnostics/bearing_analyzer.py
  7. 综合诊断管线：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/src/decision_support/diagnosis_pipeline.py
  8. RUL 线性/指数实现：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/src/prognostics/rul_estimator.py
  9. Kalman RUL 实现：https://github.com/LGDiMaggio/predictive-maintenance-mcp/blob/main/src/prognostics/kalman_rul.py
  10. MathWorks 滚动轴承故障数据集：https://github.com/mathworks/RollingElementBearingFaultDiagnosis-Data
  11. MCP 官方架构说明：https://modelcontextprotocol.io/docs/learn/architecture
  12. ISO 13374-1:2003 页面：https://www.iso.org/standard/21832.html
  13. ISO 20816-3:2022 页面：https://www.iso.org/standard/78311.html
  14. 项目 Zenodo DOI：https://doi.org/10.5281/zenodo.17611542
分享到