去年3月我在苏州一家做精密零部件的厂里做项目复盘。他们花了不少钱上了振动监测系统模型也调得不错轴承异常报警的准确率能做到85%以上。但我翻了三个月的报警记录发现一个扎心的事实将近40%的报警后面跟着的是一片空白——没有处理记录没有维修工单什么都没有。设备主管跟我解释报警发到企业微信群里大家看到了就哦一声该干嘛干嘛。除非设备真停了才有人想起来去查。说白了这套系统就差最后一公里报警知道该喊但没人接住它。这一公里就是和CMMS工单系统的打通。先搞清楚CMMS是什么以及为什么它这么难搞CMMSComputerized Maintenance Management System计算机化维护管理系统说白点就是设备台账维修工单备件库存的合体。国际上常见的有IBM Maximo、SAP PM现在叫EAM模块国内不少厂用的是自研或者本地厂商做的系统——说实话自研的占大头而且接口能力参差不齐。为什么难搞因为预测性维护系统和CMMS往往是两拨人、两个时期上的项目。监测系统可能是2024年上的CMMS可能是2016年就有的老系统数据库表结构十年没动过唯一对外的能力是一个陈旧的Web Service接口。你想打通就得在中间做翻译。我们的做法一般分三档按CMMS的接口能力往下选。第一档API直连报警自动生成工单最理想的情况CMMS有REST API。Maximo 8.x有标准的REST接口SAP可以通过OData暴露PM/CS模块的工单创建功能。我们去年在一家汽车零部件厂做的方案大概是这样监测数据在InfluxDB 2.7里检测到异常后走Kafka 3.6消息总线由一个Python网关服务把报警事件翻译成CMMS工单。核心代码其实不长import requests import hashlib import time CMMS_URL http://cmms.internal.abc-factory.com/api/v3/workorders API_TOKEN xxxx # 运维发的只写权限token千万别用管理员账号 def create_workorder(alarm: dict) - dict: # 幂等键设备编码报警ID做哈希防止Kafka重复消费导致重复派单 idem hashlib.md5( f{alarm[device_code]}:{alarm[alarm_id]}.encode() ).hexdigest() payload { order_type: PM, # PM预防性维修CM纠正性维修 priority: alarm[level], # 报警等级直接映射工单优先级 equipment: alarm[device_code], description: f[预测性维护] {alarm[device_name]}{alarm[fault_desc]}, suggest_action: alarm.get(advice, 安排点检确认), due_hours: 48 if alarm[level] 3 else 168, # 高等级48小时闭环 source_ref: idem, # 关键字段CMMS侧建唯一约束 } for attempt in range(3): try: r requests.post(CMMS_URL, jsonpayload, headers{Authorization: fBearer {API_TOKEN}}, timeout10) if r.status_code in (200, 201): return r.json() if r.status_code 409: # 409重复工单说明幂等生效不算失败 return {order_id: None, duplicated: True} except requests.Timeout: time.sleep(2 ** attempt) # 指数退避1s、2s、4s raise RuntimeError(f工单创建失败: {alarm[alarm_id]})踩坑提醒source_ref这个字段一定要加。我们第一版没做幂等Kafka一次rebalance重复消费了一批报警CMMS里凭空多出37张重复工单维修班长在电话里把我们骂了一顿。从那以后所有对接工单的服务必须带幂等键这成了我个人的一条铁律。还有个容易忽略的细节报警等级到工单优先级的映射最好让设备部门一起定。我们最初的映射是拍脑袋定的一线觉得三级报警就该当天处理系统里却给了7天时限两边的预期对不上工单按时完成率的数据就失真了。第二档中间表搬运土但稳如果CMMS没有API但能给你一个数据库中间表或者文件交换目录那就退一步做搬运工。定时任务每5分钟扫一次报警表把新报警写入CMMS的接口表CMMS侧的集成程序一般是乙方写好的负责捞数据生成工单。这个方案听着土但2026年了国内工厂里这种中间表集成依然占了至少一半。它的好处是稳定、可追溯坏处是时效性差而且出了断链两边都说不清是谁的责任。我的建议中间表方案必须配一张处理日志表记录每条报警的写入时间、CMMS消费时间、工单回传时间。出了断链三张时间戳一对责任马上定位。第三档RPA兜底体面地不体面遇到那种连中间表都没有、只能网页操作的CMMS国内真的有而且不少就只能上RPA了。用Playwright或者影刀之类的工具模拟人工填单。我知道很多人看不上RPA觉得不优雅。但反过来想一个每天就十几张工单的场景RPA脚本加兜底告警维护成本远低于推动甲方改造老系统。工程上管用比优雅值钱。当然RPA方案必须配失败转人工脚本填单失败3次自动把报警升级到值班群让人手动处理绝不能让报警无声无息地死在队列里。打通不是终点让工单反馈反过来喂模型前面说的都是报警→工单的正向流程但真正值钱的是反向闭环维修工处理完工单后填写的结论——更换6205轴承拆检发现外圈剥落——这是天然的高质量标注数据。我们在苏州那个厂加了每月一次的回流对账拉出当月所有工单的处理结论和报警记录join起来人工复核一遍。哪些报警是真故障正样本哪些是误报负样本直接更新到模型训练集。跑了半年报警准确率从85%提到91%。这不是调参调出来的是闭环数据喂出来的。有人可能会问为什么不让CMMS自动把结果回传理论上可以但实际中维修工在工单里填的东西五花八门——已处理正常换了个东西——这种文本质量直接自动回流就是灾难。所以老老实实人工复核宁可慢一点。最后说两句见过太多预测性维护项目模型准得漂亮就是没人用。说到底预测性维护不是算法项目是一个报警-工单-维修-反馈的闭环管理项目模型只是第一个环节。如果你的监测系统还在往微信群里发报警别急着优化模型先想想怎么把它和工单系统接起来。那才是真正省钱的地方。 预测性维护系统怎么和CMMS工单系统打通
去年3月我在苏州一家做精密零部件的厂里做项目复盘。他们花了不少钱上了振动监测系统模型也调得不错轴承异常报警的准确率能做到85%以上。但我翻了三个月的报警记录发现一个扎心的事实将近40%的报警后面跟着的是一片空白——没有处理记录没有维修工单什么都没有。设备主管跟我解释报警发到企业微信群里大家看到了就哦一声该干嘛干嘛。除非设备真停了才有人想起来去查。说白了这套系统就差最后一公里报警知道该喊但没人接住它。这一公里就是和CMMS工单系统的打通。先搞清楚CMMS是什么以及为什么它这么难搞CMMSComputerized Maintenance Management System计算机化维护管理系统说白点就是设备台账维修工单备件库存的合体。国际上常见的有IBM Maximo、SAP PM现在叫EAM模块国内不少厂用的是自研或者本地厂商做的系统——说实话自研的占大头而且接口能力参差不齐。为什么难搞因为预测性维护系统和CMMS往往是两拨人、两个时期上的项目。监测系统可能是2024年上的CMMS可能是2016年就有的老系统数据库表结构十年没动过唯一对外的能力是一个陈旧的Web Service接口。你想打通就得在中间做翻译。我们的做法一般分三档按CMMS的接口能力往下选。第一档API直连报警自动生成工单最理想的情况CMMS有REST API。Maximo 8.x有标准的REST接口SAP可以通过OData暴露PM/CS模块的工单创建功能。我们去年在一家汽车零部件厂做的方案大概是这样监测数据在InfluxDB 2.7里检测到异常后走Kafka 3.6消息总线由一个Python网关服务把报警事件翻译成CMMS工单。核心代码其实不长import requests import hashlib import time CMMS_URL http://cmms.internal.abc-factory.com/api/v3/workorders API_TOKEN xxxx # 运维发的只写权限token千万别用管理员账号 def create_workorder(alarm: dict) - dict: # 幂等键设备编码报警ID做哈希防止Kafka重复消费导致重复派单 idem hashlib.md5( f{alarm[device_code]}:{alarm[alarm_id]}.encode() ).hexdigest() payload { order_type: PM, # PM预防性维修CM纠正性维修 priority: alarm[level], # 报警等级直接映射工单优先级 equipment: alarm[device_code], description: f[预测性维护] {alarm[device_name]}{alarm[fault_desc]}, suggest_action: alarm.get(advice, 安排点检确认), due_hours: 48 if alarm[level] 3 else 168, # 高等级48小时闭环 source_ref: idem, # 关键字段CMMS侧建唯一约束 } for attempt in range(3): try: r requests.post(CMMS_URL, jsonpayload, headers{Authorization: fBearer {API_TOKEN}}, timeout10) if r.status_code in (200, 201): return r.json() if r.status_code 409: # 409重复工单说明幂等生效不算失败 return {order_id: None, duplicated: True} except requests.Timeout: time.sleep(2 ** attempt) # 指数退避1s、2s、4s raise RuntimeError(f工单创建失败: {alarm[alarm_id]})踩坑提醒source_ref这个字段一定要加。我们第一版没做幂等Kafka一次rebalance重复消费了一批报警CMMS里凭空多出37张重复工单维修班长在电话里把我们骂了一顿。从那以后所有对接工单的服务必须带幂等键这成了我个人的一条铁律。还有个容易忽略的细节报警等级到工单优先级的映射最好让设备部门一起定。我们最初的映射是拍脑袋定的一线觉得三级报警就该当天处理系统里却给了7天时限两边的预期对不上工单按时完成率的数据就失真了。第二档中间表搬运土但稳如果CMMS没有API但能给你一个数据库中间表或者文件交换目录那就退一步做搬运工。定时任务每5分钟扫一次报警表把新报警写入CMMS的接口表CMMS侧的集成程序一般是乙方写好的负责捞数据生成工单。这个方案听着土但2026年了国内工厂里这种中间表集成依然占了至少一半。它的好处是稳定、可追溯坏处是时效性差而且出了断链两边都说不清是谁的责任。我的建议中间表方案必须配一张处理日志表记录每条报警的写入时间、CMMS消费时间、工单回传时间。出了断链三张时间戳一对责任马上定位。第三档RPA兜底体面地不体面遇到那种连中间表都没有、只能网页操作的CMMS国内真的有而且不少就只能上RPA了。用Playwright或者影刀之类的工具模拟人工填单。我知道很多人看不上RPA觉得不优雅。但反过来想一个每天就十几张工单的场景RPA脚本加兜底告警维护成本远低于推动甲方改造老系统。工程上管用比优雅值钱。当然RPA方案必须配失败转人工脚本填单失败3次自动把报警升级到值班群让人手动处理绝不能让报警无声无息地死在队列里。打通不是终点让工单反馈反过来喂模型前面说的都是报警→工单的正向流程但真正值钱的是反向闭环维修工处理完工单后填写的结论——更换6205轴承拆检发现外圈剥落——这是天然的高质量标注数据。我们在苏州那个厂加了每月一次的回流对账拉出当月所有工单的处理结论和报警记录join起来人工复核一遍。哪些报警是真故障正样本哪些是误报负样本直接更新到模型训练集。跑了半年报警准确率从85%提到91%。这不是调参调出来的是闭环数据喂出来的。有人可能会问为什么不让CMMS自动把结果回传理论上可以但实际中维修工在工单里填的东西五花八门——已处理正常换了个东西——这种文本质量直接自动回流就是灾难。所以老老实实人工复核宁可慢一点。最后说两句见过太多预测性维护项目模型准得漂亮就是没人用。说到底预测性维护不是算法项目是一个报警-工单-维修-反馈的闭环管理项目模型只是第一个环节。如果你的监测系统还在往微信群里发报警别急着优化模型先想想怎么把它和工单系统接起来。那才是真正省钱的地方。