★ FEATURED ARTICLE 简介这份PDF资料围绕安灯系统Andon在生产现场的应用与解决方案展开面向制造企业的生产管理、设备维护及品质管理人员也适合精益生产学习者参考。内容系统梳理了安灯系统在汽车、电子、机械等行业的应用场景归纳其及时响应异常、提升效率、降低成本、改善品质与提高管理效率五大作用并详解现场信息采集装置、现场看板与B/S后台管理系统三部分物理结构以及从异常监控、信息发送、处理、状态跟踪到数据分析的五步处理流程。资源包为1个PDF文件约1.54MB结构紧凑便于按章节查阅。目前已有154人学习适合希望快速建立安灯系统整体认知、对照现场落地异常响应机制的读者参考。1. 安灯系统落地前先把这三个问题想清楚车间里最怕的不是设备坏是坏了没人知道、知道了没人来、来了不知道找谁。安灯系统Andon解决的就是这条链路——把异常从“口头喊话”变成“有记录、有响应、有闭环”的流程。但很多团队一上来就问“买哪家”结果系统上线三个月工人嫌麻烦不用班组长嫌弹窗太多关掉最后变成一块挂在墙上的电子看板。问题不在产品在于没想清楚三件事异常怎么触发、响应怎么升级、数据怎么复盘。这篇内容围绕安灯系统的应用场景和解决方案展开从触发方式、B/S 架构选型、QSmart Andon 这类典型方案的配置逻辑到上线后最容易翻车的地方给出一条能照着走的路径。适合正在选型或已经上线但用不起来的制造现场工程师、IT 对接人和生产主管。2. 安灯系统的触发方式与响应机制从拉绳到自动采集2.1 三种触发方式的实际差异安灯系统的核心不是看板是触发。触发方式决定了这套系统能不能真正跑起来。常见做法有三类物理拉绳/按钮触发是最传统的方式。工位上方拉一根绳或装一个按钮盒工人发现异常一拉对应工位的安灯亮起同时触发呼叫。优点是操作零学习成本缺点是只能表达“有异常”说不清是什么异常。适合工位固定、异常类型少的场景比如总装线的某个装配工位。终端界面触发是在工位旁的触摸屏或平板上一键选择异常类型。工人点“缺料”“设备故障”“质量异常”系统自动带上工位号、时间戳、异常类型。比拉绳多了一步操作但信息完整度高很多。我一般建议新上线的项目优先用这种方式因为后续的数据分析全靠这个分类字段。设备自动触发是通过 PLC 或传感器采集设备状态达到阈值自动报异常。比如注塑机温度超限、CNC 刀具寿命到期。这种方式最“无感”但对设备接口和协议对接要求高通常只在关键设备上做。三种方式不是互斥的实际项目里经常混用关键设备自动触发普通工位终端触发应急场景保留物理按钮。2.2 响应升级规则怎么设才不形同虚设触发之后如果没人响应安灯就只是个灯。响应升级机制是安灯系统的灵魂。常见做法是按时间分层层级触发条件通知对象通知方式一级异常发生班组长工位看板变色 终端弹窗二级超过 3 分钟未响应车间主管短信/企业微信推送三级超过 10 分钟未解决生产经理电话呼叫 看板红色闪烁四级超过 30 分钟未闭环厂长/跨部门升级至例会通报这个时间梯度不是拍脑袋定的。3 分钟的依据是大多数装配工位的节拍在 60-90 秒3 分钟意味着已经影响了 2-3 个节拍班组长必须到场。10 分钟意味着单工位停线已经影响到整条线的产出。30 分钟则是需要跨部门协调比如设备科、质量部的级别。参数设置上每个层级的超时时间应该做成可配置项而不是写死在代码里。不同产线、不同班次的容忍度不一样。夜班人少响应时间可以适当放宽但升级路径不能断。2.3 用状态机理解安灯的完整生命周期安灯系统本质上是一个状态机。一条异常记录从产生到关闭经历的状态包括触发Triggered→ 已响应Acknowledged→ 处理中In Progress→ 已解决Resolved→ 已确认Closed每个状态转换都要记录操作人和时间戳。这里有个容易忽略的点“已解决”和“已确认”是两回事。解决是处理人说“我搞定了”确认是发起人或班组长说“确实搞定了”。很多系统把这两个合并导致异常被草草关闭数据失真。用代码表达这个状态机的核心逻辑# 安灯异常状态机核心转换逻辑 from enum import Enum from datetime import datetime class AndonState(Enum): TRIGGERED triggered # 已触发等待响应 ACKNOWLEDGED acknowledged # 已响应处理人已接单 IN_PROGRESS in_progress # 处理中 RESOLVED resolved # 已解决等待确认 CLOSED closed # 已确认关闭 # 合法状态转换表 VALID_TRANSITIONS { AndonState.TRIGGERED: [AndonState.ACKNOWLEDGED], AndonState.ACKNOWLEDGED: [AndonState.IN_PROGRESS], AndonState.IN_PROGRESS: [AndonState.RESOLVED], AndonState.RESOLVED: [AndonState.CLOSED, AndonState.IN_PROGRESS], # 确认不通过可打回 AndonState.CLOSED: [] # 终态 } def transition(current_state, target_state, operator, comment): 执行状态转换记录操作人和时间 if target_state not in VALID_TRANSITIONS[current_state]: raise ValueError(f非法转换: {current_state} - {target_state}) record { from: current_state.value, to: target_state.value, operator: operator, timestamp: datetime.now().isoformat(), comment: comment } # 写入数据库并推送看板更新 return record这段代码的关键在于VALID_TRANSITIONS表——它把业务规则固化成了数据结构。RESOLVED状态可以打回IN_PROGRESS对应的是“确认不通过重新处理”的场景。没有这个回退路径异常处理就变成单向流程确认环节形同虚设。参数说明operator字段必须记录真实操作人不能填系统默认值否则后续追责和绩效统计全是废数据。comment在打回场景下必填其他场景可选。3. B/S 架构安灯系统的部署方案与 IE 浏览器兼容处理3.1 为什么很多工厂还在用 B/S 架构安灯系统的部署架构主要分两种C/S客户端/服务器和 B/S浏览器/服务器。C/S 需要在每台工位终端上装客户端软件B/S 只需要浏览器打开网址就能用。工厂现场选 B/S 的理由很实际工位终端数量多少则几十台多则上百台。C/S 架构下每次系统升级都要逐台更新客户端IT 部门跑断腿。B/S 架构下服务器更新完所有终端刷新页面就是最新版。而且工位终端往往配置不高装一堆客户端软件容易卡。但 B/S 架构在工厂有个绕不开的坑IE 浏览器。很多工厂的工位终端是几年前采购的工控机系统还是 Windows 7默认浏览器就是 IE。更麻烦的是有些安灯系统的看板页面用了 ActiveX 控件来对接本地硬件比如呼叫按钮、LED 灯控这些控件只能在 IE 里跑。3.2 IE 浏览器兼容的三种处理路径路径一升级终端浏览器。把工位终端的默认浏览器换成 Chrome 或 Edge。这是最干净的方案但前提是终端硬件支持。Windows 7 最高只能装到 Chrome 109再往上就不支持了。如果工控机还在跑 Windows 7这条路走不通。路径二双核浏览器兼容模式。国内很多浏览器比如 360、QQ 浏览器有双核模式可以切换到 IE 内核渲染。配置方式是在页面头部加 meta 标签!-- 强制使用 IE 内核渲染兼容 ActiveX 控件 -- meta http-equivX-UA-Compatible contentIEedge !-- 指定使用 IE11 的渲染模式 -- meta http-equivX-UA-Compatible contentIE11但双核浏览器的兼容模式不稳定不同版本行为不一致生产环境慎用。路径三服务端渲染降级。如果安灯系统的看板页面是自己开发的可以在服务端判断 User-Agent对 IE 请求返回简化版页面——去掉复杂的 CSS 动画和 ES6 语法用 ES5 重写关键交互逻辑。这种方式工作量大但最可控。我一般建议新项目直接要求终端用 Chrome/Edge把 IE 兼容从需求里划掉。老项目如果必须兼容 IE优先走路径三把兼容层做在服务端前端代码保持干净。3.3 一个最小可用的 B/S 安灯看板实现假设已经确定用 B/S 架构服务端用 Python Flask前端用原生 JS WebSocket 做实时推送。核心是看板页面和异常推送逻辑。# 服务端Flask WebSocket 推送安灯状态 from flask import Flask, render_template, jsonify from flask_socketio import SocketIO, emit app Flask(__name__) socketio SocketIO(app, cors_allowed_origins*) # 模拟当前所有工位的安灯状态 stations { A01: {state: normal, type: None, since: None}, A02: {state: normal, type: None, since: None}, A03: {state: normal, type: None, since: None}, } app.route(/) def dashboard(): 看板页面返回所有工位当前状态 return render_template(andon.html, stationsstations) app.route(/api/trigger/station_id/abnormal_type, methods[POST]) def trigger_andon(station_id, abnormal_type): 工位触发异常更新状态并推送 if station_id not in stations: return jsonify({error: 工位不存在}), 404 stations[station_id] { state: triggered, type: abnormal_type, since: datetime.now().isoformat() } # 通过 WebSocket 推送给所有看板客户端 socketio.emit(andon_update, { station: station_id, state: triggered, type: abnormal_type }) return jsonify({ok: True}) socketio.on(connect) def handle_connect(): 客户端连接时推送当前全量状态 emit(full_state, stations) if __name__ __main__: socketio.run(app, host0.0.0.0, port5000)// 前端接收 WebSocket 推送更新看板颜色 const socket io(http://localhost:5000); // 连接后接收全量状态 socket.on(full_state, (stations) { Object.entries(stations).forEach(([id, info]) { updateStationCard(id, info); }); }); // 接收增量更新 socket.on(andon_update, (data) { updateStationCard(data.station, data); }); function updateStationCard(stationId, info) { const card document.getElementById(station-${stationId}); if (!card) return; // 根据状态切换颜色正常绿色触发红色处理中黄色 const colorMap { normal: #4CAF50, triggered: #F44336, acknowledged: #FF9800, resolved: #2196F3 }; card.style.backgroundColor colorMap[info.state] || #9E9E9E; card.querySelector(.type).textContent info.type || ; }服务端用 Flask-SocketIO 做实时推送避免前端轮询。/api/trigger接口接收工位号和异常类型更新内存状态后通过 WebSocket 广播。前端收到andon_update事件后更新对应卡片的颜色和文字。参数说明cors_allowed_origins*在生产环境要改成具体域名否则有跨域安全风险。stations字典在真实项目里应该换成数据库或 Redis否则服务重启数据全丢。WebSocket 的full_state事件在客户端连接时推送全量数据保证看板刷新后状态不丢。4. QSmart Andon 类方案的配置要点与数据闭环4.1 安灯系统不是孤岛要和 MES 打通QSmart Andon 这类方案的核心价值不在于看板本身而在于它和生产执行系统MES的数据打通。安灯记录如果只停留在“几点几分哪个工位报了异常”价值有限。真正有用的是这个异常对应哪个工单、影响了多少产出、处理耗时是否计入设备综合效率OEE的停机时间。常见做法是安灯系统通过 API 或数据库视图和 MES 做数据同步。触发异常时安灯系统从 MES 拉取当前工位的工单号和产品型号异常关闭时把处理时长和异常分类回写给 MES。这样 OEE 报表里的停机原因分析才有数据支撑。配置要点安灯系统的异常分类字典必须和 MES 的停机原因字典对齐。我见过一个项目安灯系统里叫“缺料”MES 里叫“物料短缺”两个系统各记各的月底对不上账IE 工程师手动核对了两天。4.2 看板布局的三个实用原则安灯看板不是越花哨越好。车间环境光线复杂、观看距离远通常 5-10 米看板设计要遵守几个原则颜色不超过四种。绿色正常、红色异常、黄色处理中、灰色离线。颜色太多工人记不住反而增加认知负担。工位号字体要大到 10 米外能看清。一般建议工位号字号不小于 48px异常类型不小于 24px。如果是大屏看板按屏幕尺寸等比放大。异常持续时间要实时刷新。看板上显示“已持续 5 分 23 秒”比只显示“异常”两个字有用得多。这个计时器让响应人产生紧迫感也方便主管一眼看出哪些异常拖久了。4.3 用 SQL 做安灯数据的日复盘安灯系统跑起来之后每天的数据怎么用最直接的是出一张日复盘报表。假设数据表结构如下-- 安灯异常记录表核心字段 -- id: 自增主键 -- station_id: 工位号 -- abnormal_type: 异常类型 -- trigger_time: 触发时间 -- ack_time: 响应时间 -- resolve_time: 解决时间 -- close_time: 确认关闭时间 -- operator: 处理人 -- 查询当日各工位的异常次数和平均响应时长 SELECT station_id, COUNT(*) AS abnormal_count, ROUND(AVG(TIMESTAMPDIFF(SECOND, trigger_time, ack_time)), 0) AS avg_ack_seconds, ROUND(AVG(TIMESTAMPDIFF(SECOND, trigger_time, resolve_time)), 0) AS avg_resolve_seconds, SUM(CASE WHEN TIMESTAMPDIFF(MINUTE, trigger_time, ack_time) 3 THEN 1 ELSE 0 END) AS timeout_count FROM andon_records WHERE DATE(trigger_time) CURDATE() GROUP BY station_id ORDER BY abnormal_count DESC;这条 SQL 输出每个工位当天的异常次数、平均响应秒数、平均解决秒数和超时次数。timeout_count是响应超过 3 分钟的异常数这个指标比平均响应时间更能暴露问题——平均值会被快速响应的记录拉低超时次数才是真实的管理漏洞。参数说明TIMESTAMPDIFF(SECOND, ...)返回秒数差适合计算短时间间隔。如果异常处理跨越班次需要额外处理班次归属逻辑否则数据会算到错误的班组头上。5. 安灯系统上线后最容易翻车的五个地方5.1 工人不用因为触发太麻烦现象系统上线第一周触发记录每天只有个位数但车间明明经常停线。原因触发操作步骤太多。工人要走到终端前登录账号选工位选异常类型再点确认。一套下来 30 秒有这时间不如直接喊班组长。解决把触发路径缩短到两步以内。物理按钮直接触发终端上默认当前工位异常类型用大图标代替下拉菜单。登录用刷卡或工牌扫码不要输账号密码。5.2 弹窗太多班组长直接关掉现象班组长反映“一上午弹了 50 个窗口没法干活”。原因所有异常都推给班组长没有分级。有些异常工人自己就能处理不需要升级。解决在触发端加一个“自行处理”选项。工人选了之后系统只记录不推送超过 5 分钟未自行解决再升级。这样能过滤掉 60% 以上的无效推送。5.3 IE 浏览器下看板不刷新现象Chrome 里看板正常IE 里数据不更新要手动按 F5。原因WebSocket 在 IE 下兼容性差或者代码用了 IE 不支持的 ES6 语法。解决如果必须支持 IE把 WebSocket 降级为长轮询setInterval fetch并把 JS 代码转译成 ES5。但更好的做法是推动终端浏览器升级把 IE 从支持列表里去掉。5.4 异常分类太细数据没法分析现象系统里有 80 多种异常类型月底导出报表每种类型只有两三条记录看不出趋势。原因上线时让各部门自己报异常类型没有做归并。解决异常类型控制在 10-15 种以内大类下面再分小类。比如“设备故障”下面分“机械故障”“电气故障”“程序故障”但报表层面只看大类。小类用于维修部门分析不用于管理报表。5.5 数据只进不出没人看现象系统跑了半年数据存了几万条但除了 IT 部门没人打开过报表。原因没有把安灯数据和现场管理动作挂钩。班组长不看因为看了也没用主管不看因为不影响考核。解决把安灯响应时长纳入班组绩效考核每天早会过一遍前一天的安灯数据。数据只有和人的利益相关才会被真正使用。6. 用安灯数据做产线瓶颈分析的一个具体技巧安灯系统跑顺之后数据本身能告诉你产线的瓶颈在哪。分享一个我常用的分析方法按工位统计异常触发频次结合节拍时间找出“异常高发且影响大”的工位。具体操作导出最近两周的安灯记录按工位号分组统计每个工位的异常次数和总停机时长。然后和该工位的节拍时间做对比。如果一个工位的异常次数排前 3且平均处理时长超过 2 个节拍这个工位就是瓶颈候选。更进一步把异常类型和工位做交叉分析。比如 A03 工位的“缺料”异常特别多那问题可能不在工位本身而在物料配送路径。这种分析用一张透视表就能做工位异常总数缺料设备故障质量异常平均处理时长A01123544分12秒A0282243分05秒A032515376分48秒A0461322分30秒A03 的缺料异常 15 次远超其他工位。这时候不用看设备直接去查 A03 的物料配送频率和线边库存。大概率是配送间隔太长或者库存设置不合理。这个分析我一般每两周做一次做完之后把结果发给生产主管让他们决定要不要调整。安灯系统的价值不在于灯亮不亮在于灯亮之后的数据能不能让产线变得更好。我自己踩过的坑是一开始只关注系统功能忽略了数据运营结果系统上线半年产线该停还是停。后来把数据分析做成固定动作每周花半小时跑一遍才真正看到改善。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
