安灯系统落地全指南：从架构选型到数据调优

简介：这份PDF资料围绕安灯系统（Andon）在生产现场管理中的应用与解决方案展开，面向制造业生产管理、品质管理及信息化建设相关人员，帮助理解如何通过事件驱动机制实时监控设备故障、品质异常与物料短缺等问题。资源共1个PDF文件，压缩包约1.54MB，内容以图文说明为主，便于快速查阅与内部培训使用。资料系统梳理了安灯系统的应用行业、五大作用、物理结构（现场信息采集装置、现场看板、后台管理系统）以及异常处理流程，并配有结构示意与流程说明，可帮助读者掌握从异常触发、信息发送、逐层报警到状态跟踪与数据分析的完整闭环。目前已有154人学习，适合作为制造企业推进现场透明化管理与异常快速响应的参考材料。

1. 安灯系统的应用及解决方案归纳：从一份 PDF 说起，把车间异常响应讲透

很多工厂的异常响应还停留在“操作工喊班长、班长找维修、维修等配件”的口口相传阶段，一份名为《安灯系统的应用及解决方案归纳.pdf》的资料之所以被反复传阅，恰恰说明大家卡在同一个问题上：知道安灯（Andon）有用，但不知道从哪落地、用什么架构、参数怎么定。安灯系统本质是一套“异常呼叫—响应—升级—闭环”的现场管理机制，用硬件按钮或软件终端把工位异常实时抛给责任岗位，再用计时和看板逼着响应速度提上来。它适合离散制造、汽车零部件、电子组装这类节拍紧、异常多的车间，也适合想把 QSmart Andon 这类成熟方案或自研 B/S 系统跑起来的信息化团队。下面按“是什么—怎么搭—坑在哪—怎么进阶”的顺序，把这份资料背后的落地路径拆开讲。

2. 安灯系统的核心机制与选型：为什么不是装几个按钮就完事

安灯这个词来自丰田，最初就是一根拉绳，拉一下线停、班长过来。但今天再照搬拉绳，基本等于白做，因为异常响应真正的难点不在“呼叫”，而在“谁在多长时间内响应、超时之后找谁、数据怎么沉淀”。这一章先把机制和选型讲清楚，后面动手才不会返工。

2.1 安灯的四层结构：呼叫、响应、升级、闭环

一套能用的安灯，拆开看是四层。第一层是呼叫触发，工位通过物理按钮盒、触摸屏或扫码发起异常，异常类型通常分质量、设备、物料、工艺几类，每类对应不同责任岗位。第二层是响应确认，被呼叫方在终端上点“已接收”，系统开始计时。第三层是超时升级，如果响应超过设定阈值，自动升级到上一级主管，甚至推送到手机。第四层是闭环归档，异常处理完要填原因和处理结果，数据进报表。

这四层里，最容易被砍掉的是第三层和第四层。很多车间只做了呼叫和响应，结果异常叫了没人管，或者管了没记录，月底复盘拿不出数据。我的经验是：升级规则和闭环记录必须在第一期就做进去，哪怕先用最土的短信或企业微信推送，也比没有强。因为安灯的价值不在“叫得响”，而在“叫了必须有人接、接了必须有结果”。

从选型角度看，物理按钮盒适合油污、粉尘、戴手套的工位，可靠性高但灵活性差；触摸屏或平板适合异常类型多、需要填信息的场景，但要注意防护等级。常见做法是混合部署：关键工位用物理按钮保证一定能触发，班组长和维修用平板或 PC 端处理。

2.2 自研 B/S 架构还是买 QSmart Andon：三条判断线

标题里提到的 QSmart Andon 属于成品方案，而 B/S 系统是自研常见路线。到底选哪条，我一般看三条线。

第一条是异常类型复杂度。如果只有“设备坏了”一种呼叫，买个按钮加声光报警器几百块就够，没必要上系统。但如果有质量、物料、设备、工艺多类异常，每类要走不同流程，成品方案或自研 B/S 才有意义。

第二条是是否需要和现有系统打通。安灯如果只孤立运行，数据就是死数据。真正有价值的是异常记录能关联到 MES 的工单、ERP 的物料、设备系统的停机记录。QSmart Andon 这类成品通常提供标准接口，自研 B/S 则要自己写对接层。如果厂里已经有 MES，选型时一定要问清楚对接方式和字段映射。

第三条是浏览器兼容性。这是热搜词里反复出现 IE 浏览器的原因——很多老厂的内网终端还是 Windows 7 加 IE，成品安灯系统如果只支持现代浏览器，现场根本打不开。自研 B/S 反而可以针对性兼容。这一点在选型阶段不确认，上线当天就会翻车。

2.3 浏览器兼容这条线，决定了现场能不能用起来

热搜里“ie浏览器”“ie浏览器下载”反复出现，不是偶然。大量工厂的看板机、工位终端、班组长电脑还停留在 IE 时代，操作系统可能是 Windows 7 甚至 XP。安灯系统如果前端用了较新的框架，在这些终端上直接白屏。

常见做法是：前端尽量用兼容性好的写法，避免依赖新特性；如果必须用现代框架，就在终端侧统一升级到内置 Chromium 的浏览器，而不是死磕 IE。这里要提醒一句，网上搜“ie浏览器下载”出来的结果鱼龙混杂，现场装机一定走内部软件源或可信渠道，别在工位机上随便装来路不明的安装包，这是血泪经验。

提示：选型阶段就拿现场最老的那台终端做兼容性测试，别在开发机上测通了就以为万事大吉。

3. 从零搭一套安灯系统：数据库、后端接口与看板的最小实现

这一章给一套可复现的最小实现，技术栈选 Python + Flask + SQLite 做后端，前端用原生 HTML 加定时轮询，目的是兼容老终端。生产环境可以把 SQLite 换成 MySQL 或 PostgreSQL，轮询换成 WebSocket，但核心逻辑不变。

3.1 数据模型：异常工单表怎么设计

安灯的核心数据就是一张异常工单表。字段要覆盖触发、响应、升级、闭环四个阶段的时间戳，这样后面算响应时长、升级次数才有依据。

-- 异常工单表：一条记录就是一次安灯呼叫的完整生命周期 CREATE TABLE andon_ticket ( id INTEGER PRIMARY KEY AUTOINCREMENT, station TEXT NOT NULL, -- 工位编号，如 A-03 category TEXT NOT NULL, -- 异常类型：quality/equipment/material/process level INTEGER DEFAULT 1, -- 当前升级层级，1 为初始 status TEXT DEFAULT 'open', -- open/acked/closed created_at DATETIME NOT NULL, -- 呼叫触发时间 acked_at DATETIME, -- 响应确认时间 escalated_at DATETIME, -- 最近一次升级时间 closed_at DATETIME, -- 闭环时间 owner TEXT, -- 当前责任人 reason TEXT, -- 处理原因 solution TEXT -- 处理结果 );

字段说明：category决定这条工单推给谁，level记录升级到第几层，status控制看板上的颜色。created_at和acked_at的差值就是响应时长，这是安灯最核心的考核指标。escalated_at用来判断是否触发过升级。注意owner存的是当前责任人，升级时要更新，否则看板上会一直显示初始责任人。

3.2 后端接口：触发、响应、升级三个动作

后端只需要三个核心接口：触发呼叫、响应确认、超时升级。升级逻辑用一个后台定时任务扫描超时工单。

from flask import Flask, request, jsonify from datetime import datetime, timedelta import sqlite3 app = Flask(__name__) DB = "andon.db" # 各异常类型的响应阈值（秒），超时即升级 RESPONSE_TIMEOUT = {"quality": 120, "equipment": 180, "material": 300, "process": 240} def get_db(): conn = sqlite3.connect(DB) conn.row_factory = sqlite3.Row return conn @app.route("/api/call", methods=["POST"]) def call(): """工位触发安灯呼叫""" data = request.json conn = get_db() conn.execute( "INSERT INTO andon_ticket (station, category, created_at) VALUES (?,?,?)", (data["station"], data["category"], datetime.now()) ) conn.commit() return jsonify({"ok": True}) @app.route("/api/ack/<int:ticket_id>", methods=["POST"]) def ack(ticket_id): """责任人响应确认，记录响应时间""" conn = get_db() conn.execute( "UPDATE andon_ticket SET status='acked', acked_at=?, owner=? WHERE id=?", (datetime.now(), request.json["owner"], ticket_id) ) conn.commit() return jsonify({"ok": True}) def escalate_job(): """后台任务：扫描超时未响应的工单并升级""" conn = get_db() rows = conn.execute("SELECT * FROM andon_ticket WHERE status='open'").fetchall() for r in rows: timeout = RESPONSE_TIMEOUT.get(r["category"], 300) if datetime.now() - datetime.fromisoformat(r["created_at"]) > timedelta(seconds=timeout): conn.execute( "UPDATE andon_ticket SET level=level+1, escalated_at=? WHERE id=?", (datetime.now(), r["id"]) ) conn.commit()

逻辑说明：call接口只写触发时间，ack接口写响应时间和责任人，escalate_job由定时器每分钟跑一次，扫描status='open'且超过阈值的工单，把level加一。参数上，RESPONSE_TIMEOUT按异常类型区分，质量类通常最紧，物料类可以放宽。这个阈值不是拍脑袋定的，要拿现场历史数据算，后面第 5 章会讲怎么调。

3.3 看板前端：兼容老终端的轮询写法

看板要能在老终端上跑，前端就别用复杂框架，原生 JS 加定时轮询最稳。

// 每 5 秒拉一次未闭环工单，刷新看板颜色 function refreshBoard() { fetch('/api/tickets?status=open,acked') .then(res => res.json()) .then(list => { const board = document.getElementById('board'); board.innerHTML = ''; list.forEach(t => { const div = document.createElement('div'); // 未响应红色，已响应黄色，超过阈值闪烁 div.className = t.status === 'open' ? 'card red' : 'card yellow'; div.innerText = t.station + ' | ' + t.category + ' | L' + t.level; board.appendChild(div); }); }); } setInterval(refreshBoard, 5000); refreshBoard();

逻辑说明：轮询间隔 5 秒是兼容性和实时性的折中，太短增加服务器压力，太长现场感觉迟钝。颜色规则里，open红色表示没人接，acked黄色表示处理中。如果要加闪烁提醒，用 CSS 动画而不是 JS 定时器，减少老终端负担。参数上，轮询接口要支持按status过滤，避免把已闭环的历史工单也拉回来。

注意：老终端上fetch可能不被支持，必要时降级用XMLHttpRequest，这是兼容 IE 的关键一步。

4. 安灯系统落地避坑：五条现场踩出来的经验

这一章专门讲坑。安灯系统翻车往往不是技术问题，而是流程和现场适配问题。下面五条都是我在不同车间见过的真实情况。

4.1 坑一：按钮装了，但没人敢按

现象：安灯按钮装上去一个月，触发记录寥寥无几，问操作工说“怕按了被骂”。

原因：管理层把安灯触发次数当成负面指标考核班组，按得越多扣得越多，操作工自然不敢按。

解决：安灯触发次数要当成改善输入而不是追责依据。正确做法是鼓励触发、奖励及时触发，把考核放在“响应时长”和“闭环率”上，而不是“触发次数”。这一点不扭转，系统就是摆设。

4.2 坑二：升级规则设了，但升级对象收不到

现象：工单超时升级了，但主管根本没收到通知，异常还是没人管。

原因：升级只改了数据库里的level字段，没有真正推送消息。看板在车间，主管在办公室，看不到。

解决：升级动作必须绑定实际通知渠道，短信、企业微信、钉钉、邮件都行，关键是主管日常会看的那个。推送内容要带工位、异常类型、已等待时长，让主管一眼判断紧急程度。

4.3 坑三：响应阈值一刀切，质量异常和物料异常一个标准

现象：所有异常都设 5 分钟响应，结果质量异常频繁升级，物料异常又太宽松。

原因：没有按异常类型区分阈值，用了一个全局值。

解决：按类型设阈值，质量类可以 2 分钟，设备类 3 分钟，物料类 5 分钟，工艺类 4 分钟。阈值要基于历史响应数据动态调整，而不是一次定死。第 5 章会给一个调整方法。

4.4 坑四：老终端打不开看板，现场直接弃用

现象：系统在开发机上好好的，装到车间看板机上白屏或样式错乱。

原因：前端用了老浏览器不支持的特性，或者依赖了外部 CDN 资源而车间内网访问不了。

解决：前端资源全部本地化，不用外部 CDN；避免使用箭头函数、fetch、Promise等老 IE 不支持的特性，必要时引入 polyfill 或直接写 ES5。上线前拿现场最老的终端实测。

4.5 坑五：数据只进不出，月底复盘拿不出报表

现象：系统跑了一年，数据一堆，但没人看，也没人分析。

原因：只做了实时看板，没做统计报表，异常数据没有转化成改善输入。

解决：至少做三张报表——按工位统计异常频次、按类型统计平均响应时长、按班次统计闭环率。报表不用花哨，能导出 Excel 给生产例会看就行。数据只有被用起来，安灯才有持续投入的理由。

5. 让安灯真正产生价值：阈值调优与数据复盘的具体技巧

系统跑起来只是开始，真正决定安灯值不值得继续投入的，是它能不能持续压缩异常响应时间。这里讲两个具体技巧，一个是怎么调响应阈值，一个是怎么用数据复盘。

先说阈值调优。很多厂把阈值定死就不管了，结果要么频繁误升级，要么形同虚设。我的做法是每月拉一次历史数据，算每个异常类型的响应时长分布，取第 75 百分位作为新阈值。比如质量异常过去一个月 75% 的工单在 90 秒内被响应，那阈值就设 90 秒，而不是拍脑袋的 120 秒。这样阈值会随着现场能力提升逐步收紧，形成正向循环。

-- 计算各异常类型响应时长的第 75 百分位（SQLite 语法） SELECT category, AVG((julianday(acked_at) - julianday(created_at)) * 86400) AS avg_sec, COUNT(*) AS total FROM andon_ticket WHERE acked_at IS NOT NULL AND created_at >= datetime('now', '-30 days') GROUP BY category;

这条 SQL 给出各类型的平均响应秒数，实际调优时可以把结果导出到 Excel 用百分位函数算 P75。参数上，统计窗口取 30 天，太短波动大，太长反应迟钝。注意只统计已响应的工单，未响应的单独看，那才是真正的问题。

再说数据复盘。安灯数据最有价值的不是平均值，而是长尾工单。平均响应 2 分钟听起来不错，但如果有 5% 的工单响应超过 30 分钟，这 5% 才是真正影响产线的。复盘时重点看三类：响应时长最长的前 10 条、升级次数最多的工位、反复触发同一异常的工位。前 10 条看流程卡在哪，升级多的工位看责任人是否匹配，反复触发的工位看是不是设备或工艺有根因问题。

最后说一个我自己的习惯：每次调整阈值或流程，都在系统里留一条变更记录，写清楚改了什么、为什么改。安灯系统跑久了，最大的风险不是技术故障，而是没人记得当初为什么这么设。留了变更记录，半年后回头看，才知道哪些参数是有效的、哪些是当时妥协的产物。这套东西不难，难的是坚持用数据说话，而不是靠感觉拍板。希望帮到你。

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