1. Andon系统与异常管理全景

Andon（安灯）这个词来自日语“行灯”，原意是纸罩灯。它真正成为制造业术语，源于丰田生产体系：当工位出现异常，操作员拉下绳索或按下按钮，工位上方或产线看板上的灯亮起，音乐响起，班组长必须在节拍时间内赶到现场。它的核心不是“报警”，而是把异常从隐性变成显性，把等待变成响应。传统产线上，设备故障、缺料、质量波动往往靠人喊、靠电话、靠经验发现，信息在传递中衰减；Andon把“谁、在哪、出了什么问题、需要谁来、多久必须到”压缩成一次可被记录、可被追踪的信号。

理解Andon的价值，要区分三个层次。第一层是呼叫：让异常被看见。第二层是响应：让异常被处理，且处理有明确的责任人和时限。第三层是闭环：让异常被记录、分析、消除根因，避免重复发生。很多工厂只做到第一层，灯亮了、人来了、问题临时解决了，但没有留下结构化数据，于是同样的异常反复出现。Andon系统真正的工程价值，在于把这三层串成一条可度量的链路。

异常管理闭环通常包含五个环节：发现与触发、呼叫与升级、响应与处置、恢复与验证、记录与改善。发现可以来自操作员、设备传感器、质量检测或系统自动判断；触发时产生一条异常事件，携带工位、设备、时间、异常现象等基础信息。呼叫与升级决定“通知谁、多久没响应就升级到谁”。响应与处置是维修、工艺、质量、物料等角色按职责介入。恢复与验证确认产线回到正常状态，且产品/工艺参数满足要求。记录与改善则把这次异常转化为原因码、处置时长、根因和改进措施。原因码与SLA正是这条闭环上的两个关键“锚点”：原因码回答“是什么异常”，SLA回答“多久必须处理完”。

把原因码和SLA放进闭环来看，它们不是两张独立的表，而是同一套管理语言的两个维度。原因码解决“分类”问题：如果每次异常都写成“设备坏了”“有点问题”，数据就无法聚合，改善就无从下手。SLA解决“时限”问题：如果没有明确的响应和处置时限，异常处理就变成“有空再修”，产线等待时间不可控。两者结合，才能回答管理者最关心的问题——哪类异常最频繁、哪类异常最耗时、哪类异常最容易超时、超时后升级是否有效。

举个教学示例。某装配线设定Andon异常等级：A级为停线异常，B级为降速异常，C级为一般异常。原因码采用“大类+小类”结构，例如EQ-MOTOR-OVERHEAT表示设备类-电机-过热，MT-STOCK-SHORTAGE表示物料类-库存-缺料，QL-DIMENSION-OOT表示质量类-尺寸-超差。SLA按等级设定：A级要求3分钟内响应、15分钟内恢复；B级要求10分钟内响应、60分钟内恢复；C级要求30分钟内响应、当班内关闭。当A级异常触发后，若3分钟无人响应，系统自动升级到班组长；若15分钟未恢复，升级到生产主管并触发备线切换评估。这些参数是示例，实际取值应结合产线节拍、工艺复杂度和历史数据校准。

从工程落地角度看，Andon系统通常由触发层、传输层、应用层和展示层构成。触发层包括按钮盒、拉绳、PLC信号、传感器和MES/SCADA接口；传输层负责把信号送到Andon控制器或消息中间件；应用层完成事件生成、原因码匹配、SLA计时、升级规则和通知分发；展示层则是工位灯、看板、手机推送和报表。原因码在应用层被绑定到事件上，SLA计时器在事件生成瞬间启动，直到验证关闭才停止。这里有一个容易忽略的细节：SLA的起算点必须是“异常被系统确认”的时刻，而不是“操作员按下按钮”的时刻，否则误触发和重复触发会污染数据。同样，SLA的停止点应是“恢复并验证通过”，而不是“维修人员说修好了”，否则闭环不完整。