安灯系统怎么落地：从一键呼叫到响应计时的完整链路
安灯系统（Andon）是车间里用来上报异常、分派响应并跟踪处理过程的一套软硬件组合：工位的呼叫按钮触发信号，电子看板与移动端同步显示，系统按预设规则把呼叫送到责任人，并记录从呼叫到关闭的各个时间点。它要解决的问题不是「灯亮不亮」，而是异常发生后，谁在什么时候接、多久到场、怎么关单、事后能不能查。
很多工厂装过三色灯，也拉过绳，最后变成「灯亮着没人管」。原因通常不在硬件，而在呼叫之后缺了四个环节。
一、异常从发生到关闭，常见的四个断点
呼叫没有入口。 异常靠嘴说、靠微信群里发一句「三线缺料」。谁听见算谁的，没听见就继续等，等待时长取决于运气。
信息不落地。 电话打了、消息发了，但「哪条线、哪个工位、什么问题、什么等级」散在几个渠道，班组长到场开口常是「你刚才说什么来着」。
没有升级路径。 责任人在处理另一件事、手机静音或在休假，这条呼叫就停在原地，系统不会替他记着。
没有过程数据。 复盘时靠印象判断谁响应慢，印象通常偏向声音大的人，而不是响应时长真正长的那条线。
这四点对应四件事：呼叫入口、信息同步、升级规则、闭环记录。
二、呼叫入口：无线按钮与原因分键
工位侧通常用无线呼叫按钮，按下后通过无线网关进入系统，同时驱动现场三色灯与声光报警器。
技术上有两点值得注意。一是不碰产线主体：无线按钮粘装或卡装即可，不需要布线穿管，老线改造不用为了一颗按钮安排停电窗口。二是按原因分键：缺料、设备故障、质量问题、换型调试各占一键，操作工不用解释，按对应那颗就行，后台拿到的是结构化原因，不是一句话描述。
通信侧常见做法是网关走 WiFi 或 4G 接入局域网，再由采集服务转成 Modbus TCP、OPC UA 或 MQTT 报文进后台。产线已有 PLC 的，也可以把按钮信号并入 PLC 的输入点，由上位机统一读取。
三、看板同步与移动端接单
呼叫按下后，车间电子看板应当同步出现这条记录：线别、工位、原因、等级、已等待时长。看板的价值是把「正在等」变成公开可见的状态，而不是让异常停在某个人的手机里。
移动端同步推送，班组长、维修、物料员在手机或 PDA 上收到，点「接单」，系统记录接单人与接单时间。
接单这个动作是整个链路的关键节点。 它把「我看到了」变成一个可追溯的状态。没有这一步，系统只知道呼叫发生了，不知道有没有人接手，响应时长也算不出来。
四、升级规则：逐级上报与超时自动升级
每类原因配一条升级路径。例如设备类：先到维修班组，设定分钟数内无人接单，自动升到设备主管；再超时，升到生产经理。物料类可能先到物料员，再升到仓储主管。
配置时有三条经验：
- 分级只设两到三级。 层级太多，消息在中间层悬停，反而更慢。
- 按原因分别定时长。 设备故障与缺料的可接受等待时间不同，用同一套阈值没有意义。
- 升级要通知到人，不能只落到看板。 只落看板等于把责任推回现场。
升级不是惩罚机制，它的作用是防止呼叫停在某个正在忙的人手里。规则可配置，改一次就生效，比反复开会强调更可靠。
五、闭环记录与响应计时考核
一条呼叫的生命周期，系统记录四个时间点：呼叫时间、接单时间、到场时间、关闭时间。关闭时填写处理结果与原因分类。
这四个时间点直接支撑三组指标：平均响应时长、超时次数、重复呼叫率。重复呼叫率常被忽略——同一个工位一周内反复叫同一类异常，说明上一次没修到根因，这条数据比响应时长更能反映改善是否真的发生。
考核的对象应当是「每一段用了多久」，而不是「谁被叫了」。把考核压在按钮上，会出现一个可预见的后果：按钮被绕过，异常重新回到口头传递。
原因字典也不宜一次列二十个。先按现场最常发生的四到六类设置，跑一个月再拆细。分类过细，现场记不住，最后都选「其他」，报表就失去了分析价值。
六、与 MES、ERP 的边界
这一点需要在项目启动前说清楚，否则实施阶段容易扯皮。
安灯系统管异常事件与响应过程：谁在何时呼叫了什么、谁接的、多久到场、怎么处理。
MES 管工单、工艺、物料与生产执行；ERP 管订单、库存与成本。
三者是接口关系，不是替代关系。安灯把异常事件与停机时段传给 MES，MES 把工单与产品信息回给安灯，两侧报表才对得上。接口只传必要字段：工单号、设备编号、异常类型、起止时间。把两套系统的数据模型硬拼在一起，后期维护成本会成倍上升。
七、老线改造的实施顺序
现场设备品牌不统一、状态不透明、改造还要兼顾连续生产，是改造类项目最常见的三个前提。可行的顺序是分段推进：
阶段一，先把呼叫与设备状态接起来，让异常「看得见」——安灯按钮、声光报警、与 PLC 或 OPC UA 的设备状态采集同步上线。
阶段二，按产线分段接入监控，一段稳定了再动下一段，不追求一次铺满。
阶段三，接整线 MES，把工单、质量与追溯纳入。
反过来做，先上工单与报表，底层数据还没稳，现场会被两套口径压住。分期推进的好处是每一段都能单独验收，问题暴露在小范围内。
八、选型时看哪几项
- 呼叫通道与原因字典能不能自己配：按钮数量、原因分类、升级路径是否为配置项，而不是写死在程序里。
- 时间戳是否四点齐全：只有呼叫与关闭两个点的系统，算不出响应过程。
- 接口清单：是否支持 Modbus TCP / RTU、OPC UA、S7、MC 协议，能否向 MES 输出异常事件。
- 部署方式与授权：本地部署、多车间多工厂扩展、数据库选型、离线授权是否支持。
- 看板与移动端是否同源：两端数据来自同一套后台，才不会出现看板与手机对不上的情况。
常见问题
Q：安灯系统和 MES 的异常管理模块有什么区别？
MES 的异常管理通常挂在工单与生产执行下，关注异常对工单进度的影响；安灯系统关注异常事件的呼叫、响应、升级与闭环过程。两者可以并存，通过接口交换工单号与异常事件，不必二选一。
Q：没有 PLC 的老产线能装安灯吗？
可以。无线呼叫按钮与无线网关自成一套，不依赖产线控制系统；需要设备状态时，再通过加装采集模块或读取电表、计数信号补充。
Q：响应计时考核会不会让班组不愿意按按钮？
会，如果考核直接对着「按了多少次」或「谁被叫了」。可行的做法是考核响应时长与超时次数，并且明确重复呼叫指向的是流程问题而不是个人，按钮才不会被绕过。
需要按自己的车间做一次落地设计，可以先做一次方案设计，把呼叫点、原因分类与升级规则理清楚，再谈系统。
相关方案
上海橙轩智能自 2009 年起专注制造业数字化,业务覆盖 MES、SCADA 上位机、设备数据采集、设备标机软件、机器视觉、OEE、质量追溯、能源管理与储能 EMS、远程运维等方向,覆盖 11 个重点行业方向并具备通用平台能力,累计形成 600+ 项目与方案实践,具备从现场控制到智能化的跨层整合能力与长期服务体系。公司为上海市高新技术企业、科技型中小企业,持有多项自主软件著作权。欢迎咨询。
