📅 · 阅读时长 4 分钟 · Meta Smart Factory 团队
这两样东西常被当作一次采购卖给你,但它们不是一回事。CMMS记录什么,预测性维护在它之上又加了什么,以及决定传感器数据变成一张工单、还是变成一张没人理会的图表的那条边界。
维护经理要的是一套“CMMS”。供应商给出的答案是传感器、机器学习,以及一块能提前三周预测故障的看板。真正的问题——凌晨两点设备再次故障时会发生什么——在这场对话里被弄丢了。CMMS和预测性维护不是互相竞争的两笔采购,但也不是同一笔采购。一个是记录一切的骨架,另一个是架在这副骨架之上的一种策略。先买后者、不买前者,是更常见、也代价更高的错误。
计算机化维护管理系统(CMMS)从设计上就不炫目:维修工单、预防性排程、备件库存和设备历史,全都放在一个地方,而不是一块白板、一张表格,外加碰巧记得上次发生了什么的那个技术员。按时间和按用量制定的计划——每月一次、每年一次,或者每运行N小时、每生产N件——由系统自动生成并跟踪,不必依赖有人碰巧注意到到期日。
这副骨架比架在它之上的任何策略都更重要,因为每一种策略都依赖同一份记录。如果没有工单去执行、没有技术员被指派、也没有这个轴承上一次保养究竟做了什么的历史记录,那么“轴承即将故障”的预测毫无价值。跳过工单纪律、直接上马预测性维护的工厂,通常会发现模型才是最容易的那部分。
预防性维护靠日历或计数器运行:每90天或每5万次循环——两者以先到为准——保养这台齿轮箱一次,而不管它实际状态如何。这种方式启动成本低——只需要一套带策略排程的CMMS,不需要任何传感器——但代价是给状态良好的设备做了过度保养,给负载异常的设备做了保养不足,因为时间和循环次数只是磨损的替代指标,而不是磨损本身的测量值。
预测性维护用真实测量取代了这个替代指标。来自IoT传感器或现有PLC的振动、温度和电流数据,喂给一个模型,在退化变成故障之前把它标出来——一个轴承的温度高于它自己的基线,一台电机在做同样的活时比一个月前多耗了电流。输出仍然是同一套CMMS里的一张维修工单;变的只是触发条件,从一个日期变成了一个真实信号。
说句实话:一个预测模型的好坏,取决于它学习所用的故障历史有多好。过去一年里既没有故障记录、也没有传感器历史的设备,根本没有东西可供模型校准。这就是预测性维护通常是工厂第二步而非第一步要做的事情的实际原因——CMMS必须先记录下真实的故障和真实的维修,“预测下一次”才有意义。
MTBF(平均故障间隔时间)和MTTR(平均修复时间)不是拿来好看的指标;它们是唯一能把“我们在做维护”和“维护真的有效”区分开的两个数字。MTBF上升,说明无论用的是哪种策略——预防性、预测性,还是两者都用——都在真正预防故障,而不只是在事后把它记录下来。MTTR下降,说明设备一旦故障,工单、被指派的技术员和备件都能足够快地到位,让停机成为一个机械问题,而不是一个行政问题。
一份只统计故障次数、却没有“报修”“开始”“关闭”时间戳的维护历史,无法诚实地算出这两个数字中的任何一个。这正是设备历史必须是CMMS里结构化数据的具体原因——按设备、产线和工厂计算的MTBF、MTTR、停机率、紧急呼叫率和成本,都应该来自技术员本来就要填写的同一份记录,而不是事后凭记忆重建。
维护计划和生产排程争的是同一段设备工时,如果它们分别建在两个互不通话的系统里,一方总会以意外的方式发现另一方的存在。维护把换轴承排在周二下午;生产在同一条线上排了一张周二下午必须交付的加急订单。总有一方要让步,而通常是当天早上谁嗓门大谁说了算,而不是哪个选择实际成本更低。
把维护窗口计划进生产排程里——而不是与它对着干——能把这场争吵变成一个排程约束,而不是一次对峙。APS在建立计划时,把维护窗口看作一个不可用的时段;维护在提出一个窗口时,看得到已经承诺出去的订单。双方都不会感到意外,因为双方用的都不是对方看不见的那份计划。
把MES与ERP、SCADA区分开的那道边界问题,在这里同样适用,也同样值得说清楚。MES拥有设备停机的那一刻:它在车间里实时采集停机原因——类别、时间戳、是哪道工序——因为停机在那里最先被看见。CMMS拥有接下来发生的一切:由那个停机原因自动生成的维护通知、派出的技术员、预留的备件、记录下来的维修,以及这张工单关闭那一刻,被并入这台设备MTBF的整个事件。
把两者当作可以互相替代的东西,两个方向都会出问题。让MES去管理维修,它根本没有备件库存、技术员技能或预防性日历的概念——那本来就不是它该干的事。让CMMS在没有车间数据接入的情况下自己去发现停机,每一条通知就都得靠有人记得手动录入,而这恰恰是当初买CMMS想要消除的那个纪律问题。真正管用的集成很窄、也很具体:MES里记录的一条停机原因,自动生成维护通知,设备、时间和故障代码都已经填好。没有人需要重新录入,也没有什么要等着被人注意到。
一张只告诉技术员要修什么、却不告诉他备件在不在架子上的工单,只是半套系统——而这正是相当多CMMS项目在第一年悄悄失败的地方。库存核对该做还是会做——只是变成了打电话去仓库问,而不是在软件里完成,这恰恰把延迟又放回了CMMS本该消除它的那个位置。
把维护工单直接和备件库存挂钩,能补上这个缺口:一张工单会预留它需要的备件;如果这个备件放在另一条线或另一个厂区,就通过带条码确认的跨仓调拨把它调过来;如果货架上真的没有了,就自动触发一张采购订单。技术员仍然要走到货架前,但软件已经提前回答了备件会不会在那里的问题——同样一次维修,这就是走十分钟和等两天的区别。
在Meta Smart Factory的各个维护项目中,从纯反应式或松散预防式,切换到一套叠加了预测性维护的CMMS,典型的变化是故障减少约45%、设备寿命延长约20%、维护成本降低约30%,工单也从此前纸质和记忆混杂的状态,变成完全数字化。这四个数字没有一个是单靠传感器得来的——它们来自组合:一套可靠记录每一次故障和每一次维修的CMMS,不再靠猜间隔的预防性计划,故障历史足以支撑的预测性告警,以及在技术员出发之前就已预留、而不是事后才发现缺货的备件。
实际要回答的排序问题从来不是“CMMS还是预测性维护”——而是哪个先来,答案永远是CMMS。预测性维护是一种策略,你把它对准的,应该是一套已经在真实记录什么在故障、代价是多少的维护系统。对准任何达不到这个标准的东西,模型都没有真实的东西可学。
与我们的专家交流探讨CMMS是记录系统本身——工单、预防性排程、备件和设备历史。预测性维护是架在它之上的一种策略:用传感器数据(振动、温度、电流)从一个真实信号而不是一个日历日期,触发工单。工厂完全可以只用纯预防性(按日历/按用量)的计划来运行CMMS,一个传感器都不需要;而预测性维护则始终需要底下有一套CMMS,才能针对它预测出的结果采取行动。
传感器数据——典型输入是振动、温度和电流,来自IoT设备或现有PLC——加上足够多的故障历史记录,好让模型学会这台特定设备的“异常”长什么样。背后没有维护历史的设备,不会给预测模型留下任何校准依据,这也是为什么预测性维护通常是在CMMS已经记录了一段时间真实故障之后才采用,而不是在此之前。
都不是。MES在车间里实时采集停机原因——停了什么、什么时候停的、为什么停。CMMS从这里接手:维护通知、指派的技术员、预留的备件、关闭的工单,以及由此算出的MTBF/MTTR。真正管用的集成是:MES里的一条停机原因自动生成维护通知,这样就没有人需要把同一个事件在两套系统里各录一遍。
MTBF(平均故障间隔时间)等于总运行时间除以故障次数;MTTR(平均修复时间)等于总维修时间除以维修次数。MTBF上升,说明维护策略在预防故障,而不只是在记录故障;MTTR下降,说明设备一旦故障,工单、技术员和备件都能足够快地到位,让停机成为一个机械问题,而不是一个行政问题。这两个数字都需要每张工单上带时间戳的“报修/开始/关闭”数据——一份只记录“坏过”的维护日志,无法诚实地算出这两个数字中的任何一个。
能,而且没有这层集成,维护和生产最终会各自独立地排同一段设备工时,然后以最难堪的方式发现冲突。把维护窗口计划进APS,意味着排程在制定计划时会把它当作一个不可用的时段,而不是维护和生产在两套从不互相通气的系统里,各自把同一个周二下午都排满。
只做预防性维护是一个正当的、不需要传感器的起点:一套带时间和用量计划的CMMS,已经解决了靠人脑记日历这个问题,而这正是第一期上线需要解决的大部分内容。等到有了足够的故障历史可以训练模型,并且相关设备一旦故障代价高昂或影响巨大、值得为提前发现付出传感器成本时,再加上预测性维护才划算——车间里不是每一台设备都需要从第一天起就做到预测性。