摘要：针对离散制造业产线计划外停机根因排查效率低、依赖人工经验的痛点，本文结合实际工程落地经验，拆解系统从设计到落地的核心要点，分享实际项目中的踩坑经验和选型权衡。
上周跟以前的老同事吃饭，他还在吐槽去年厂里上新的那套故障诊断系统，花了两百万，现在天天误报，运维没人会调，基本当成摆设扔那了。
产线停摆，最怕的就是找不到哪坏了。你懂那种感觉吗？整条线趴窝，流水线停一分钟，订单赶不出来，就是几千块的损失。找半天找不到根因，所有人围着生产线干着急。
传统根因排查为啥越急越错
我十年前刚进工厂的时候，跟着老师傅学排障。焊装线停了，老师傅绕线走三圈，伸手摸一摸主电机的外壳，再去PLC柜晃两下网线，大概率能蒙对，但也经常错。
有次冬天赶订单，整条线停了快一个半小时，换了三波人查，一会说通讯故障，一会说传感器误触，最后发现是张紧轮的轴承磨坏了，跳了过载保护，藏在传送带架子底下，没人想到去看。
急得满头汗。停一小时，亏十几万。
传统排查的问题太明显了：完全依赖个人经验，年轻工程师接不住，复杂产线上百个节点，挨个试错的时间成本根本扛不住。
产线停机故障根因分析诊断系统落地的核心取舍
说实话，现在很多方案商上来就推全数据采集+大模型推理，张口就要几百万预算，真的没必要。甲方工厂的预算永远卡得死，一条百十米的组装线，能出一百万做改造就不错了，搞那么复杂干嘛？
我做过三个不同行业的落地项目，最深的体会就是：根因分析不需要全量数据，只要抓对核心节点的特征参数就够。按照ISO 14161:2019《机械设备故障诊断》的规范要求，我们只需要针对三类核心单元采集数据：动力单元、传动单元、控制单元，每个单元只采三个参数：振动（采样频率1k~10kHz）、温度（精度±0.5℃）、电流有效值，就覆盖了90%以上的常见故障。
我第一次做项目的时候踩过大坑，当时为了“全面”，把所有工位的到位开关、安全门信号都采进去了，结果数据里90%都是无效噪声，模型训练出来误报率超过32%，天天喊狼来了，工人根本不信。后来狠狠心删掉了所有无关采集点，误报率直接降到7%以下，一下子就好用了。
真正能用的系统，必须绕开这三个坑
第一个坑，故障数据太少。很多严重故障一年才出个两三次，根本拿不到足够的标注数据，模型训不出来。我们现在的做法是，找同型号同工艺的产线要历史故障数据做迁移学习，再用半监督训练，只需要标注不到20%的故障样本，就能达到可用的精度，省了至少大半年的数据标注时间。
第二个坑，推理延迟太高。产线PLC的扫描周期才10ms，故障触发了，你的系统半分钟才出结果，等结果出来，生产线都停凉了。我的硬性要求是，所有推理必须放在边缘端完成，云端只做模型更新和数据存储，单故障点推理延迟不能超过100ms。达不到这个指标，再好的准确率都是虚的。
第三个坑，运维门槛太高。很多高大上的系统，要调参数得会写python，得懂机器学习，甲方的运维工程师只会拧螺丝看PLC，出点问题就得找厂家远程，拖个三五天，人家干脆不用了。我们现在做的系统，把阈值调整、模型更新都做成了可视化拖拽，运维工程师只要把误报的案例拖到对应分类里，系统自动更新参数，十分钟就能上手，根本不需要懂算法。
去年在珠三角某电子组装厂做的项目，改造之前平均每次计划外停机的排查时间是42分钟，改造之后降到平均7分钟。有一次提前三天检测出贴片机主轴轴承的早期磨损，直接在周末换班的时候换了，连计划外停机都没发生，甲方生产主管当时拉着我们去吃烧烤，连敬三杯，那感觉真的爽。
最后说点实在的
很多人做这个系统，追求的是100%准确率，追求什么“预测性维护全覆盖”，其实完全没必要。工厂要的不是完美的系统，是能解决问题的系统。少搞点花里胡哨的概念，多想想现场的实际痛点，把成本降下来，把易用性提上去，才是真的能落地的产线解决方案。
