产线亮了红灯，群里也发了消息，十分钟后仍然没人到场。班组长问维修，维修说没有接到任务；再看系统，报警早就被人点过“确认”。等生产恢复，报表又把最后补记录的时间算进停线，几个人对着同一次异常说出了不同的时长。
工单生命周期篇已经涉及暂停、返工和恢复。这篇单独追踪异常发生后的责任交接。所有身份、时刻和升级规则为独立教学设定，不是现场实测或某个 MES 产品的默认流程。
呼叫发出以后，要能找到当前负责的人
Andon 常称为安灯。Lean Enterprise Institute 的定义将它描述为显示现场状态、提示异常并召集快速响应的可视管理工具。异常可以涉及设备、质量、物料或作业条件，未必都交给维修部门。
接入 MES 时，先确定呼叫落在哪个工厂、产线、工位和执行任务，再根据问题类别、班次及资格找到责任角色。设备维修、缺料配送和质量处置分别关联各自的业务系统；MES 保存对当前生产任务的影响和执行结果。企业也可以用独立异常协同服务承接派单，职责需要在接入前约定。
| 现场说法 | 系统里需要保存的事实 | 仍要继续确认什么 |
|---|---|---|
| 消息已经发出 | 通知目标、发送及送达结果 | 谁实际承担处理责任 |
| 报警已经确认 | 哪个报警事件被谁确认、何时确认 | 是否已接业务任务，是否到场 |
| 问题正在处理 | 当前负责人、到场及处置记录 | 还缺哪些恢复条件 |
| 设备报警消失 | 指定报警不再满足激活条件 | 验证、质量条件及生产准入 |
| 异常已经结案 | 关闭依据和相关记录完整性 | 实际恢复发生在何时 |
Ignition 8.3 的报警说明将激活／消除与确认／未确认分开组合。本文另设业务接单，要求责任人接受具体任务；它与报警确认使用不同字段，不假设厂商报警状态天然包含全部业务责任。
三条通知不一定要建三张异常单
模拟装配资源 ASM-A01 在 09:00 出现报警 AL-A01。同一激活事件被投递两次，消息编号不同，但原始事件身份、资源和发生时刻一致。09:03 该报警消除，09:04 同一来源再次激活，产生新的报警事件 AL-A02，到 09:18 消除。
这里有三条激活通知投递、两个不同报警事件。确认和消除的状态变化另行保存，不计入这三条投递。重复投递按原事件查回处理结果；第二次激活保留新的报警身份，不能作为同一条重复消息删掉。
本例经现场复核，两次报警属于尚未处理完成的同一个业务问题，批准将它们关联到异常单 ANDON-A01。于是业务异常为一单，来源报警仍为两次。关联依据写入 REVIEW-A01，原始记录继续可查。
相同报警文字或相邻发生时间只能帮助找候选，不能单独证明同因。不同设备、不同原因，或已经恢复后再次出现的问题，应重新评估是否另建异常。错误合并会把第二次故障藏进旧工单；每次重传都建新单则会让多个岗位重复处理同一问题。
责任切换也保留历史。维修接手前，原负责人仍有跟进责任；转交申请发出、目标接受、实际到场分别记录。通知失败或接收人不在班时，应进入备用责任路径，不能把消息“发送成功”当成交接结束。
接单和复产分别计时，确认报警以后仍可能超时
本例全程位于同一计划生产时段，无休息窗口和其他并行停线，时钟已经校准。正文按北京时间显示，样本时间戳携带 +08:00。另定规则 AR-01：呼叫后五分钟内接单；从实际停线起二十分钟内恢复生产。两项都是本例的管理约定，不是行业统一服务时限。
| 时刻 | 本例发生的事实 | 管理上看什么 |
|---|---|---|
| 09:00 | 呼叫产生，首次报警激活 | 接单计时开始 |
| 09:01 | 操作员确认首次报警 | 尚无业务责任人接受任务 |
| 09:02 | 现场确认生产停止 | 复产计时开始 |
| 09:05 | 仍未接单，触发责任升级 | 按本例班表通知后备负责人 |
| 09:06 | 班组长接受业务任务 | 接单用时六分钟，已超约定 |
| 09:09 | 处理人员到场 | 从呼叫到场九分钟 |
| 09:20 | 本次处置工作完成 | 验证与复产条件继续核对 |
| 09:22 | 生产尚未恢复，触发复产升级 | 接单成功没有停止这项计时 |
| 09:24 | 规定验证完成 | 取得本例验证记录 |
| 09:26 | 本例复产条件获批 | 批准范围与身份可回查 |
| 09:30 | MES 取得实际恢复生产记录 | 停线及复产计时结束 |
| 09:40 | 补齐记录并管理结案 | 不延长已经结束的停线 |
09:05 的升级针对无人接单，09:22 的升级针对停线未恢复，分别有规则、截止时刻、目标角色和执行回执。同一升级任务重试使用原业务身份；重传不能再产生一项独立升级动作。
这里要检查通知工具与业务规则的区别。Ignition 8.3 的通知管道说明列出默认退出条件，确认、消除或暂挂都可能使报警退出相应通知管道，具体还要看事件管道配置。业务上的复产超时若仍需跟踪，就要另行配置与验收，不能只依赖已经退出的报警通知。
升级时保留原负责人、当前影响、已做动作和缺少条件，后备岗位才能接着处理。把同一条消息发到更多群里，没有形成新的责任接受记录，仍然可能继续等待。
处置结束后，继续核对验证、批准和实际恢复
本例第二次报警在 09:18 消除，处置工作到 09:20 才结束，规定验证到 09:24 才完成。这几个时刻分别有来源，不能将报警位变回正常直接写成异常解决。
设备停机篇已经区分维修结束、复产批准和实际开工。Andon 在此继续关联各岗位的结果：需要哪些验证、是否仍有质量挂起、哪些资源和在制品允许继续，由企业批准的恢复规则确定。现场控制与安全联锁按其自身授权执行，异常协同消息不替代设备控制许可。
09:26 获批后，仍等到 09:30 才取得实际复产记录。中间四分钟要保留实际原因和执行回执，不能按批准时间提前结束停线。若回执丢失，先查原动作结果，状态保持待核实，不重复发起设备动作。
到 09:25 的中间快照时，实际复产时间尚不存在。系统可以显示从 09:02 起已停二十三分钟，但完整停线时长仍未确定。字段缺失不能填成零，也不能把预计恢复时间写进实际时间。结案还需检查本例的责任、验证、批准、实绩和记录依据，不能靠点一次“关闭”补齐缺失事实。
Agent 可以汇总未接单、未到场和待验证清单，解释为什么触发升级。改派负责人、改变超时规则、批准复产及结案分别需要相应业务授权，目标结果要读回留存。
用时间分段看等待发生在哪里
主管先看各段事实，再调查具体原因。本例从呼叫到实际复产三十分钟，可分成以下连续区间。
待接单6 + 接单后到场3 + 到场后处置11
+ 验证4 + 验证后待批准2 + 批准后待实绩4 = 30分钟
实际停线 = 09:30 − 09:02 = 28分钟
管理结案补录 = 09:40 − 09:30 = 10分钟
异常单存续 = 09:40 − 09:00 = 40分钟
三十分钟包含停线前的两分钟，不能再与二十八分钟相加。十一分钟是本例到场至处置完成的区间，没有逐项工时记录时，也不能声称全部是直接维修工时。时间分段能定位继续调查的范围，还不足以直接认定某个人应承担全部损失。
这一个案例不能计算工厂平均修复时间、OEE 或损失产量。那些指标还需定义事件总体、计划时间、重叠区间、合格产出和节拍；通信未知区间也要单列，见现场事件篇。
| 验收变化 | 应得到的结果 |
|---|---|
| 同一激活事件换消息号重传 | 不增加报警事件或业务异常单 |
| 同一来源消除后再次激活 | 保留新报警身份，业务关联另有批准 |
| 已确认报警但未接受任务 | 接单时钟继续，达到本例条件后升级 |
| 已接单但生产尚未恢复 | 复产时钟继续，不能取消所有升级 |
| 验证、批准或实际恢复证据缺失 | 保留相应待处理状态，不宣告闭环 |
| 同一升级任务重试 | 关联原通知结果，不生成重复业务动作 |
可下载完整教学样本、复算程序和资料与适用范围。程序核对这一个已完成案例的时间顺序、批准关联、重复通知和指标，未连接真实 MES 或通知服务。公开资料核对于 2026-10-20；专题入口见MES 目录。