简介：这份PDF资料围绕安灯系统（Andon）在生产现场的应用与解决方案展开，面向制造企业的生产管理、设备维护及品质管理人员，也适合精益生产学习者参考。内容系统梳理了安灯系统在汽车、电子、机械等行业的应用场景，归纳其及时响应异常、提升效率、降低成本、改善品质与提高管理效率五大作用，并详解现场信息采集装置、现场看板与B/S后台管理系统三部分物理结构，以及从异常监控、信息发送、处理、状态跟踪到数据分析的五步处理流程。资源包为1个PDF文件，约1.54MB，结构紧凑，便于按章节查阅。目前已有154人学习，适合希望快速建立安灯系统整体认知、对照现场落地异常响应机制的读者参考。

1. 安灯系统落地前，先把这三个问题想清楚

车间里最怕的不是设备坏，是坏了没人知道、知道了没人来、来了不知道找谁。安灯系统（Andon）解决的就是这条链路——把异常从“口头喊话”变成“有记录、有响应、有闭环”的流程。但很多团队一上来就问“买哪家”，结果系统上线三个月，工人嫌麻烦不用，班组长嫌弹窗太多关掉，最后变成一块挂在墙上的电子看板。问题不在产品，在于没想清楚三件事：异常怎么触发、响应怎么升级、数据怎么复盘。这篇内容围绕安灯系统的应用场景和解决方案展开，从触发方式、B/S 架构选型、QSmart Andon 这类典型方案的配置逻辑，到上线后最容易翻车的地方，给出一条能照着走的路径。适合正在选型或已经上线但用不起来的制造现场工程师、IT 对接人和生产主管。

2. 安灯系统的触发方式与响应机制：从拉绳到自动采集

2.1 三种触发方式的实际差异

安灯系统的核心不是看板，是触发。触发方式决定了这套系统能不能真正跑起来。常见做法有三类：

物理拉绳/按钮触发是最传统的方式。工位上方拉一根绳或装一个按钮盒，工人发现异常一拉，对应工位的安灯亮起，同时触发呼叫。优点是操作零学习成本，缺点是只能表达“有异常”，说不清是什么异常。适合工位固定、异常类型少的场景，比如总装线的某个装配工位。

终端界面触发是在工位旁的触摸屏或平板上一键选择异常类型。工人点“缺料”“设备故障”“质量异常”，系统自动带上工位号、时间戳、异常类型。比拉绳多了一步操作，但信息完整度高很多。我一般建议新上线的项目优先用这种方式，因为后续的数据分析全靠这个分类字段。

设备自动触发是通过 PLC 或传感器采集设备状态，达到阈值自动报异常。比如注塑机温度超限、CNC 刀具寿命到期。这种方式最“无感”，但对设备接口和协议对接要求高，通常只在关键设备上做。

三种方式不是互斥的，实际项目里经常混用：关键设备自动触发，普通工位终端触发，应急场景保留物理按钮。

2.2 响应升级规则怎么设才不形同虚设

触发之后，如果没人响应，安灯就只是个灯。响应升级机制是安灯系统的灵魂。常见做法是按时间分层：

这个时间梯度不是拍脑袋定的。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-equiv="X-UA-Compatible" content="IE=edge"> <!-- 指定使用 IE11 的渲染模式 --> <meta http-equiv="X-UA-Compatible" content="IE=11">

但双核浏览器的兼容模式不稳定，不同版本行为不一致，生产环境慎用。

路径三：服务端渲染降级。如果安灯系统的看板页面是自己开发的，可以在服务端判断 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", stations=stations) @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, host="0.0.0.0", port=5000)

// 前端：接收 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 工位的“缺料”异常特别多，那问题可能不在工位本身，而在物料配送路径。这种分析用一张透视表就能做：

A03 的缺料异常 15 次，远超其他工位。这时候不用看设备，直接去查 A03 的物料配送频率和线边库存。大概率是配送间隔太长或者库存设置不合理。

这个分析我一般每两周做一次，做完之后把结果发给生产主管，让他们决定要不要调整。安灯系统的价值不在于灯亮不亮，在于灯亮之后的数据能不能让产线变得更好。我自己踩过的坑是：一开始只关注系统功能，忽略了数据运营，结果系统上线半年，产线该停还是停。后来把数据分析做成固定动作，每周花半小时跑一遍，才真正看到改善。希望帮到你。

本文还有配套的精品资源，点击获取