设备 OEE 分析交给 AI，停机原因谁来定？

设备 OEE 分析引入 AI 后，AI 只负责给出建议，不自己拍板停机原因，也不直接改原因代码表。单次停机原因由现场操作员确认，原因代码表由区域主管维护，归因假设和改进动作由生产工程师或持续改善负责人敲定。现网已有一篇讲预测性维护报警太多怎么分，另一篇讲故障诊断经验怎么进工单；本篇只讲 OEE 掉下来以后，损失时间算到哪个停机原因上。

停机数据从哪来、怎么归类

工厂做设备 OEE 分析，时间损失常按六大损失归类：设备故障、换型调整算可用率损失；空转和小停机、降速算性能损失；生产缺陷、开机阶段的废品算质量损失。核算时每一分钟损失只落进一类，不两头重算。机器状态直接从控制器信号采集，区分运行、故障、阻塞、缺料、换型，不靠交接班时人工回忆补填。每次停机记成一条独立事件，带上开始和结束时间、触发信号，把停机原因挂在这条事件上；原因和设备时间对不上，算出来的可用率就跟现场实情对不上。生产事件为什么要带齐时间、信号和在产产品这些上下文，见 企业上下文管理：AI 时代不脱节的基础设施。

上下游关联停机在采集阶段就要剥开：某台机器因为等上游来料或下游腾位置而处于阻塞、缺料状态时，这段等待时间不能算在它自己头上，要挂到引发整串停机的那台源头设备上。

停机原因代码表归区域主管维护，可以按三层设计：最上层是损失大类，中间层写归哪个部门处理（维护、物料供应、换型、质量），底下是具体原因。代码列表要短，别给同一个原因建几个同义代码；平时少见的状况先归进「其他，待审核」，区域主管定期审看。

AI 建议的停机原因谁来确认

机台停下来以后，系统可以配置成按停机持续时长分级处理，留住关键停机记录的同时，也免得操作员每逢短暂停顿都得去终端填表：

• 很短的停机：可以配置成记成小停机，免掉操作员手动填报。
• 稍长的停机：在机台终端弹窗提示，让操作员从短列表里选一个停机原因。
• 更长的停机：选完代码后，要求操作员补写一段具体说明。
• 再长的停机：升级到维护或质量部门跟进，并在事件单上打审核标记。

AI 在这一步可以配置成结合当时的故障码、停机前的控制器信号、当前在产产品、距上次换型的时长和历史记录，给当次停机推一个最可能的原因。建议显示在机台终端上，由当班操作员当场确认或手动改掉；改过的记录留存下来，成为后续标注样本。班组长和区域主管日常按机台和班次查看建议被操作员接受的比例。

损失排完序以后怎么找原因

单次停机确认完代码后，生产工程师和持续改善负责人接手做损失排序与归因。先把一段周期的损失按类别和时长做帕累托排序，抓出排在前面的几项主要损失，再按物料批次、供应商、班组、产品、设定值、距上次保养的天数做分层对比。

分层对比跑出来的关联关系，都属于待验证的假设，不能直接当成定论。比如数据显示某个物料批次跟开机或生产中的质量损失有关联，这只能当成递给来料检验部门的排查线索，不能凭一张表就判定供应商有责。最终采纳哪条归因假设、往哪个方向深挖，由生产工程师或持续改善负责人拍板。

数据不全怎么办与改进怎么验证

车间常碰上产量、停机代码、质量处置这类实际数据缺失或上传滞后。遇到数据缺失或滞后时，系统可以配置成不出归因结论，直接在报表和看板上标成「实际数据不足」，不事后凭空回填原因，也不沿用前一天的结论凑数。

排查确认成立的每条假设，都要转成带明确负责人的改进动作，比如提报维修申请、启动质量调查或修改换型标准。动作做完先别急着关单，要在可比的生产条件下对比改前改后的损失数据，确认对应的损失类别真的降下来了，才正式关闭这项改进任务；上线后怎么结合建议接受比例和实际损失下降来评估效果，见 Agent 上线后，效果评估该看哪几个数。

设备 OEE 分析：常见问题

下游机器因为上游卡顿跟着停了，这段停机损失算在谁头上？

算在引发这串停机的源头设备上。控制器信号会记下下游机器处于阻塞或缺料状态，但等上游或下游机器本身不算损失源头；归集可用率损失时，要把这段等待时间挂到引发整串停机的那台设备上，避免下游班组替上游背停机时长。

现场产量或质量数据还没传上来，AI 能先参考前一天的数据出归因吗？

不能。产量、停机代码、质量处置等实际数据一旦缺失或滞后，报表就统一标成「实际数据不足」，暂停输出归因结果，不凭空补填原因，也不沿用前一天的结论，等现场实际数据补齐后再做帕累托排序和分层对比。

停机原因代码又多又乱，AI 能帮忙归并吗？

AI 可以帮忙梳理线索，但不能直接改代码表。系统可以配置成让 AI 扫描历史停机记录，列出语义重复的同义代码、平时很少用到的代码、经常被操作员改掉的原因建议，连同汇总在「其他，待审核」里的常见说明一块生成清理清单交给区域主管；最终保留哪几个停机原因代码、怎么归入损失大类和责任部门，由区域主管修改代码表。