博客

汽车零部件工厂预测性维护项目复盘：从数据采集到规模化上线

某企业机器学习实施案例项目背景

企业基本情况

项目客户是一家汽车零部件制造企业，拥有3个生产基地、26条加工产线。

工厂主要生产转向系统零件，核心设备包括数控机床、磨床、空压机和清洗设备。

设备总量超过420台，其中关键设备138台，平均运行年限为6.5年。

工厂采用三班制生产，设备每天运行约20小时。任何非计划停机都可能影响交付。

项目启动前，企业已经部署MES和设备联网系统，但数据主要用于状态展示。

企业面临的业务挑战

设备维修以固定周期保养和故障后抢修为主，维护计划与真实状态脱节。

部分主轴轴承按季度更换，但拆检后发现，约35%的轴承仍可继续使用。

另一些设备没有达到保养周期，却突然出现振动异常、温升或刀具崩裂。

2022年，该企业关键设备发生非计划停机93次，累计停机超过760小时。

按照产能损失、加班和紧急维修计算，直接损失约480万元。

维修人员每天需要查看多套系统，再用Excel登记点检结果。

异常判断依赖老师傅经验。同一组数据，不同人员可能得出不同结论。

企业管理层提出三个问题：哪些设备可能出故障、什么时候处理、投入多少钱。

项目立项原因

企业没有直接追求全自动决策，而是选择轴承和主轴作为首批预测对象。

这两类部件故障记录较完整，停机损失也容易核算，适合验证投资回报。

项目目标被明确为：提前24至72小时识别异常，降低非计划停机时间。

另一个目标是减少无效保养，让备件采购从经验备货转向按风险备货。

该机器学习实施案例最终采用“小范围验证、达标后复制”的建设方式。

首期覆盖32台数控设备，计划周期为6个月，预算控制在120万元以内。

机器学习实施案例需求分析与方案设计

核心需求梳理

项目组没有把“建设智能平台”当作需求，而是逐项拆解生产问题。

业务部门最关心误报率。报警过多，维修人员很快就会忽略系统提示。

设备部门要求报警必须说明原因，不能只显示一个难以解释的风险分数。

生产部门要求系统不能影响设备控制，采集故障也不能导致机床停机。

IT部门则关注数据怎么传、存多久、是否需要连接外网，以及权限怎么分。

经过现场访谈，项目形成了12项核心需求和28项验收指标。

其中，故障召回率要求不低于85%，日均误报不得超过设备总数的3%。

系统响应时间控制在10秒内，关键数据本地保存不少于24个月。

报警信息必须包含设备编号、异常参数、变化趋势和建议检查项目。

模型输出不直接控制设备，只通过工单系统通知班组长和维修工程师。

方案设计思路

整体架构采用边缘采集、工厂侧计算、中心平台管理的三层模式。

设备侧通过OPC UA、Modbus TCP和数控系统接口获取运行数据。

对无法直接读取信号的老设备，加装振动、温度和电流传感器。

边缘网关负责时间对齐、异常值过滤、断点续传和数据压缩。

工厂服务器承担特征计算和模型推理，避免生产数据频繁传到公网。

中心平台用于模型版本管理、报警管理、看板展示和效果评估。

算法没有只选一种模型，而是采用规则、异常检测和分类模型组合。

规则引擎识别温度越限、振动突升等明确问题，便于快速上线。

孤立森林和自编码器用于发现未知异常，不依赖大量故障标签。

梯度提升树负责判断已知故障类型，并输出主要影响特征。

系统将报警结果推送到企业微信，同时自动创建维修工单。

维修人员处理后填写故障原因、更换部件和实际停机时间。

这些结果会重新进入训练数据，形成报警、处理、反馈、再训练闭环。

技术选型考量

技术选型重点不是模型多复杂，而是现场能否长期维护。

采集层选择支持多协议和断网缓存的工业网关，单台可接入20至40台设备。

数据存储使用时序数据库保存高频信号，关系数据库保存设备和工单信息。

模型开发采用Python生态，服务通过容器部署，方便版本回滚和节点迁移。

硬件投入约42万元，软件与实施费用约68万元，培训费用约8万元。

企业保留模型和数据所有权，供应商负责首年运维及季度模型优化。

机器学习实施案例实施过程与关键节点

第一阶段：环境准备与部署

项目第一个月完成设备普查，确认哪些数据能读、频率多高、质量怎么样。

现场发现，32台设备中有11台无法提供稳定的主轴振动数据。

项目组为这11台设备安装三轴振动传感器，采样频率设为12.8kHz。

温度和电流数据按1秒采集，设备状态及加工程序按5秒采集。

为了避免不同系统时间不一致，网关、服务器和MES统一进行时钟同步。

项目还建立了设备编码表，将机床编号、资产编号和MES编号统一映射。

这一工作看起来简单，却直接决定后续数据能否关联。

部署过程采用旁路方式，采集系统只读数据，不向PLC写入指令。

每台设备安排2小时验证窗口，检查网络负载和控制系统响应。

环境验收时，数据完整率达到98.7%，断网恢复后的补传成功率为99.5%。

项目没有急着训练模型，而是连续采集4周数据，建立正常运行基线。

先把数据采准，再讨论算法，成为这一阶段最重要的原则。

第二阶段：数据迁移与联调

企业过去三年的维修记录分散在MES、纸质工单和多个Excel文件中。

项目组整理了1.8万条记录，但只有约6400条能够对应到具体设备。

部分记录只写“主轴异常”，没有故障部位、发生时间和处理结果。

数据团队与维修人员共同制定标签规则，将故障划分为8个主要类别。

无法确认原因的记录不强行标注，而是放入待审核数据集。

在数据清洗后，约3900条记录可用于监督模型训练和离线验证。

模型训练采用时间切分，前两年数据训练，最近一年数据验证。

这样能避免随机切分造成信息泄漏，也更接近真实上线场景。

联调期间，系统曾把设备换刀造成的瞬时振动识别为轴承异常。

团队增加加工程序、主轴转速和换刀状态特征，误报率下降了41%。

另一类误报来自新刀具磨合。项目组按产品和刀具批次建立不同基线。

模型上线前进行了两周“只观察、不报警”运行，逐条核对高风险事件。

通过阈值调整，故障召回率从82%提升到88%，日均误报降至0.7次。

第三阶段：上线与运维

正式上线没有一次覆盖全部32台设备，而是先选择8台进行灰度运行。

灰度期内，报警先发送给项目组，再由项目组与维修主管联合判断。

确认流程稳定后，系统才将报警直接推送给各产线设备负责人。

每条报警分为提示、关注和紧急三级，对应不同的处理时限。

提示级进入次日点检，关注级要求4小时内检查，紧急级要求30分钟响应。

上线第三周，系统识别到一台磨床主轴振动包络值持续上升。

维修人员检查后发现轴承保持架磨损，并在周末计划停机时完成更换。

如果按原维修方式，该问题很可能在工作日演变为突发停机。

运维机制按日、周、月三个周期执行。每天检查数据中断和异常报警。

每周由设备工程师复核模型判断，每月分析漏报、误报和节省金额。

当设备大修、工艺变更或传感器更换时，系统会触发模型重新评估。

模型版本、训练数据、参数和上线时间均保留记录，支持一键回滚。

上线三个月后，32台设备稳定运行，数据可用率保持在99.2%以上。

机器学习实施案例实施效果与数据

效率提升数据

项目效果采用上线前后各6个月的数据对比，并排除法定长假影响。

试点设备非计划停机次数从31次降到17次，降幅为45.2%。

累计非计划停机时间从226小时降至121小时，减少105小时。

轴承和主轴类问题的平均预警时间为38小时，最长达到86小时。

维修人员日常数据检查时间从每人每天65分钟降至18分钟。

报警与工单自动关联后，维修记录完整率从61%提高到94%。

平均故障定位时间从72分钟缩短至29分钟，效率提升59.7%。

计划维修占全部维修任务的比例由54%提高到76%。

生产部门可以提前调整排产，不再等设备停机后临时协调订单。

成本节约数据

项目运行6个月后，减少的产能损失折算为约136万元。

紧急外购备件和加急运输费用减少22万元，维修加班费用减少11万元。

基于真实健康状态延长更换周期后，轴承消耗量同比下降18%。

试点设备备件库存金额从168万元降至139万元，释放资金29万元。

扣除服务器、传感器、软件和实施投入，首年预计净收益约146万元。

按照当前覆盖范围测算，项目投资回收期约为9.7个月。

如果复制到三个工厂，需增加网关、传感器和实施服务约210万元。

企业预计规模化后每年可减少停机及维护成本520万至680万元。

这些收益均通过工单、停机记录和采购单核算，没有使用主观评分。

用户反馈

维修人员最认可的是报警附带原因，不需要自己翻查多套历史曲线。

班组长认为三级报警机制可执行，不会因为普通波动频繁打断生产。

采购经理可以查看未来30天的部件风险清单，用于安排备件采购。

管理层则更关注每条产线节省多少钱，以及模型有没有持续产生收益。

试点调查覆盖46名用户，39人认为系统减少了重复检查工作。

仍有5名员工认为部分报警解释不够直观，项目组随后增加趋势对比图。

用户满意度由试运行阶段的78分提高到正式上线后的89分。

机器学习实施案例实施经验总结

做对了什么

项目做对的第一件事，是把目标定为减少停机，而不是追求算法准确率。

所有指标都能对应业务结果，包括停机小时、维修时间和备件金额。

第二个有效做法，是让维修人员参与标签制定和报警规则设计。

他们知道哪些波动属于正常加工，哪些变化可能代表部件损伤。

项目还保留了人工确认环节，没有让模型直接操作生产设备。

这种设计降低了安全风险，也让一线人员有时间建立信任。

采用小范围试点同样有效。32台设备的数据问题更容易被逐台解决。

踩了什么坑

最大的坑是历史数据质量。企业有大量记录，却缺少统一设备编码。

数据团队花了近5周整理旧工单，比原计划多投入约180人时。

项目初期还过度依赖高频振动数据，导致存储量快速增加。

调整采样策略后，只保留关键片段和统计特征，存储成本下降约63%。

另一个问题是忽略工艺变化。更换产品型号后，模型曾连续产生误报。

后续将产品、转速、刀具和加工程序纳入模型，才解决基线漂移问题。

这些问题说明，算法能不能用，往往取决于数据管理和现场流程。

给其他企业的建议

准备建设类似项目时，可以先回答四个问题：预测什么、谁处理、怎么验收、多少钱。

首批设备应选择故障损失高、数据基础较好、维修记录相对完整的对象。

不要一开始覆盖全厂。建议先选10至30台设备，运行3至6个月。

验收指标不能只有准确率，还要包含召回率、误报率和提前预警时间。

合同中应明确数据所有权、模型交付范围、运维费用和二次开发接口。

供应商报价需要拆分硬件、软件、实施、培训和年度服务费用。

项目上线后，每月都要核算业务收益，否则系统容易变成只展示不使用的看板。

一套可复制的机器学习实施案例，核心不是模型演示，而是持续闭环。

声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：sales@idmakers.cn删除，任何个人或组织，需要转载可以自行与原作者联系。