生产制造车间待久了你会发现产线上最值钱的不是设备本身而是“出问题之后多久能被看见”。传统安灯系统靠拉绳、按钮盒触发操作员跑到现场按一下物理灯亮起来班组长看到后跑过去处理。这套逻辑本身没错但问题在于按下去之后只有灯和声音异常类型靠喊、响应时长靠猜、数据统计靠人肉填Excel。一旦车间上了数字化看板“按钮无法报具体异常”就成了硬伤。这个项目就是冲着这个痛点来的用一台普通PC替换物理按钮操作员在工位电脑上点一下异常类型、工位编号、触发时间、责任响应人全部自动生成同时看板大屏立刻闪烁报警、声光报警器联动响起整个响应链路全程留痕。如果你正在做精益生产推进、车间数字化改造或者要给现有产线补一套异常管理闭环这篇内容可以直接当落地参考。1. 项目认知为什么要把安灯触发从“物理按钮”搬到PC上1.1 安灯系统的本质与现状安灯Andon这个概念出自丰田生产方式本质是一套“异常快速暴露机制”。TPS的核心不是消灭异常而是让异常在发生的瞬间被看见。异常被看见了才有机会被响应、被纠正、被沉淀为改善课题。所以安灯系统绝不是“装几个灯喊一喊”它是一套拉动式的管理信号装置。传统的安灯实现大概有三种拉绳方式产线旁边一条绳拉动后整条线段停线灯亮报警。适合流水线连续作业场景。按钮盒方式工位旁固定安装几个彩色按钮按不同的按钮对应不同异常红色设备故障、黄色物料短缺、绿色求助。无线遥控器方式操作员随身带一个小遥控走到哪都能按灵活性高但电池维护和防误触是老大难。我在车间里见过不少装了按钮盒的产线现场实际用起来问题很多。最典型的是按钮只有红黄绿三颗设备故障、模具损坏、物料质量、图纸疑问全都压在“红色”一颗按钮上。看板亮了红灯班长跑过来问“怎么了”操作员说了一遍班长再转达给维修师傅信息传递折损两次问题定位全靠两条腿。还有个更大的问题——没有记录。按钮按下去灯亮响应人来了修复了灯灭。整个过程“灭灯即消失”工厂复盘时拿不出任何数据。做精益的人想把问题分层、做柏拉图分析、算异常响应时长却发现历史数据完全空白。传统按钮式安灯本质上是把异常信息“按成了灯”而不是“按成了数据”。1.2 PC操控模式解决的核心痛点把触发端从“物理按钮”换成“PC软件”不是省几个按钮的钱而是把安灯从“信号装置”升级成“数据采集与流程管控节点”。实际操作中PC操控带来的核心改变有五点异常类型细分。PC界面可以放十几个按钮质量异常、设备故障、物料短缺、工装问题、技术求助、安全事件每一种都单独标记。甚至同一类异常可以再分下级设备故障还能区分“停机”、“参数偏移”、“异响”、“漏油”。点一下按钮信息结构化责任归属清晰。数据自动留痕。每次触发都记录操作员账号、工位编码、异常类型、触发时间、响应人、响应时刻、恢复时刻。这些数据的价值远超过一次报警本身因为月底做改善报告时它是异常分布和响应SLA的原始依据。响应闭环可控。PC端触发后异常工单直接推送给对应责任人的看板或手机端责任人到场后需要在系统中“确认响应”否则异常持续升级。这个闭环是物理按钮根本做不到的。条件判断能力。有些异常需要限定条件才能触发。比如“物料短缺”如果该工位当前批次刚领过料且用量未过半系统可以拦截或提示确认。物理按钮只能无脑触发PC端可以内置业务规则。远程代触与多端联动。班组长在办公室看到某个工位状态异常可以直接在管理端代为触发或代为确认。这在物理按钮时代是不可想象的。1.3 方案选型局域网优先还是直接走云端安灯系统对实时性要求很高操作员点击之后看板最好1秒内反馈。如果一个车间的网络都不稳定云端方案再先进也白搭。我见过一些项目把安灯摘到云端平台结果车间AP一抖动看板延迟十几秒操作员以为没触发成功又点了一遍数据直接重复。所以这个项目的核心处理链路走的局域网PC触发的数据先到车间网关服务看板和声光报警都通过局域网内网通信。云端不是完全不用而是放在汇聚层做跨厂区汇总和移动端通知。局域网负责实时控制云端负责数据汇聚和消息推送两边解耦。因为安灯记录的数据量本身不大每天几千条就算全部上报网络负担也很小。这样做的好处是产线自动化层哪怕断外网看板和报警依然秒级工作不会因为一条外网线路故障导致整个车间失去异常管控能力。2. 系统整体设计异常怎么定义、报警怎么流转2.1 异常类型与响应等级怎么定义项目启动第一步别急着敲代码一定先把异常类型理清楚。这是整个系统最容易返工的地方。只分“设备、质量、物料”三大类是不够的因为每个工厂的异常颗粒度完全不一样。我又见过一些团队上来就设计三十多个异常类型把操作员搞蒙了点都找不到最后现场根本不用。比较合理的做法是两层结构一级分类控制广度二级分类控制颗粒度。一级分类控制在5-7个二级分类按车间实际情况配置。以下是我在某电子装配车间实际跑过的模型可以直接参考一级分类二级分类示例默认响应角色首次响应时限升级时限设备异常停机、异响、参数偏移、漏油设备工程师5分钟10分钟质量异常不良品、测试fail、外观缺陷质量工程师5分钟10分钟物料异常缺料、错料、物料品质物料组/线长3分钟8分钟工装异常夹具损坏、定位偏移工艺工程师5分钟15分钟技术求助图纸疑问、程序疑问工艺/PE10分钟20分钟安全事件人员受伤、安全隐患安全员线长立即3分钟这张表想说明的是每种异常必须绑定一个默认响应角色和一个升级路径。升级逻辑解决了“异常一直没人响应怎么办”的推诿问题。举个例子设备异常触发后5分钟没人确认系统自动给设备主管发通知再等10分钟还没处理自动升级到厂长级别。这个机制一旦跑起来响应率会显著提升因为管理层面子挂不住。2.2 从触发到看板的信号链路设计整个系统的信号链路可以拆成五段PC客户端 → 网关服务 → 业务服务 → 看板大屏/声光报警器 → 通知系统。第一段操作员在PC上点击异常按钮客户端把工位号、异常类型、操作员账号、备注内容打包成一条JSONPOST到网关服务的HTTP接口。这里强调一下虽然车间内网延迟低但客户端UI必须做“本地先反馈”点击后按钮立即变灰并显示“已发送”等服务端确认返回后再变成“触发成功”或“触发失败”。否则弱网情况下操作员以为没反应会反复点击造成重复数据。第二段网关服务收到请求后先做基础校验工位是否存在、异常类型是否有效、该工位是否已有未处理的同类型异常校验通过后写入数据库同时向消息总线推送一条“新异常事件”。第三段业务服务监听事件执行四件事给看板推送新异常卡片、控制声光报警器点亮、按规则匹配响应责任人、判断是否需要发送短信通知。第四段看板大屏收到事件后将异常卡片插入页面顶部列表触发闪烁动画与声音提示声光报警模块根据工位和异常等级点亮对应颜色灯并启动蜂鸣。第五段如果超时未响应升级任务触发系统向升级对象发送短信或企微消息。整个过程每个环节都要打印日志方便排查问题。2.3 关键硬件选型与通讯协议PC硬件没啥特殊的一台能运行的Windows工控机就行配置不用高。如果现场没有现成PC几百块的小主机也能带起来。重点说两个容易踩坑的设备声光报警器和IO控制方式。声光报警器我踩过一次坑买个了很便宜的结果蜂鸣器声音还没车间设备声音大等于没装。报警器至少要有三色灯红黄绿加高分贝蜂鸣器建议选可以单独控制灯色和蜂鸣开关的型号这样软件里可以做“亮红灯但不响”和“红灯蜂鸣”两种模式。IO控制方式主要有三种方式优点缺点适用场景串口继电器卡便宜、协议简单连线多、抗干扰差小范围测试Modbus TCP模块一根网线、稳定、地址灵活模块成本略高大多数产线工业PLC扩展IO稳定性最好需要PLC编程、调试成本高已有PLC的产线我建议优先用Modbus TCP模块。一台16路的模块大概一千多块接一根网线就能控制16路设备的灯和蜂鸣器不需要拉一堆控制线。更关键的是修改对应线圈地址就能控制灯亮灭调试效率高也不用动PLC程序。3. 实操落地数据库建模、PC操控端开发、看板大屏实现3.1 数据库表结构设计安灯系统的数据表不复杂但设计上有一个关键点报警记录表要冗余工位名称和异常类型名称不要只存ID。我第一次做的时候按传统三范式拆得很干净看板每次查询都要join四五个表大屏刷新一慢操作员和班长都开始抱怨。后来把常用字段冗余进记录表查询直接从单表查速度明显改善。三范式是课本现场对查询性能要求更高适度冗余是对的。核心表结构可以参考下面这套CREATE TABLE andon_event_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, station_code VARCHAR(32) NOT NULL, station_name VARCHAR(64) NOT NULL, event_type_id INT NOT NULL, event_type_name VARCHAR(64) NOT NULL, level_no TINYINT NOT NULL DEFAULT 1, content TEXT, created_at DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 0, response_at DATETIME, response_by VARCHAR(64), source CHAR(1) DEFAULT P, INDEX idx_status_created (status, created_at) ); CREATE TABLE andon_event_response ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id BIGINT NOT NULL, response_at DATETIME NOT NULL, response_by VARCHAR(64) NOT NULL, response_type TINYINT COMMENT 1到场 2修复 3误报 4取消, content TEXT, INDEX idx_event_id (event_id) ); CREATE TABLE andon_upgrade_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, event_id BIGINT NOT NULL, upgrade_level TINYINT NOT NULL, target_role VARCHAR(64), created_at DATETIME NOT NULL, INDEX idx_event_id (event_id) );字段说明几个容易忽略的地方status用0/1/2/3分别表示未响应/已响应/已取消/已关闭。这里“已取消”和“已关闭”一定要分开取消是操作员误触发主动撤回关闭是异常处理完成正常结束。统计报告里这两个状态含义完全不同混在一起会导致响应时长数据失真。created_at统一用服务端时间生成。这个我特别强调一下PC客户端发送时会把本地时间一起带上但千万不要用它来排序和统计。车间里的工控机从来不校时有些机器时钟偏了十几分钟一旦参与统计看板上的响应时长就是乱的。正确做法是客户端发送时间仅作为参考字段local_time服务端以收到的系统时间created_at为准。3.2 PC操控端的功能与实现逻辑PC操控端是操作员每天面对的东西界面设计原则是大字、大按钮、颜色直观、最少两步完成触发。车间操作员普遍戴着手套鼠标操作精度低所以按钮高度至少60像素以上异常类型按钮用大色块区分——设备异常是红色质量异常是橙色物料异常是黄色求助是蓝色。界面主操作区只放核心按钮其他功能全部折叠。核心操作流程是点击异常类型按钮 → 弹出确认面板显示工位、异常类型、备注输入框→ 点击“确认触发”。确认面板很重要能挡住绝大多数误触。但也不要搞太繁琐两步够用。具体实现逻辑里有两个细节值得分享防重复提交。按钮点击后立即禁用2秒并调接口查询该工位当前是否存在未响应的同类型异常。如果存在提示“该工位已有未处理的设备异常记录”不重复创建。这个逻辑比单纯防连点更实用因为它从数据层面拦住了同一时间段的重复触发。误触发取消窗口。确认触发后PC端保留一个10秒的取消倒计时10秒内操作员可以点击“撤销”。倒计时结束后就无法取消了。但设备异常和安全事件这两个分类不允许取消因为设备异常一旦触发通常伴随着停机或维修动作安全事件更是必须留下记录。不同异常类型可以设置不同的取消策略这个字段要加到异常类型配置表里。PC端技术栈选择上如果团队熟悉Web技术用Electron包一层比较快如果想减少内存占用直接用WinForms或WPF配合WebView也行。我个人建议优先考虑本地应用而不是纯网页原因很简单PC端还要对接刷卡器、扫描枪这类外设。比如扫描员工卡确认响应本地应用读串口很方便网页就需要调额外的驱动程序实在麻烦。3.3 看板报警页面的数据刷新方案车间看板大屏通常就是一个浏览器全屏页面显示当前产线状态。数据刷新有两种主流方案轮询和WebSocket。轮询最省事前端每隔3秒调一次GET /api/andon/active接口拿当前未处理异常列表。数据量不大3秒一次对数据库压力很小。但它有个明显问题如果车间里挂了20台大屏同时3秒轮询一个接口数据库QPS就增加不少。解决方法是接口前面加一层缓存Redis缓存活动异常列表大屏查询时直接打缓存数据库只在事件变化时更新缓存。WebSocket推送是实时性最好的方案服务端有事件时主动推送延迟可以做到毫秒级。对安灯这种秒级响应要求的场景WebSocket是首选。如果团队没有现成的MQTT或消息中间件直接用WebSocket协议自己封装一个简单的发布订阅模型也够用。前端订阅andon/status主题服务端在异常触发、响应、取消、升级时推送完整的活动异常列表。大屏页面核心展示内容要清楚每个工位的实时状态格正常是绿色异常红色闪烁已响应黄色离线灰色当前未处理异常列表按触发时间倒序超时未响应的置顶显示异常类型饼图、响应SLA达成率、今日趋势超时升级记录滚动条大屏上最容易忽略的是浏览器声音策略。浏览器默认不允许页面在用户没有交互的情况下自动播放音频导致异常触发时大屏“闪了灯却没声音”。解决方式是页面右下角放一个“开启声音”按钮首次进入大屏时手动点击解锁音频之后异常触发时就可以正常播放提示音。这个坑我第一版就踩了测试时点开浏览器有声音设备接上去后大屏黑屏重启完就没有了查了半天发现是浏览器策略限制。3.4 声光报警与异常升级联动声光报警不推荐由PC客户端直接控制而是由服务端统一调度。原因很简单PC可能关机、断网、被强制关闭而服务端是7x24小时跑的。一旦异常触发客户端只需要负责把数据传给服务端服务端再根据异常类型和工位编码去控制Modbus模块点灯。流程上是这样跑通的# 伪代码服务端控制声光报警 def on_new_event(event): module_address station_to_module(event.station_code) if event.level 1: modbus.write_coil(module_address, coil_redTrue) modbus.write_coil(module_address, coil_buzzerTrue) elif event.level 2: modbus.write_coil(module_address, coil_redTrue) modbus.write_coil(module_address, coil_buzzerFalse)station_to_module维护一张工位和Modbus地址的映射表工位A的红灯线圈是1蜂鸣器是2工位B的红灯线圈是3蜂鸣器是4依次排下来。这块配置放在数据库里不要写在代码里因为现场调整工位和报警器对应关系是常有的事。响应确认之后服务端写绿、熄红灯。同时还要检查这条异常是否真的被处理完也就是响应记录里是否有关闭标记。如果处理人标记了“处理完成”这条异常才算真正关闭。升级逻辑非常简单但要注意一个原则升级计时从触发时刻开始算不是从推送确认时刻开始算。现场管理的口径是“这个异常已经挂了多少分钟”从触发开始计时才能真实反映响应时长。升级动作放到一个定时任务里每30秒扫一次处于“未响应”状态且超时的异常满足条件就发通知并记录升级日志。4. 联调测试与异常处理实录4.1 模拟触发验证全链路系统开发完成后联调阶段一定不能只在开发环境里点一点就完事。至少要做三轮完整的链路验证。第一轮是接口联调。用HTTP工具模拟PC客户端调用触发接口确认数据落库、看板能拉到最新记录、报警器能亮灯。接口层验证通过后再做异常流程验证触发 → 响应 → 关闭走一遍状态流转。第二轮是端到端现场验证。让试产线上的操作员真实点击PC界面观察体验是否顺畅、按钮是否够大、确认面板是否清晰。这个环节能发现开发阶段根本想不到的操作习惯比如操作员习惯左手点鼠标、有人手指粗总点到旁边的按钮、有人不看文字只看颜色。第三轮是断网测试。这是很多人会忽略但现场必考的项目。把工位的网线拔掉操作员点击触发PC端应该提示“网络异常已本地记录”并且把数据缓存到本地队列。网络恢复后自动补传。没有这个能力网络一断整个系统就瘫痪了操作员只能跑回去找物理按钮一个月下来网线被踢掉几次系统口碑就没了。4.2 常见问题速查表现象可能原因排查方式解决建议看板不刷新前端轮询接口报错、WebSocket连接断开打开浏览器F12看网络请求/控制台日志排查后端服务状态WebSocket加自动重连声光报警器不响Modbus地址错误、模块断电、线圈被占用用Modbus调试工具手动写线圈测试建立报警器巡检记录每日早班自检PC端提示连接失败网关服务停止、网络不通在PC上用Ping/telnet测试网关端口网关服务配开机自启PC端做本地缓存异常记录重复客户端防重复逻辑失效、网络超时重发查看触发时间连续的多条记录服务端增加工位类型时间窗口去重看板排序错乱PC和服务端时钟不一致对比记录创建时间和PC本地时间统一用服务端时间客户端时间只当参考浏览器无报警声音浏览器自动播放策略限制看控制台是否提示Audio playback错误首次进入页面强制用户点击“开启声音”按钮无法取消误触发取消窗口已过、类型不允许取消查看异常类型配置配置页区分“可取消”和“不可取消”类型4.3 现场实施中的几个提醒第一个提醒PC端一定要锁权限。工位电脑常常被操作员当普通电脑用登录微信、插U盘、乱装软件系统跑几天就卡死。实施时做两件事一是开机自启安灯客户端全屏运行并置顶二是禁用任务管理器和AltF4防止误关程序。Windows更新必须通过组策略禁用或设置维护窗口否则半夜自动重启第二天早班操作员对着黑屏发懵这是现场最常见的事故。第二个提醒PC和物理按钮最好并行保留。很多精益经理把数字化看得过重上线PC后就拆了物理按钮。但现场总有特殊情况——电脑死机、系统更新、网络故障。保留一套物理按钮作为应急后备成本也就几百块关键时候能保住产线的异常暴露能力。这也方便向现场员工证明系统在过渡期是稳妥的。第三个提醒项目交付的重心不是“能触发”而是“环环有记录、超时能升级”。开发阶段我建议大家先做PC触发和看板报警这两块见效快领导看了满意第二优先级做响应闭环和超时升级最后做统计报表和分析页面。管理层的关注点永远是“什么异常多、谁响应慢、改善有没有效果”这些都必须依赖完整的数据闭环。最后分享一点个人实操体会这套PC安灯系统跑通之后我最深的感触是技术实现其实很简单难的是把业务流程钉死在系统里。物理按钮时代异常能不能被看见取决于操作员愿不愿意跑一趟PC操控时代系统能强制操作员点击“响应确认”、强制超时升级、每天生成异常分析报告这些约束才是真正的价值。所以做这个项目时花了一周时间讨论异常类型和响应角色比写代码时间长一倍但这步做错了后面所有功能都会变形。最后再留一个小技巧现场看板最好保留一块“历史趋势”区域显示最近7天异常数量曲线。员工会盯着这个曲线看一旦哪天异常数突然升高不用等管理者追问操作员和班长自己就会去复盘原因。这种“数据驱动自管理”的效果比任何管理考核都管用。