晚上十一点车间主任老赵给我打电话语气有点急“三号注塑机螺杆卡死刚才还在干活突然就停了这批货明天早上要发。”我打开MES系统的历史数据一看轴承温度在过去三天里从62℃悄悄爬到了78℃振动特征值也在持续上升只是大家都在忙产量谁也没注意到。这就是设备管理最扎心的地方设备不是突然坏的而是我们太晚发现它快要坏了。我在MES系统设备管理模块里花了小半年做的事归纳起来就五个字——故障提前预判。这篇内容把整个过程拆开讲数据怎么来、预判逻辑怎么做、基于若依框架怎么落地、上线以后还会踩哪些坑。适合MES实施工程师、工厂数字化负责人、设备科和搞物联网采集的同学参考。1. 设备最贵的成本是“没预告”的停机1.1 传统设备管理的三板斧为什么不够用车间里的设备管理绝大多数工厂还是三板斧。第一板斧是事后维修——坏了再修。设备能用就拼命用真正停下来的时候往往是半夜或者赶货的节骨眼。维修成本里的大头不是零件而是停产损失和紧急调度的成本。一台关键设备停两小时后道工序全堵住再算上临时找人、加急物流费用翻着倍往上走。第二板斧是定期保养——按固定周期做更换和清洁比如每三个月换一次润滑油。这种方式的毛病在于它根本不看设备实际状态。有的设备状态很好你按周期保养反而增加了计划外停机有的设备已经劣化到临界点离保养周期还有两周它根本撑不到那一天。第三板斧是人工点检——让操作工和维修工拿测温枪、听诊器去巡线。点检表上写满“正常、正常、正常”因为点检效果完全靠人的经验和责任心而且两次点检之间的空档期恰恰是故障最容易冒头的窗口。这三板斧的共同点是它们都在等设备给信号——要么是已经坏了要么是肉眼可见的异常。而故障提前预判要做的事情是把被动等待改成主动监测从连续采集的运行数据里找到正常状态偏离的苗头在设备真正停机之前给出预警。1.2 预判的边界哪些故障真的能被提前发现先理清一个概念免得后面越聊越乱。设备领域有几个词经常混用故障诊断、故障预判、预测性维护。故障诊断是出了故障之后通过数据或现象定位根因属于“事后破案”故障提前预判是在故障发生之前根据数据变化趋势推断设备状态正在朝哪个方向演化属于“事前预警”预测性维护则是以预判结果为依据把维护动作安排在最佳时机是“预判之后的行动”。MES设备管理里做故障提前预判实际是把诊断的前置关口挪到了故障之前再和工单体系打通就形成了完整的预测性维护闭环。但也不是所有故障都能预判。设备故障大致分两类一类是渐进劣化型比如轴承磨损、润滑油老化、刀具磨损、绝缘老化、散热片堵塞它的特征是运行数据有迹可循——温度缓慢爬升、振动逐渐加剧、电流波动变大另一类是突发随机型比如电压浪涌、外力撞击、操作失误、结构件突然断裂这类没有明显的渐进前兆硬要预判属于为难系统。做方案之前一定要先跟设备科核对清楚被监控设备的主要故障模式是渐进劣化还是突发随机。先盯住那些“有迹可循”的故障把这类停机降下来这套系统就已经值回票价了。1.3 这笔账怎么算才让人信服做数字化项目老板第一个问的就是投入产出比。故障预判的收益算法其实很简单就看非计划停机时间的减少。举个例子一条总装线平均每个月发生两次非计划停机每次停机4小时每小时产线直接损失大约是5000元。那这条线一个月因为非计划停机损失4万元一年就是48万。如果预判系统能把其中一半的停机转化为计划内维修——你有两三天的时间窗口去安排换件停机时间能从4小时压到1小时算下来一年能挽回的损失大概在20万上下。如果工厂有三条这样规模的产线这个数字就相当可观了。反过来看投入MES本身已经在跑设备数据采集的网关和传感器是可复用资产预判模块主要投入是开发工时和现场调试。我的建议是不要一上来就买昂贵的商业预测软件先用现有MES平台把规则型预判做起来跑出几个真实案例让车间看到效果再考虑要不要往机器学习方向投钱。2. 数据地基怎么打先把设备的“脉搏”接进MES2.1 三条数据通道按设备现状选故障预判这件事没有数据就是空中楼阁。设备数据采集有三条典型路径。第一条是控制器的标准接口。现在大部分数控机床、注塑机、压铸机、包装机都带PLC或者独立控制器常见通讯协议是OPC UA、Modbus TCP、西门子S7、三菱MC等。通过OPC UA服务器把点位暴露出来MES侧的采集服务按点位周期读取就行。好处是无需额外硬件、数据频率高坏处是需要设备厂商配合开放点位表有些老设备的点位表早就丢了只能靠电气工程师现场灌包抓包。第二条是外接传感器。老设备没有数字接口或者需要监测的关键物理量控制器里根本没有最典型的是加装振动传感器、温度传感器、电流互感器。无线加速度计贴到轴承座附近网关把数据汇到边缘盒子再转发给MES。成本很低一台设备几百到一千多块能搞定而且不抢设备厂商的协议。第三条是手工录入和检验数据。比如润滑油定期化验的金属颗粒含量、点检时的测温记录、设备清洁度检查结果这些低频数据同样有价值。把它们录进系统和实时数据放一起看往往能发现单看实时数据看不出来的问题。这里有个关键架构问题MES所在的IT网段和设备控制器所在的OT网段通常要隔离不允许直接打通。稳妥做法是在产线侧放一个边缘采集网关一边用OPC UA或Modbus从控制器读数一边把数据推送到MES的接入接口同时网关本地缓存断网时不丢数。采集服务不要挤在MES主应用里独立成一个采集进程或微服务后面调采集频率、加点位都不会影响生产管理功能的使用。2.2 点位表和采样频率怎么设计设备数据进来以后第一件事是把物理世界的信号变成MES里的数据字典我们叫点位表。一张点位表至少要有这些字段点位编码、点位名称、所属设备、数据类型、单位、采集频率、报警上下限、是否参与预判分析。采样频率不要盲目追求高。振动、电流这类变化快的信号原始采集至少做到秒级甚至毫秒级但没必要把原始值全量存进数据库温度、压力、流量这类慢变量5秒到1分钟采一次就够。实际做法是原始数据在边缘侧保留7到30天用于故障追溯落库的是降采样后的分钟级均值和极值再按小时和天做聚合存上五年也不心疼。点位表还要定义设备状态。判断预判逻辑是否触发首先要确认设备处于运行状态。如果设备本身就停机温度会自然回落这时候按运行中的阈值去判满屏都是误报。设备状态通常从PLC的运行信号拿拿不到就用电流阈值推断主电机电流大于某个值持续一段时间判定为运行中。2.3 数据质量预判系统的生死线我在这个项目上踩过的第一个大坑是数据缺得七零八落还在跑规则结果误报率高得没法看。数据质量对预判系统来说不是“优化项”是“生死线”。常见的数据问题有三个。第一是缺失PLC停机、网络抖动、采集进程重启都会造成读数空洞。解决办法是做间隙检测超过采集周期的两倍没有新数据就标记该时间段为数据缺失规则引擎自动跳过而不是把上一次的值继续拿来用。第二是噪声毛刺传感器受电磁干扰偶尔冒出一个离谱尖峰比如温度瞬间从60℃跳到120℃。解决办法是做滑动平均或中值滤波更稳妥的是在规则引擎里加一个合理性校验单次跳变量超过设定上限判为无效数据。第三是时间对齐振动是秒级数据温度是分钟级数据做组合判断时要把多条信号对齐到同一个时间窗口取过去5分钟窗口内的均值、最大值、斜率作为该窗口的特征再交给规则或模型。这些数据质量问题别指望靠后期洗数据解决。采集阶段就要定好规则边缘网关先把脏数据过滤一遍MES侧再做二次校验。数据干净了后面的预判规则才谈得上可信。3. 预判逻辑的三个层次别一上来就上机器学习3.1 L1 阈值告警先把最朴素的判断做扎实阈值告警是最朴素的一层某个点位超过设定值就产生一条告警。比如主轴温度超过85℃预警超过95℃报警。几乎所有MES都有这个功能但它最容易犯的错误是把阈值当成拍脑袋的数只有一个报警值没有分级、没有回差、没有防抖。我建议设计成完整的分级体系警告和报警两级再配两个工程参数——回差值hysteresis和确认次数debounce。回差的意思是温度升到90℃触发告警后要回落到87℃才复位避免温度在阈值附近抖动时告警反复横跳。确认次数是指连续N个采集周期都超限才判定告警成立瞬时尖峰直接滤掉。这两个参数加上两级阈值误报率能降一半以上。阈值告警适合温度、压力、流量这类有明确物理安全边界的参数优点是直观、好解释、调试快缺点是机械——它完全忽略趋势。很多故障在数值还没到阈值时趋势已经在恶化了。3.2 L2 趋势预判让数据斜率提前说话第二层是用趋势说话这是故障提前预判的核心。举个典型场景一台设备的轴承温度正常是62℃规定报警值是90℃。按阈值逻辑一切正常。但实际这三天温度从62℃稳步爬到78℃斜率明显为正说明承载系统或润滑系统已经开始劣化。如果等到90℃再报警轴承可能已经磨出问题了。趋势预判最实用的是滑动窗口斜率法。取过去N个数据点对窗口内的读数做拟合算出斜率k同时计算窗口平均值。规则是k大于某个值且平均值超过某个值同时设备处于运行状态判定为趋势异常发出预警。为什么要两个条件因为单看斜率刚开机时温度快速上升也是大斜率正但那不是故障是正常升温过程单看平均值又漏掉了“数值不高但一直在涨”的情况。两个条件一组合既能抓缓慢劣化又能避开开机阶段误报。代码实现其实很短核心逻辑就是取窗口首尾的平均段对比比完整线性回归更抗噪声工程上够用private boolean isTrendUp(ListDouble values) { if (values.size() 20) return false; double headAvg average(values.subList(0, 5)); double tailAvg average(values.subList(values.size() - 5, values.size())); double slope (tailAvg - headAvg) / values.size(); return slope trendThreshold tailAvg baseThreshold; }趋势参数窗口长度、斜率阈值、基准值怎么定没有捷径要靠历史数据去拟合。取设备过去90天正常运行的数据画出温度分布的百分位曲线拿P75和P90作为基准参考再结合设备说明书的允许范围去微调第五节细说这个调参过程。3.3 L3 多信号组合与机器学习把路铺给未来到了第三层就是多信号联合判断和机器学习。单看一个温度误报漏报都不少但如果温度、振动、电流、节拍时间同时出现异常故障置信度就高得多。比如注塑机合模异常的早期信号往往是液压油温度上升、主电机电流波动加大、单个循环周期变长三个信号一起看比只看电流可靠得多。到了机器学习这一步常见做法有两种一种是无监督异常检测比如对采集到的多维特征序列做孤立森林或者自编码器重构误差分析目标是发现“分布外”的异常模式另一种是有监督分类把历史故障数据和状态数据打标签训练模型判断设备处于正常、预警、危险哪种状态。但作为从业者我得说句实话大部分工厂有监督学习在初期根本跑不起来。原因很简单——没有足够多的带标签故障样本。一台设备一年也就故障两三次你还得保证每次故障前的数据都被完整记录样本量根本不够训练一个靠谱的分类器。所以我的建议路线是先用规则引擎把阈值和趋势预判跑起来让车间积累告警记录和处置记录工程师把这些记录里的“有效预警”和“误报”标注出来这本身就是干净的标签数据等积累了一定规模再拿这些标签去训练异常识别模型让模型反过来发现规则引擎没覆盖到的异常模式。让规则先跑机器学习跟进这是一条务实走得通的路径。我把三个层次的关键区别整理成一张表方便建立整体认知层次判断依据数据要求落地成本典型场景L1 阈值告警单点超限单个点位、低频即可低温度、压力、液位上限L2 趋势预判窗口斜率加均值分钟级连续数据中轴承温度爬升、刀具磨损L3 组合与机器学习多信号联合、异常模式多维数据需标签样本高关键设备综合健康评估4. 基于若依框架落地设备模块、数据表和规则引擎4.1 为什么要用若依框架做MES基座先说为什么选若依。MES这种系统权限、用户、菜单、操作日志、定时任务这些基础能力每个项目都得有自己写又慢又容易留坑。若依是国内用得最广的快速开发框架之一基于Spring Boot加Vue自带后台管理、RBAC权限、代码生成器和Quartz定时任务社区活跃踩坑资料一搜一大把。很多工厂的MES项目说穿了就是一个加强版的后台管理系统套上一堆业务表用若依做基座能省下大量基础开发时间把精力集中在设备管理、工单、质量这些业务模块上。要注意若依只是底座不是MES。设备管理、生产工单、质量追溯这些业务模块还是要根据工厂实际流程去设计。建议用RuoYi-Vue-Plus这类相对完整的版本它自带多数据源和WebSocket消息推送做实时告警正好用得上用经典版RuoYi-Vue也没问题WebSocket自己接一下也就几十行。4.2 表结构设计五张核心表一次建明白设备预判相关的表核心是五张设备台账、设备点位、实时读数、告警规则、告警记录。若依的代码生成器可以直接用下面的建表语句生成CRUD和后端代码再在此基础上改业务逻辑。CREATE TABLE mes_device ( device_id bigint NOT NULL AUTO_INCREMENT COMMENT 设备ID, device_code varchar(64) NOT NULL COMMENT 设备编码, device_name varchar(128) NOT NULL COMMENT 设备名称, device_type varchar(32) DEFAULT NULL COMMENT 设备类型, line_id bigint DEFAULT NULL COMMENT 产线ID, status char(1) DEFAULT 1 COMMENT 状态(1正常 0停用), PRIMARY KEY (device_id), UNIQUE KEY uk_device_code (device_code) ) ENGINEInnoDB COMMENT设备台账; CREATE TABLE mes_device_point ( point_id bigint NOT NULL AUTO_INCREMENT COMMENT 点位ID, device_id bigint NOT NULL COMMENT 设备ID, point_code varchar(64) NOT NULL COMMENT 点位编码, point_name varchar(128) NOT NULL COMMENT 点位名称, data_type varchar(16) DEFAULT number COMMENT 数据类型, unit varchar(16) DEFAULT NULL COMMENT 单位, warn_value varchar(64) DEFAULT NULL COMMENT 预警值, alarm_value varchar(64) DEFAULT NULL COMMENT 报警值, is_analysis char(1) DEFAULT 0 COMMENT 是否参与预判(0否 1是), PRIMARY KEY (point_id), KEY idx_point_device (device_id) ) ENGINEInnoDB COMMENT设备点位表; CREATE TABLE mes_device_reading ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, device_id bigint NOT NULL COMMENT 设备ID, point_code varchar(64) NOT NULL COMMENT 点位编码, read_time datetime NOT NULL COMMENT 采集时间, value decimal(18,4) NOT NULL COMMENT 读数, PRIMARY KEY (id), KEY idx_reading_query (device_id, point_code, read_time) ) ENGINEInnoDB COMMENT设备读数表; CREATE TABLE mes_alarm_rule ( rule_id bigint NOT NULL AUTO_INCREMENT COMMENT 规则ID, rule_name varchar(128) NOT NULL COMMENT 规则名称, device_id bigint NOT NULL COMMENT 设备ID, point_code varchar(64) NOT NULL COMMENT 点位编码, rule_type char(1) NOT NULL COMMENT 规则类型(1阈值 2趋势), condition_json varchar(500) DEFAULT NULL COMMENT 规则条件(JSON), severity char(1) DEFAULT 2 COMMENT 级别(1提示 2警告 3报警), status char(1) DEFAULT 1 COMMENT 启用状态(1启用 0停用), PRIMARY KEY (rule_id) ) ENGINEInnoDB COMMENT预判规则表; CREATE TABLE mes_alarm_record ( alarm_id bigint NOT NULL AUTO_INCREMENT COMMENT 告警ID, device_id bigint NOT NULL COMMENT 设备ID, point_code varchar(64) NOT NULL COMMENT 点位编码, rule_id bigint DEFAULT NULL COMMENT 触发规则ID, alarm_type varchar(32) NOT NULL COMMENT 告警类型(阈值/趋势), alarm_value varchar(64) DEFAULT NULL COMMENT 触发时的值, alarm_time datetime NOT NULL COMMENT 告警时间, severity char(1) DEFAULT 2 COMMENT 级别, status char(1) DEFAULT 0 COMMENT 状态(0待确认 1已确认 2误报 3已处置), confirm_user varchar(64) DEFAULT NULL COMMENT 确认人, confirm_time datetime DEFAULT NULL COMMENT 确认时间, remark varchar(500) DEFAULT NULL COMMENT 处置说明, PRIMARY KEY (alarm_id), KEY idx_alarm_query (device_id, alarm_time) ) ENGINEInnoDB COMMENT告警记录表;几个设计要点。第一实时读数表不要只存在MySQL业务库里量一大查询会拖垮主库。实际项目里我会把读数转入TDengine这类时序库MySQL里只保留最近一小时的数据用于规则引擎扫描历史数据走API查询。第二告警规则用JSON存条件是为了兼容不同设备不同点位不同参数的差异不用每加一条规则就改一次代码。第三告警记录必须带状态和处置人字段这是后面调误报率、算命中率的唯一依据没有这些字段预判效果好不好就是一笔糊涂账。4.3 规则引擎和定时任务怎么接若依自带Quartz定时任务正好用来做规则扫描器。设计是一个每分钟执行一次的任务处理流程分四步加载所有启用规则和对应设备的近期读数按规则类型分发到不同的评估器阈值规则评估当前值是否超限趋势规则评估窗口斜率是否超阈评估通过后做告警去重判断——同一点位同一规则在最近半小时内已经产生过有效告警且未处理的不再重复产生避免每分钟刷屏写告警记录再推给前端页面同时推送给设备科和当班机修。核心代码是这个思路用Spring的定时注解就够Component public class AlarmScanTask { Resource private AlarmRuleService alarmRuleService; Resource private DeviceReadingService readingService; Scheduled(cron 0 * * * * ?) public void scan() { // 1. 查询启用规则 ListMesAlarmRule rules alarmRuleService.listEnabledRules(); // 2. 按设备分组取最近30分钟读数 MapLong, ListDeviceReading readingMap readingService.loadRecent(30); for (MesAlarmRule rule : rules) { ListDeviceReading readings readingMap.get(rule.getDeviceId()); if (readings null || readings.isEmpty()) continue; // 3. 根据规则类型调用评估器 boolean hit evaluate(rule, readings); if (hit) { alarmRuleService.createAlarm(rule, readings.get(readings.size() - 1)); pushService.push(rule, readings.get(readings.size() - 1)); } } } }实际项目里我会在evaluate方法里把阈值、趋势、组合判断都接到条件表达式上不要在定时任务里堆if else否则规则一多代码就没法维护了。4.4 看板与告警工单联动预判的最终产出不是一条告警记录而是设备科的处置动作。所以告警产生之后必须跟工单体系打通设备科在告警列表里确认这条预警系统按规则自动生成维修工单或保养工单指定责任人处置完成后填写处置说明和结果——是轴承磨损、是传感器误报、还是润滑油不足。这个结果数据回流到告警记录表正是前面说的标签数据来源。展示端用ECharts做两块就够一块是设备实时趋势曲线选择任意设备任意点位显示最近24小时到7天的曲线叠加预警线和报警线另一块是设备健康度排行榜把每台设备各点位的偏离程度加权计算成一个健康分分数低的排在前面。车间不需要懂算法看排行就知道今天优先去检查哪台设备。5. 上线之后的调优误报、漏报与车间信任5.1 “狼来了”效应是预判系统最大的敌人预判系统上线之后我经历过一段特别尴尬的时期告警天天有但十有八九到现场一看设备活得好好的。几次下来机修师傅看到系统预警都懒得去了——这就是“狼来了”效应。告警系统一旦失去权威性再好的算法都是摆设。怎么破我的经验是三管齐下。第一控制告警频次和级别。把大部分规则设置成“警告”级别真正高置信度、高组合度的判断才升到“报警”避免所有消息都走最高优先级。第二增加确认和复核流程。每条告警必须由设备科人员响应并填写结论系统按周统计每台设备的告警命中率命中率低的规则要回炉调整。第三减少无效推送。告警只推给当班责任人不搞全员广播让收到消息的人知道这事和自己有关。5.2 阈值怎么定才科学这是项目里被问得最多的问题。我见过不少项目预警值是设备厂商工程师凭经验给的或者干脆复制同行参数结果要么报警太频繁要么永远不报警。科学的定法是用历史数据说话。第一步给每台设备每个点位攒至少30天以上健康运行数据时间最好跨一个完整生产周期包含不同班次、不同负载的产品组合。第二步对数据做百分位统计把P90设成预警参考值P95设成报警参考值这只是一个起点。第三步结合现场验证调整——拿着这两条线跑几天把误报和漏报的案例标记出来动态微调。实操中你会发现不同设备哪怕型号相同阈值都可能不一样因为安装位置、散热条件、负载率都不同还要考虑季节性冬天和夏天的油温基准明显不同规则参数最好支持按月份配置或者按环境温度修正。提示参数调整一定要留痕。每条规则的参数变更都记录到变更日志里哪条规则哪天改了哪个值、为什么改、效果怎么样都记下来。这套调参史就是后续做算法优化的金矿。5.3 预判效果用什么指标衡量设备科的人不关心你用了什么模型只关心两件事报出来的到底准不准真正的故障有没有漏掉。所以要算两个指标。命中率也就是精确率系统预警后在规定窗口期内确实发生劣化、需要维修处置的比例。分子是所有被确认有效的预警分母是全部预警。命中率长期低于30%的规则要重点关注大概率是参数太敏感或者规则本身不成立。覆盖率也就是召回率设备实际发生的可预判故障里系统提前预警到的比例。覆盖率看的是漏报。不过要客观对待突发随机故障本来就不该算进漏报里统计口径要和设备科提前说清楚。上线前三个月目标不是好看的数字而是把告警闭环跑顺畅、让车间信任这套系统。等处置记录积累够了再回头调命中率和覆盖率。我见过一个项目上线第一周命中率只有20%车间骂声一片但处置记录越来越规范之后团队根据反馈把趋势窗口从10分钟改成30分钟、把斜率阈值调高两个月后命中率稳定在60%以上。这个过程里真正进步的不是算法而是大家对这个设备群运行规律的理解。6. 从故障预判到预测性维护闭环的延伸6.1 闭环流程预警不只是通知故障预判在MES里的价值要在和维护流程闭环之后才真正兑现。一个成熟的闭环是系统预警、设备科响应确认、生成预测性维护工单、现场检查处置、填写处置结论、结论反哺规则参数。每一步都要有时效要求比如预警后半小时未响应告警升级并抄送车间主任四小时内未处置再升级。让预警真正变成动作而不是又一个需要填的表。6.2 设备健康度从单点判断走向综合评估当点位和规则多了以后单条规则的告警会越来越不够用。这时候可以做设备健康度评分每个点位根据偏离程度打分加权汇总成设备健康分。权重怎么分关键点位的偏离权重高比如轴承振动占30%、温度占20%、电流波动占15%再扣除最近故障次数和维修次数。健康分从0到10080分以上绿色正常60到80黄色关注60以下红色预警。这个分数展示在设备看板上车间每天早晨开工前扫一眼排行先处理最红的设备管理效率会高很多。健康度评分的好处是把多维度信息压缩成一个车间主任能直接做决策的数字。做评分时要注意分数不是真理是引导。它帮你决定先看哪台设备最终判断还是要落到点位曲线和现场检查上。6.3 再往远处走备件、能耗和生产联动预判系统的价值还能继续延伸。第一个延伸是备件管理——系统预测某台设备轴承在未来两周内风险升高备件库刚好没库存预警可以自动触发备件申购提醒把“坏了我再找件”变成“还没坏我就备好件”。第二个延伸是能耗联动——设备劣化初期往往能耗上升同一台设备横向对比单位产出的电耗异常上升本身就是故障前兆这个维度通常被忽略但非常有效。第三个延伸是和排产联动——对于预测风险较高的设备生产排程时尽量避免给它安排交期极紧的连续订单多留出检修窗口。不过这些都是后话。我的建议是先把设备管理模块的数据、规则、告警闭环做扎实再一步步往外扩。很多人一开始想得很宏大要做AI预测平台结果连设备数据采集都没做全最终项目烂尾。从一条温度趋势线开始比从一张PPT蓝图开始要靠谱得多。最后分享一个小心得。做故障提前预判最难的不是算法是跟车间建立信任。我踩过的坑是上线初期为了展示效果把预警阈值调得很灵敏结果告警刷屏机修师傅直接无视。后来我反过来宁可漏掉几条边缘预警也要保证报出来的每一条都经得起现场验证。前两个月命中率不算高但每一条有效预警都认真反馈、认真复盘车间就慢慢相信这套系统是真的在帮他们提前发现问题。有了信任后面调整参数、增加规则配合度完全不一样。设备预判这件事做的其实不是预测模型是车间的工作习惯——这一点做得越久体会越深。