安灯响应闭环：从异常呼叫到复盘改善

安灯不是灯，而是一条事件状态链

传统灯号适合迅速提示异常，但若没有后续接单、处置和关闭记录，就只能证明“有人看到过”。闭环安灯把每次呼叫生成唯一事件，将发生位置、设备、工单或产品上下文、呼叫类型和当前责任关联起来。

状态设计要反映真实现场，而不是追求状态越多越好。未接单、已接单、处理中、待协同、已恢复和已关闭等状态应有清晰进入条件；临时恢复与根因关闭必须区分，否则事件关闭可能只是停止计时。

异常分类要对应责任，而不是堆砌代码

异常分类应优先覆盖现场真实的高频场景，例如设备、质量、物料、工艺、人员与安全相关呼叫。每一类都要有默认责任组、可选协同组和升级条件，不能仅做颜色区分。

自动设备报警与人工安灯呼叫也要区分。PLC故障码可以触发事件，但业务原因仍需现场确认；同一根因可能产生多个设备信号，应在分析层合并关联，而不是让多个通知同时驱动不同人员重复出动。

响应计时先定义语义，再讨论快慢

常见计时包括呼叫到接单、呼叫到场、到场到恢复、呼叫到关闭，它们分别反映认领、响应、处置和根因管理。若只保留一个总时长，就无法判断瓶颈在人员调度、备件等待、技术处理还是审批。

暂停计时必须有严格规则。等待备件或等待质量判定可以是独立状态，但不应随意用来美化响应指标；跨班、夜间和无人值守时段也要明确责任是否转移。原始时间戳不可因状态修订而覆盖。

• 发生时间：优先使用设备或系统事件时间，人工呼叫保留录入时间。
• 接单时间：具体责任角色确认承担，而非消息被群发。
• 到场时间：现场或批准的远程响应实际开始，口径需一致。
• 恢复时间：产线或设备经确认恢复规定功能，不等于永久修复。
• 关闭时间：处置记录和必要原因确认完成，后续改善可另建任务。

升级机制处理的是风险和资源，不是催促

升级条件可综合事件等级、持续时间、影响范围和重复发生情况。到达条件后，系统应将事件和已有处理上下文一并升级，避免新责任人重新询问全部信息；升级不等于原责任人立即免责。

通知渠道应服从工厂网络与终端条件，可采用现场声光、LED、Web画面或经批准的移动端消息。关键不是渠道数量，而是送达、认领与失败兜底是否可验证，不能将消息发送成功等同于人员已经响应。

与SCADA、OEE和维护流程怎样衔接

SCADA提供设备状态与原始报警，安灯负责把异常送入人员响应流程，OEE使用一致的停机事件分析效率损失，维护流程承接需要进一步维修或改善的任务。四者可共享事件标识，但各自的主责和关闭条件不同。

接口设计要避免双向覆盖。设备复位不应自动删除安灯处置记录，安灯关闭也不应自动改写OEE原始状态；若已有维护系统，安灯可按规则创建或关联任务，而不是默认再建设一套独立TPM产品。

• 设备事件只负责陈述事实，业务原因由授权角色补充。
• 安灯与OEE共享起止和原因映射，但保留各自分析口径。
• 需要维修的事件关联设备、故障模式、处理和备件等信息。
• 重复异常进入改善清单，验证对策后再更新标准与阈值。

用真实异常演练完成分阶段上线

实施时可先选一个区域和少量高频异常，验证从呼叫到恢复的全过程，再扩展自动触发、移动通知和分析。上线前应分别演练正常工作、无人接单、协同等待、跨班、断网和重复报警等场景。

复盘指标应同时包含数量、响应链、复发和改善执行，避免只按平均时长考核。平均数会掩盖极端事件，也会诱导过早关闭；需要回到具体事件分布和主要损失原因，才能形成有效改进。

• 盘点异常：合并同义类型，明确每类责任与默认处置入口。
• 定义状态：为接单、到场、恢复和关闭写出可观察的判据。
• 联调场景：验证设备、人员、网络和既有系统异常时的行为。
• 班组试运行：检查呼叫是否易用、通知是否准确、记录是否增加无效负担。
• 定期复盘：关闭重复问题，调整路由与标准，而非只通报排名。