🚨 精益生产入门第一步

生产看板/安灯系统(Andon)

工位异常呼叫 + 车间实时大屏 + 三级报警升级 + 响应时间统计 + 钉钉/企业微信推送。ESP32自制按钮盒(<200元/工位)+ 全链路开源方案,帮你实现车间信息透明化,异常响应速度提升3倍,停机时间减少20-40%

🔘 安灯按钮盒 异常呼叫硬件
🔀 Node-RED 异常逻辑与报警升级
📡 MQTT/EMQX 实时消息传输
📊 Grafana 生产大屏看板
🗄️ PostgreSQL 事件记录与统计
🔘 呼叫:4键按钮盒(质量/设备/物料/安全) 📊 展示:65寸车间实时大屏 🔔 报警:三级升级(5/15/30分钟)+ 钉钉推送 📈 统计:响应时间/异常柏拉图/改善对比

01 为什么中小企业最需要安灯系统

没有安灯系统的车间,普遍存在这4个问题

📢
异常靠喊
设备坏了工人扯着嗓子喊维修,缺料了跑去找仓库,车间噪音大听不见,响应全靠运气
⏱️
响应慢
从异常发生到有人来处理,平均15分钟以上,设备干等着,产量白白损失
📋
无记录
异常发生了多少次、每次多久、哪类最多,全凭印象,改善没有数据支撑
🙈
不透明
老板/车间主任在办公室不知道现场情况,要了解得去车间转一圈,管理滞后

安灯系统是什么?为什么它是精益生产入门第一步

安灯(Andon)起源于丰田生产方式,是一种"异常快速呼叫和响应系统"——工人发现异常(设备故障/质量问题/缺料/安全隐患)时,按下工位上的按钮,车间大屏立刻显示异常位置和类型,同时通知相关责任人快速响应。

安灯系统的核心价值不是"记录异常",而是"缩短异常响应时间"——异常暴露得越快、响应得越快,停机损失就越小。一个10台设备的车间,每台设备每天少停机10分钟,一天就多生产100分钟产量,一年多生产25000分钟(约416小时),相当于多了2个工人的产量。

为什么说安灯是精益生产入门第一步?因为它最简单(就是按钮+大屏+报警)、最直观(效果立竿见影)、最容易推广(工人一学就会),而且它是其他精益工具(TPM/TQM/5S)的基础——没有异常数据,其他改善都无从谈起。

02 系统架构

五层架构:呼叫→传输→逻辑→存储→展示,全链路开源方案

01
🔘
呼叫层
安灯按钮盒/PLC
工位异常呼叫硬件:4键按钮盒(质量/设备/物料/安全),或PLC信号(设备故障自动触发)。按钮盒用ESP32/树莓派+工业按钮自制,成本<200元/工位。支持声光报警(按钮盒自带LED+蜂鸣器)
→
02
📡
传输层
MQTT/EMQX
异常事件通过MQTT协议实时上传,EMQX消息中间件支撑1000+并发连接,延迟<100ms。按钮盒断网时本地缓存事件,恢复后补传。支持QoS1消息保证(至少送达一次),异常事件不丢失
→
03
🔀
逻辑层
Node-RED
异常事件处理逻辑:事件分类(质量/设备/物料/安全/其他)、报警升级(5分钟未响应→通知班组长,15分钟→通知车间主任,30分钟→通知厂长)、响应/解除处理、响应时间计时。所有逻辑可视化拖拽配置,现场可调整
→
04
🗄️
存储层
PostgreSQL
异常事件记录表(事件ID/工位/类型/触发时间/响应时间/解除时间/响应人/处理结果/升级次数)、班次配置表、工位配置表、人员配置表(姓名/角色/钉钉ID/企业微信ID)。支持按类型/工位/班次/时间段多维度统计分析
→
05
📊
展示层
Grafana大屏
车间实时大屏(当前异常列表+各工位状态+今日产量+OEE+响应中事件倒计时),挂65寸大屏车间入口。异常报警通过钉钉/企业微信推送(@相关责任人)。历史分析看板(异常柏拉图/响应时间趋势/工位异常排行/月度改善对比)
💡 架构设计要点:
  • 按钮盒离线可用:ESP32按钮盒本地缓存事件,WiFi断了按了不丢,恢复后补传。按下后立刻声光反馈(不依赖网络),工人知道"按到了"
  • 报警三级升级:5分钟未响应→班组长,15分钟→车间主任,30分钟→厂长。升级不是为了追责,而是为了"确保有人管"
  • 精准@人:根据异常类型和工位,@具体责任人,不是发大群被淹没。钉钉互动卡片带"我来响应"按钮,点一下就能响应
  • 文化先于技术:安灯是管理工具不是监控工具,上线前必须先做文化对齐——按按钮是英雄不是罪人,否则工人不敢按,系统成摆设

03 核心软件/硬件选型理由

Node-RED 异常逻辑与报警升级

为什么选它:安灯系统最核心的是"异常处理流程"——谁触发、通知谁、多久没响应要升级、升级通知谁、怎么解除。不同工厂流程不同,用硬编码写死流程,改一次要重新部署。Node-RED可视化拖拽配置流程,现场工程师可以自己调整升级时间、通知人员、处理规则。支持钉钉/企业微信API节点,报警推送不用写代码。支持状态机节点,异常生命周期(触发→响应中→已解除)管理清晰。比写硬编码C#/Python开发效率高10倍,维护成本低90%。

对比过:对比过硬编码后端(改流程要改代码编译部署,现场无法快速调整)、商业工作流引擎(太重,学习成本高,小团队用不起来)、规则引擎(不适合状态机和时间触发的升级逻辑)

MQTT/EMQX 实时消息传输

为什么选它:安灯系统要求"实时性"——按钮按下后大屏要在1秒内显示,报警要立刻推送。HTTP请求延迟高(几百ms到几秒)且不支持双向通信,MQTT是专为物联网设计的轻量级实时协议,延迟<100ms,支持发布/订阅模式(按钮发布事件,大屏和报警引擎订阅)。EMQX是开源MQTT broker,单机支撑100万连接,2核4G服务器跑100个工位毫无压力。支持QoS消息保证(异常事件不丢失)、遗嘱消息(按钮盒掉线自动通知)。比用HTTP轮询实时性高10倍,服务器负载低80%。

对比过:对比过HTTP轮询(延迟高,服务器负载大,实时性差)、WebSocket(需要自己实现消息路由和QoS,EMQX已经封装好了)、TCP Socket(需要自己写协议解析和连接管理,MQTT是标准协议)

Grafana 生产大屏看板

为什么选它:安灯大屏需要实时刷新(<5秒)、醒目显示(异常红色闪烁、倒计时)、多数据源(PostgreSQL事件+MQTT实时状态+TDengine产量)。Grafana支持实时刷新(最低5秒),支持告警状态面板(异常红色高亮),支持PostgreSQL和MQTT数据源,支持仪表盘自动轮播(多车间多产线自动切换)。社区有大量工业大屏模板可以参考。比自己写Web前端开发周期短10倍,且Grafana的图表和告警功能比自研成熟得多。

对比过:对比过自研Web前端(开发周期长,实时刷新要自己写WebSocket,图表库要自己调)、商业看板软件(授权贵,和PostgreSQL/MQTT集成不如Grafana原生)、电视投屏PPT(不是实时数据,需要人工更新)

ESP32自制按钮盒 异常呼叫硬件

为什么选它:商业安灯按钮盒(如Andon系统专用按钮柱)动辄几千元一个工位,10个工位就要几万。用ESP32开发板(20元)+工业按钮(10元/个×4)+LED指示灯+蜂鸣器+3D打印外壳,总成本<100元/工位。ESP32支持WiFi和MQTT,Arduino开发简单,固件可以OTA升级。按钮按下后通过MQTT发布事件,同时本地LED闪烁+蜂鸣器响(声光报警),收到大屏"已响应"确认后LED变绿。比商业按钮盒成本低90%,且可以根据需求自定义按键数量和功能。

对比过:对比过商业安灯按钮柱(几千元一个,贵,功能固定不能定制)、普通电脑键盘触发(不适合车间油污环境,且需要工位有电脑)、PLC按钮(需要PLC点位,布线成本高,且异常类型不够灵活)

04 部署要点(关键配置)

01

安灯流程设计与文化对齐

先设计安灯使用流程:异常类型(质量/设备/物料/安全/其他)、响应人矩阵(哪类异常通知谁)、升级规则(5/15/30分钟三级升级)、响应/解除流程、响应时间考核标准。写进《安灯系统使用规范》。然后做"文化对齐":开全员大会说明安灯目的(暴露问题不是追责),管理层带头使用,前2周每天站会复盘。这一步比技术更重要,文化不对系统必失败

02

按钮盒硬件制作与部署

ESP32-WROOM-32E开发板 + 4个工业按钮(红/黄/蓝/绿,对应设备/质量/物料/安全)+ 4个LED指示灯 + 蜂鸣器 + 3D打印/亚克力外壳。固件用Arduino开发:WiFi连接+MQTT发布+本地缓存+声光反馈+OTA升级。每个工位一个按钮盒,固定在工位操作台(工人伸手可及的位置)。测试:按下按钮后LED闪烁+蜂鸣器响,1秒内大屏显示,收到确认后LED变绿。成本<100元/工位

03

EMQX + Node-RED部署

服务器部署EMQX(MQTT broker,Docker一键部署,1883端口),配置认证(用户名密码,每个按钮盒一个账号)和ACL(按钮盒只能发布自己工位的主题)。部署Node-RED,配置MQTT订阅节点(订阅所有工位的异常主题),实现异常处理流程:事件分类→记录数据库→触发报警→启动升级定时器→响应/解除处理→升级通知。用Node-RED的dashboard做一个简单的"异常管理后台"(查看当前异常/手动响应/解除/导出报表)

04

PostgreSQL数据库设计

核心5张表:①andon_events(异常事件表:事件ID/工位ID/类型/子类型/触发时间/响应时间/解除时间/触发人/响应人/处理结果/根本原因/升级次数/状态);②workstations(工位表:工位ID/名称/产线/责任人/按钮盒MQTT主题);③staff(人员表:姓名/工号/角色/钉钉ID/企业微信ID/电话);④shift_config(班次表);⑤escalation_rules(升级规则表:类型/响应时限/升级通知人)。andon_events建索引:工位ID+触发时间、类型+状态、响应人+状态。数据保留3年,历史数据按月分区

05

Grafana大屏与报警配置

3个核心看板:①实时大屏(当前异常列表+倒计时+各工位状态地图+今日产量+OEE+响应中事件数),挂车间65寸大屏,5秒刷新;②异常分析看板(异常柏拉图按类型/子类型/工位、响应时间趋势图、平均响应时间排行、月度异常对比),管理层用;③班次报表(自动生成Excel,含异常明细/响应时间统计/类型分布/改善建议,每天下班发邮件)。配置Grafana Alerting:异常超过5分钟未响应→钉钉webhook通知@班组长,超过15分钟→@车间主任。注意:Grafana告警是轮询触发,不如Node-RED实时,紧急异常用Node-RED直接发钉钉

06

钉钉/企业微信报警集成

注册钉钉企业内部应用(或企业微信应用),获取AppKey/AppSecret,配置机器人webhook。Node-RED中实现报警推送:异常触发→发钉钉消息到对应群@责任人(消息内容:工位+异常类型+触发时间+倒计时);升级→发更高级别群@上级;响应→发消息"XX已响应,预计XX分钟解决";解除→发消息"XX已解除,处理结果:XX"。消息卡片带"我来响应"和"已解除"按钮(钉钉互动卡片),责任人点按钮就能响应/解除,不用进系统。测试:模拟异常,10秒内收到钉钉消息,点"我来响应"后大屏状态更新为"响应中"

05 踩过的坑(真实问题与解决方案)

安灯系统最容易失败的不是技术,而是"工人不敢按"和"报警没人理",这里是真实踩过的6个坑

坑 01 安灯系统上线后,工人不敢按按钮——怕按了被追责,异常还是靠喊
原因: 安灯系统的初衷是"快速暴露问题",但如果企业文化是"谁按按钮谁负责",工人就不敢按——设备坏了不敢按(怕被说操作不当),缺料了不敢按(怕被说没提前报)。系统成了摆设,异常还是靠人跑来跑去喊
解决: 安灯系统上线前必须先做"文化对齐",这是比技术更重要的一步:①明确安灯的目的是"暴露问题、快速解决",不是"追责"——按按钮的人是英雄,不是罪人;②制定"安灯使用规范":什么情况该按(任何影响生产的异常都该按)、按了以后谁来响应、响应时间要求、不按的后果(异常扩大了追责不按的人);③管理层带头:前2周厂长/车间主任每天在安灯大屏前开5分钟站会,表扬按按钮及时的工位,批评异常不按的;④和绩效挂钩:响应及时的班组有奖励,异常隐瞒的有处罚。关键:安灯系统是"管理工具",不是"监控工具"——文化不对,技术再好也没用
坑 02 报警通知发了,但没人看——钉钉/企业微信消息被淹没,异常没人响应
原因: 报警只发了一条消息,没有@具体责任人,且消息发在大群里被其他消息淹没。且没有升级机制——发了就算了,没人响应也不催。大家对报警麻木了(狼来了效应),真正重要的异常也被忽略
解决: 报警通知"精准+升级+多通道":①精准@人:根据异常类型和工位,@具体责任人(设备异常@维修班组群@维修组长,质量异常@质检员@班组长,物料异常@仓库管理员),不是发大群;②升级机制:5分钟未响应→升级通知班组长,15分钟→车间主任,30分钟→厂长,每次升级都@具体人;③多通道:钉钉/企业微信消息+电话呼叫(紧急异常自动拨打电话)+大屏红色闪烁+声光报警器(车间现场);④报警降噪:不是所有异常都发报警,只有"未响应"和"升级"才发通知,已响应的只在大屏显示,避免报警泛滥。关键:报警的目的是"让人行动",不是"让人知道"——发了没人响应等于没发
坑 03 ESP32按钮盒经常掉线,WiFi不稳定,异常按了没反应
原因: 车间环境复杂(金属设备多、WiFi信号干扰大、路由器覆盖不够),ESP32用WiFi连接不稳定,经常掉线。且按钮盒没有断线缓存,掉线期间按的事件直接丢了。工人按了没反应,就不再按了
解决: 按钮盒"可靠性设计"5点:①WiFi优化:用工业级WiFi模块(如ESP32-WROOM-32E,抗干扰强),车间部署足够的AP(每500平米一个,不要用一个路由器覆盖整个车间),按钮盒优先连接5G WiFi(干扰少);②断线缓存:按钮盒本地用SPIFFS存储未发送事件(可存1000条),WiFi恢复后自动补传,补传成功才删除;③本地声光反馈:按钮按下后立刻LED闪烁+蜂鸣器响(不依赖网络),工人知道"按到了",收到服务器确认后LED变绿;④心跳监测:按钮盒每30秒发心跳,大屏显示每个按钮盒在线状态,掉线的工位显示灰色并通知管理员;⑤硬件看门狗:ESP32启用硬件看门狗,程序跑飞自动重启。关键:车间环境不是办公室,WiFi稳定性必须重视,按钮盒必须"离线可用"
坑 04 异常分类太粗,全是"其他",分析不出哪类问题最多
原因: 按钮盒只有4个键(质量/设备/物料/安全),但实际异常类型很多——设备异常又分机械故障/电气故障/程序故障/气压不足,质量异常又分尺寸超差/外观不良/装配错误。只按大类统计,无法定位具体问题,改善没有针对性
解决: 异常分类"两级制":①第一级(按钮盒4键):质量/设备/物料/安全,工人快速选择;②第二级(响应人选择):响应人到达现场后,在工位终端/手机上选择具体子类型(设备→机械故障/电气故障/程序故障/气压不足/其他),并填写简短描述。系统统计时按子类型分析,柏拉图才能显示具体问题分布。同时支持"自定义异常类型":每个工厂可以根据自己的情况配置子类型列表,不用改代码。关键:异常分类是为了"改善",不是为了"记录"——分类太粗,改善就没有方向。建议前1个月用"其他"兜底,1个月后根据"其他"的具体内容,新增常用子类型
坑 05 响应时间统计不准——有人按了按钮立刻自己解除,响应时间显示0秒
原因: 响应时间=解除时间-触发时间,但如果触发人和解除人是同一个人(工人自己按了自己解除),或者解除时没有选择"响应人",系统就不知道是谁响应的、响应了多久。数据失真,无法考核响应速度
解决: 响应时间"严格定义+人工确认":①触发和解除必须是不同的人(触发人不能自己解除,必须由响应人解除);②解除时必须选择"响应人"(扫码/工号/选择列表),系统记录响应人身份;③响应时间=响应人点击"我来处理"的时间-触发时间(不是解除时间-触发时间),因为"到达现场开始处理"才是真正的响应,"处理完解除"是恢复时间。分开统计两个指标:响应时间(触发→开始处理)、处理时间(开始处理→解除);④异常解除时必须填写"处理结果"(已解决/临时处理/转其他部门)和"根本原因"(可选,但鼓励填写)。关键:响应时间是安灯系统最核心的KPI,必须定义清楚、统计准确,否则考核没有依据
坑 06 大屏做出来了,但车间没人看——挂在角落里,亮度不够,内容不吸引人
原因: 大屏挂在车间角落(找不到好位置),亮度不够(车间灯光亮,大屏看不清),内容只有数字(没有视觉冲击力),刷新慢(5分钟才更新一次,不是实时)。工人路过也不看,大屏成了摆设
解决: 大屏"看得见+看得清+愿意看":①位置:挂在车间入口/主干道/休息区,所有人进出都能看到,高度2.5-3米(平视略高);②硬件:65寸以上大屏,亮度≥500nit(普通电视只有300nit,车间亮环境看不清),或者用LED拼接屏(亮度更高);③内容设计:当前异常用大红色闪烁+倒计时(视觉冲击力强),产量用大数字+进度条(目标vs实际),OEE用仪表盘+颜色(绿/黄/红),不要满屏都是小数字;④实时刷新:刷新频率<5秒,异常触发后1秒内大屏要显示;⑤多屏轮播:如果车间大,部署多个大屏,或者一个大屏自动轮播(产线1→产线2→全厂总览,每个10秒)。关键:大屏的目的是"让人看到异常并行动",不是"展示数据"——挂在角落、亮度不够、内容枯燥,等于没挂

06 关键代码片段

ESP32按钮盒核心逻辑(Arduino示例)

// 按钮按下→MQTT发布事件→本地声光反馈→等待服务器确认
// 4个按钮:质量(黄)/设备(红)/物料(蓝)/安全(绿)
#include <WiFi.h>
#include <PubSubClient.h>
#include <SPIFFS.h>

WiFiClient espClient;
PubSubClient client(espClient);
const char* mqttServer = "192.168.1.100";
const char* stationId = "STATION-01";  // 工位ID
bool ackReceived = false;

// 按钮引脚定义
const int BUTTONS[4] = { 4, 5, 6, 7 };  // 质量/设备/物料/安全
const int LEDS[4] = { 8, 9, 10, 11 };
const int BUZZER = 12;
const char* TYPES[4] = { "quality", "equipment", "material", "safety" };

void setup() {
    Serial.begin(115200);
    SPIFFS.begin(true);  // 本地缓存用SPIFFS
    
    // 初始化按钮(上拉输入)和LED
    for (int i = 0; i < 4; i++) {
        pinMode(BUTTONS[i], INPUT_PULLUP);
        pinMode(LEDS[i], OUTPUT);
    }
    pinMode(BUZZER, OUTPUT);
    
    WiFi.begin("SSID", "PASSWORD");
    while (WiFi.status() != WL_CONNECTED) { delay(500); }
    
    client.setServer(mqttServer, 1883);
    client.setCallback(mqttCallback);  // 处理服务器确认消息
    reconnect();
}

void loop() {
    if (!client.connected()) reconnect();
    client.loop();
    
    // 扫描按钮(去抖:按下持续50ms才确认)
    for (int i = 0; i < 4; i++) {
        if (digitalRead(BUTTONS[i]) == LOW) {  // 按下(上拉输入,低电平有效)
            delay(50);  // 去抖
            if (digitalRead(BUTTONS[i]) == LOW) {
                triggerAlarm(i);  // 触发异常
                while (digitalRead(BUTTONS[i]) == LOW) delay(10);  // 等待释放
            }
        }
    }
}

void triggerAlarm(int typeIndex) {
    // 1. 本地声光反馈(不依赖网络,按下立刻有反应)
    digitalWrite(LEDS[typeIndex], HIGH);  // LED闪烁
    tone(BUZZER, 1000, 200);  // 蜂鸣器响
    
    // 2. 构造MQTT消息
    String topic = String("andon/") + stationId + "/event";
    String payload = String("{") + 
        "\\"station\\":\\"" + stationId + "\\"," +
        "\\"type\\":\\"" + TYPES[typeIndex] + "\\"," +
        "\\"timestamp\\":" + String(millis()) + 
        "}";
    
    // 3. 发布MQTT消息(QoS1,至少送达一次)
    bool published = client.publish(topic.c_str(), payload.c_str(), true);
    
    // 4. 发布失败(网络断了)→ 存本地SPIFFS,恢复后补传
    if (!published) {
        saveToSPIFFS(topic, payload);
        Serial.println("WiFi断开,事件已存本地缓存");
    }
    
    // 5. 等待服务器确认(5秒超时,超时后重发)
    ackReceived = false;
    unsigned long start = millis();
    while (!ackReceived && millis() - start < 5000) {
        client.loop();
        delay(10);
    }
    
    if (ackReceived) {
        // 收到确认→LED变绿(所有LED亮绿色,表示已收到)
        digitalWrite(LEDS[typeIndex], LOW);
        // 绿色LED亮3秒
        digitalWrite(LEDS[3], HIGH);  // 安全键的LED当绿色确认灯用
        delay(3000);
        digitalWrite(LEDS[3], LOW);
    } else {
        Serial.println("未收到服务器确认,事件已存本地待补传");
    }
}

void mqttCallback(char* topic, byte* payload, unsigned int length) {
    // 处理服务器确认消息(主题:andon/STATION-01/ack)
    String ackTopic = String("andon/") + stationId + "/ack";
    if (String(topic) == ackTopic) {
        ackReceived = true;
    }
}

07 实际效果

提升3倍
异常响应速度
从平均15分钟→5分钟以内
20-40%
停机时间减少
异常快速暴露+快速响应,减少停机
<200元
单工位改造成本
ESP32自制按钮盒,比商业便宜90%
>95%
异常识别率
从"靠喊"到"系统记录",异常不遗漏
<1秒
大屏实时性
按钮按下到大屏显示,MQTT实时推送
<1个月
投资回报周期
减少停机损失,快速回本

08 相关软件与工具

需要生产看板/安灯系统?

丁丁做过多个工厂的安灯系统和生产看板项目,熟悉ESP32按钮盒制作、MQTT实时传输、Node-RED异常逻辑、Grafana大屏开发、钉钉/企业微信报警集成。可以帮你做方案设计、硬件制作、系统开发、现场调试,帮你实现车间信息透明化。