4. Andon信号触发与状态建模
Andon系统能否真正驱动现场协同，关键不在于灯亮不亮，而在于“灯亮之后系统知道发生了什么、下一步该谁动、什么时候算结束”。这要求我们把现场事件抽象成一组明确的状态，并规定状态之间的迁移条件。状态建模做得好，看板、消息推送、升级机制、统计报表才能建立在同一套语义之上；做得不好，就会出现“灯灭了但问题没解决”“响应了却没人处置”“重复呼叫淹没产线”等典型失效。
一、五个核心状态及其判定依据
一条Andon信号从产生到终结，通常经历呼叫（Call）→ 响应（Acknowledge）→ 处置（Handle）→ 恢复（Recover）→ 关闭（Close）五个状态。每个状态都必须有可被系统自动判定或人工确认的进入条件，否则状态机无法稳定运行。
- 呼叫（Call）：操作员按下呼叫按钮、拉绳、扫码或由设备自动上报异常，系统生成一条Andon事件。进入条件：触发源有效且未被抑制（如工位未处于停机维护屏蔽期）。此状态的核心数据是触发时间、工位、异常类型、优先级。
- 响应（Acknowledge）：责任人或响应方确认“我收到了，正在赶来”。进入条件：具备该工位响应权限的人员在终端上确认，或系统检测到响应方已到达（如刷卡、定位进入工位区域）。响应不等于问题解决，它只承诺“有人接手”。
- 处置（Handle）：响应人到达现场并开始实际处理。进入条件：响应人到达工位并开始作业，可由“到达确认”或“开始处置”按钮触发。此状态是耗时统计的主体，也是升级机制的主要观察窗口。
- 恢复（Recover）：异常已消除，产线或工位恢复可运行。进入条件：处置人确认问题已解决，且设备/工位状态回到正常（如设备复位、首件确认通过）。恢复是“物理上好了”，但流程上还未闭环。
- 关闭（Close）：记录归档、原因分类、责任归属确认完毕。进入条件：处置人填写原因与对策，班组长或系统审核通过。关闭是流程闭环，也是后续分析的数据入口。
需要特别强调：恢复与关闭必须分离。很多现场把“灯灭”等同于“结束”，导致原因、对策、责任全部丢失。恢复解决“能不能继续生产”，关闭解决“下次还会不会发生”。
二、状态迁移的触发条件与超时规则
状态机要落地，必须为每条迁移边定义“谁触发、什么条件、超时怎么办”。以下是一组可直接参考的迁移规则示例：
| 迁移 | 触发角色 | 进入条件 | 超时阈值（示例） | 超时动作 |
|---|---|---|---|---|
| Call → Ack | 响应人 | 终端确认或到达刷卡 | T_ack 按优先级 30s~10min | 升级通知上级 |
| Ack → Handle | 响应人 | 到达工位并点击“开始处置” | T_arrive ≤ 3min | 记录响应延迟 |
| Handle → Recover | 处置人 | 异常消除、设备复位、首件确认 | T_handle 按优先级 5~60min | 升级至主管/维修 |
| Recover → Close | 班组长/系统 | 原因分类、对策填写、审核通过 | T_close ≤ 4h（当班内） | 未关闭提醒 |
| Recover → Handle | 处置人/质检 | 恢复后复现或首件不合格 | — | 退回处置并标记复发 |
其中 T_ack、T_handle 等阈值不是拍脑袋定的，应结合历史数据：统计同类异常从呼叫到响应的P50和P90，把P90作为初始阈值，再根据管理目标逐步收紧。阈值太松则升级机制形同虚设，太紧则频繁误报、消耗管理注意力。
三、优先级规则的设计要点
优先级不是简单的“重要/不重要”，它至少影响三件事：通知对象、超时阈值、升级路径。设计时应遵循以下原则：
- 按后果定级，不按情绪定级。P0留给安全、停线、批量不良；P1是设备故障和质量异常；P2是物料与换型等待；P3是辅助请求。操作员不能随意把P3标成P0，否则优先级体系会迅速失效。
- 同级按时间先到先服务，跨级按高优先级抢占。当P0与P2同时存在，P0必须优先占用响应资源；但P0不应无限抢占，一旦恢复即释放。
- 优先级可动态调整，但必须留痕。现场情况变化时允许升级（如P2升P1），系统记录调整人、时间、原因，用于复盘。
- 抑制与合并规则。同一工位同一类型异常在短时间窗口（如60秒）内重复触发，应合并为一条事件并累加次数，避免刷屏；计划停机、维护屏蔽期内触发应被抑制，但需记录被抑制事件以备核查。
四、一个可落地的状态字段设计
无论用MES、Andon专用软件还是低代码平台实现，事件表至少应包含以下字段，才能支撑状态机运行：
event_id 事件唯一编号
station_id 工位/设备编号
signal_type 异常类型（安全/设备/质量/物料/辅助）
priority P0/P1/P2/P3
state CALL / ACK / HANDLE / RECOVER / CLOSE
call_time 呼叫触发时间
ack_time 响应确认时间
arrive_time 到达现场时间
recover_time 恢复时间
close_time 关闭时间
ack_by 响应人
handle_by 处置人
close_by 关闭审核人
root_cause 原因分类
countermeasure 对策
reopen_flag 是否复发退回
有了这些字段，T_ack = ack_time − call_time，T_handle = recover_time − arrive_time，响应率、处置时长、复发率都能直接计算。状态建模的价值最终体现在这些可度量、可追溯、可改进的数据上，而不是看板上的一个颜色。
总结来说，Andon状态建模的核心是：用明确的状态区分“有人知道了”“有人到了”“问题好了”“流程闭环了”四件不同的事，再用优先级和超时规则决定资源如何分配、何时升级。状态机清晰，现场协同才有共同语言，后续的看板、报表和持续改善才有可靠的数据基础。