简介总装车间生产目视管理ANDON系统是一份面向工业工程、生产管理与自动化领域的专业设计文档。它系统阐述ANDON如何通过工序作业、设备状态、质量管理、供应管理、停线管理和环境管理六大功能模块实现生产信息目视化、传递快捷化与工序透明化同时给出显示屏、电脑终端、广播、声音报警、转灯报警五种信息输出方式以及设备底层信号采集、现场呼叫终端、信息管理层等分层配置方案并涉及服务器、PLC、DeviceNet总线、ControlNet、INTOUCH组态软件等关键技术选型。文档还详细定义了停线权限设备限制、质量问题、计划停线与拉线/按钮呼叫方式适合总装车间规划、改造及生产提效项目参考可作为系统方案设计与设备选型的重要依据。资源为单个doc文件大小66KB内容完整结构清晰便于直接阅读和引用。已有82人学习下载适合正在搭建或优化ANDON系统的工程师、生产管理者快速获取可落地的设计思路。1. 资料总装车间的ANDON不是买块屏那么简单资料总装车间的班组长十有八九有个习惯动作站在工位尽头扯着嗓子喊。物料员在哪、设备员在哪、上一序为什么还没送来——这些信息全靠人肉传递等喊明白了整条线已经停了十分钟。ANDON系统安灯系统要解决的正是这件事把工位上的异常变成看得见的信号让对应的支持角色按优先级到场处理。网上下载的系统设计doc常被冠以“完美版”但真正能落地的设计关键不在架构图画得多漂亮而在点位表、SLA、报警联动这些细节里。这篇文章适合工艺、信息化和生产管理岗位的从业者。我把一套资料总装车间的ANDON设计思路按可施工顺序拆开讲包含架构选型、关键参数、系统对接和最容易返工的地方。2. 按工位异常设计系统架构先把呼叫链路画清楚2.1 三种常见的ANDON架构人工总装线我为什么选“柔性IO软件服务”做ANDON设计第一步不是画拓扑图而是回答一个问题用什么样的物理链路把“人按按钮”变成“系统里的一个事件”。当前常见的方案有三种各有各的适用场景。传统PLC硬接线方案在汽车焊装这类流水线上很常见。每个工位拉多芯电缆到PLC柜按钮直接进PLC的DI点PLC再驱动看板和报警灯。这种方案胜在实时性高、抗干扰强但施工量非常大一个工位十几根线后期调整工序布局几乎等于重新布线。资料总装车间如果产线半年调整一次硬接线方案的成本和改动周期都难以接受。一体化ANDON终端这两年在小装配线里很流行一个盒子自带按钮、喇叭和Wi-Fi接电就能用。它的问题在于封闭——点位固定数据模型写死在设备里想对接MES或者WMS往往只能靠导出Excel。资料总装车间要的是缺料联动、质量停线、人员请求混合编排这种盒子很难满足。我一般会选“分布式IO模块软件服务”的柔性方案工位上装普通按钮和指示灯按钮接在Modbus TCP的分布式IO模块上中央服务轮询IO状态并做逻辑判断输出到LED看板和声光报警器。这个方案的优势是工位调整只需要改软件映射分布式IO模块可以顺着网线随便移位代价是要求车间网络相对稳定这也是后面要重点处理的部分。三种方案的取舍核心看一个指标工艺变更频率。资料总装车间的特点是多品种、小批量今天做这批订单是12个工位下个月可能合并成8个物料位置、质检节点、节拍全变。ANDON设计文档里如果没给“变更后如何重新部署”留路径这张图只能停留在PPT上。2.2 从总装车间SOP里挖出12种异常重新定义呼叫类型很多ANDON设计文档把按钮直接标成“1号键、2号键、3号键”这是典型的偷懒做法。按钮是给一线员工按的员工在异常发生的瞬间不应该犹豫“我该按哪个键”。他会想的是“我现在遇到的是缺料还是质量还是设备卡纸”。所以必须先梳理异常类型再分配按键和灯光颜色。我习惯的做法是蹲在车间跟班一个完整班次把SOP从头到尾看一遍再找班组长、物料员、设备员各聊半小时。资料总装车间的异常通常集中在物料齐套、质量确认、设备故障、工艺支持这几类。把收集到的异常归纳成一张呼叫类型表类型编码异常名称优先级响应角色看板颜色A1物料短缺P1物料员黄色A2物料数量与BOM不符P1物料员黄色B1过程质量异常P0质量工程师红色B2首件确认P0质量/工艺红色C1设备卡纸/故障P1设备员蓝色C2工具磨损P2设备员蓝色D1工艺指导不明确P2工艺员绿色D2工装夹具调整P1工艺员绿色E1安全隐患/5SP0安全员红色F1上一工序延迟供应P1生产调度橙色F2人员临时离岗P2班组长白色这张表后续所有环节的主键。LED屏显示、声光报警、广播播报、报表统计全部依赖这个编码体系。设计文档里必须单列一节把这张表写清楚并注明“异常类型编码与MES异常代码的映射关系由信息化部门确认”。一旦现场发现新异常先加编码再加流程绝不能让员工拿“其他”按钮代替。2.3 把呼叫链路拆成四个子系统输入层、传输层、决策层、展示层ANDON设计文档里最常见的败笔是把系统画成一个“按钮连屏幕”的黑匣子。真正可实施的设计要把链路拆开明确每一层做什么、层与层之间交换什么数据。以分布式IO方案为例我会把链路拆成四层。输入层是工位端的一切信号来源包括呼叫按钮、带确认灯的选择开关、工位上料检测光电开关、以及一个用于复杂操作的触摸屏。这里有个设计细节按钮必须自带LED确认灯灯亮不亮由硬件回路直接控制不依赖上层软件。这样员工按下按钮后灯亮了说明按钮本身没问题。后面排查故障时可以快速切分是输入层问题还是决策层问题。传输层是工业交换机加Modbus TCP。中央服务和IO模块之间采用轮询机制轮询周期建议设置在200~500毫秒。响应500毫秒对人工总装线足够用因为这个系统的目的不是做设备急停而是管理异常响应。传输层唯一要警惕的是广播风暴IO模块属于工业设备对网络异常极其敏感后面避坑章节我会专门讲。决策层是一个运行在工控机上的中央服务承担事件判定、优先级仲裁、超时计时、升级触发、数据落库并且向外提供HTTP API给MES、WMS调用。这一层是整套ANDON系统设计的核心价值所在后文会展开讲里面的联动逻辑。展示层包括车间LED看板、工位本地LCD屏、三色声光报警器、广播分区和班组长手机端的通知。展示层和输入层之间需要保留一个硬接线回路异常发生且没人处理时即使中央服务卡死工位灯和报警器也能通过IO模块的DO输出直接点亮。这个冗余设计看着简单却能在关键时刻保住系统的可信度。整个闭环链路的关键动线是员工按下按钮IO模块把状态变化传给中央服务服务根据编码生成一个带时间戳的异常事件看板和声光报警立即刷新同时通知对应角色响应人到达工位后按“到场确认”按钮异常事件被打上闭环时间标签。很多人做ANDON只做了“呼叫—显示”这一半没做“到场确认”这后半段结果是系统没有任何约束力呼叫完没人处理也没人知道。3. 把设计文档写成能施工的图纸点位表、联动逻辑与看板布局3.1 点位表是ANDON的“黑匣子钥匙”命名规范与地址映射网上流传的ANDON设计doc十有八九只给一张系统架构图没有点位表。没有点位表的设计文档到了施工阶段就是灾难——电气工程师接完线不知道哪个按钮对应哪个地址调试工程师拿着万用表一个点一个点查查了一天发现IO模块的站号配错了。点位表是ANDON设计里必须交付的第一张施工图纸。命名规范我建议这么定ANDON-工位号-按钮物理编号-功能编码-输入输出标识。比如ANDON-W03-B01-A1-DI意思是3号工位第一个按钮功能是A1缺料呼叫属于数字量输入。同时给每个IO模块分配一个Modbus站号站号在模块上拨码设定并记录在点位表里。点位表的关键字段至少包括设备名称、模块型号、模块站号、寄存器首地址、数据类型DI/DO、信号名称、工位号、功能语义、接线端子号、备注。这张表必须由工艺、设备、信息化三方会签。我见过一次返工起因是设备工程师按自己的习惯把1号工位编成W01工艺工程师看习惯的是“一工位”结果调试当天发现看板上显示的工位号全对不上最后查了半天是命名规范不统一。点位表下发施工队后还要做一次“地址对照复核”。方法是调试阶段逐点短接输入信号在服务端看事件日志是否出现对应工位和功能。这一步不要偷懒10个工位40个点一个人一下午能测完但能省掉后面排查“玄学故障”的大量时间。3.2 定义响应SLA和升级路径让异常在3分钟内有人接单ANDON系统能不能在车间里立住不取决于看板多漂亮取决于“呼叫之后有没有人管”。这需要一个量化的SLA体系而且要写进设计文档作为系统配置项其中最大超时时间按分钟设定尽量不使用小时或随意给一个整数。我会按优先级定义三档SLAP0异常从按钮按下到第一响应人点击“接单”不超过3分钟到场不超过5分钟如果10分钟没闭环系统自动向车间主任发送第二级通知P1异常接单5分钟到场10分钟超时15分钟升级到值班经理P2异常允许适当延迟但必须当班闭环否则自动滚动到下一班次的待办清单。这里要强调一下“接单”和“到场”是两个指标分别计时。为了让SLA可执行设计里需要一张响应角色映射表A1缺料对应物料员B1质量异常对应质量工程师C1设备故障对应设备员。系统按异常类型找到对应的角色通过LED看板高亮滚动、语音播报、手机消息三个通道同时通知。这里必须配置“接单按钮”响应人到工位后在现场按确认键系统才能继续下一步计时。不能设计成“回到电脑前点确认”因为那会让“到场”变成虚假数据。这类SLA参数不要由IT部门闭着眼睛写。我在设计文档里通常附一张《SLA确认表》明确写着“由车间主任、物料组长、设备组长签字确认后生效”。ANDON系统本质上是管理工具管理者自己不认同这些数字系统就没有压制力。3.3 看板布局不是UI问题是管理问题分区、颜色与声音预案LED看板是ANDON系统面向全车间的“脸面”但很多设计文档把看板当成单纯的大屏展示来画这是理解偏了。看板的核心功能不是显示而是迫使异常在几十秒内被全车间看见。人是有从众心理的一旦整条线都知道3号工位有问题而没人处理责任压力就会迅速堆积到对应支持人员身上。看板布局我建议分三个区域左侧是当前异常滚动区显示工位号、异常类型、持续时长中间是当日呼叫汇总区按工位排列显示已完成和未闭环的事件右侧是当日异常统计区显示各类型异常次数和平均闭环时间。LED四行屏可以做前三行滚动最下面一行固定显示当前未闭环数量。颜色编码和前面异常类型表对应红色代表P0质量或者安全问题黄色代表缺料蓝色代表设备绿色代表工艺白色代表人员呼叫。这样车间里任何一个人抬头看三秒就知道哪里出了问题以及问题等级而不用走近看文字内容。声音预案也要分层设计。P0响急促的间断长鸣并伴随语音播报“三工位缺料异常请物料员到场”P1响一段短旋律后只播报一次P2只上屏不发声。同时必须设计夜间或低噪音时段模式避免影响非生产班次。资料总装车间的切纸机、胶装机、空压机噪音都很大单纯语音播报等于没报所以要依靠高频警笛加LED屏文字必要时接入分区广播系统。4. 从doc到现场网络规划、硬件选型与MES对接的前置参数4.1 网络与供电规划车间电磁干扰下的稳定传输ANDON系统的传输层用的是工业以太网但车间环境并不友好。资料总装车间里既有斩波调速的电机又有加热辊和空压机电磁干扰源多且杂。弱电布线必须和动力电缆分开走桥架间距保持30厘米以上如果空间受限无法分离中间加金属隔板屏蔽。网络规划要预留清晰的IP地址分配表。我习惯这样规划中央服务占用192.168.1.10工业交换机管理地址从192.168.1.1到192.168.1.9IO模块从192.168.1.20开始按工位顺序分配LED看板统一在192.168.1.50到192.168.1.60车间办公Wi-Fi终端在另一组地址段。IO模块所在的VLAN要单独划分禁止和车间视频监控流量混在一个二层广播域里否则突发的大流量会造成IO模块掉线。供电方面分布式IO模块和按钮指示灯统一用DC24V由机柜内的开关电源集中供电。现场设备启停频繁电压波动大模块端一定要加防浪涌保护器。我用过一个便宜的国产IO模块电源没做隔离空压机一启动模块就重启换了带隔离的版本之后再没犯过。供电设计里还要考虑断电解耦中央服务和IO模块分别接在两路电源上或者给中央服务配一个UPS确保车间晃电时ANDON系统不自乱。无线方案在输入层要慎用。Wi-Fi按钮或者Wi-Fi IO模块看着省事但车间里金属货架和移动小车对无线信号衰减非常明显运行时会出现时断时续的“灵异事件”。我一般只允许展示层使用无线现场IO层一律走有线这是多年做下来最稳的边界。4.2 硬件选型参数按钮、IO模块、LED屏、声光报警器的关键指标硬件选型是设计文档里容易被“感性决策”带偏的部分。采购看到好看的触摸屏就觉得高级但运维会在意它好不好拆、防不防尘。按资料总装车间的实际使用条件我建议在询价清单里明确下列关键参数。硬件关键参数呼叫按钮防护等级IP65以上机械寿命100万次自带LED确认灯复位方式选用自复位式接线方式为可插拔端子分布式IO模块支持Modbus TCPDI点数16以上带光电隔离工作温度-20℃~70℃供电DC24VDIN导轨安装LED看板可视距离15米以上四行四字配置亮度不低于2000cd/m²支持Modbus TCP或RS485通信三色声光报警器红黄绿三色独立控制声压不低于90dB(A)支持爆闪模式广播功放RMS功率60W以上支持分区控制能与报警灯联动按钮的IP65要求不是拍脑袋定的。资料总装车间虽然比机械加工车间干净但裁纸工序会产生纸屑粉尘胶装机附近湿度偏高防护等级不够的按钮触点会氧化三个月后开始接触不良。LED看板的亮度参数同样有讲究车间面积大、采光好亮度低于2000cd/m²的中午看不清显示内容。这里的选型逻辑要分解成两句话写进文档一是“所有的硬件接口必须开放支持Modbus TCP或HTTP协议”避免买到封闭协议的产品二是“不允许采购需要专用客户端才能管理的设备”维护团队没有精力为一个ANDON系统学习专用软件。4.3 与上层系统对接缺料预警和产量统计的数据契约ANDON系统如果是个孤岛价值会大打折扣。资料总装车间最需要对接的是WMS的缺料信息。按常规做法WMS根据工位物料消耗速率推算缺料时间主动推送给ANDON系统。这里推荐使用Webhook或MQTT做推送而非每5分钟轮询一次接口。轮询方案有两个问题一是数据总有时差二是每次拉取全量数据性能开销大高峰期容易把WMS接口拖垮。接口报文要定义成统一的数据契约例如缺料预警的消息体长这样{ event_id: EVT-20240718-00001, event_type: material_shortage, workstation: W03, material_code: MAT-2024-0718, material_desc: A4不干胶标签, quantity_remaining: 120, expected_required_time: 2024-07-18 09:30:00, level: P1 }接收端必须做幂等处理同一event_id重复推送时不重复生成异常事件。上线前我通常会做一次故障注入测试模拟100条缺料消息同时到达验证服务不崩、不重不漏。消息体里的quantity_remaining字段很关键表示当前剩余可加工数量物料员看到这个值能判断是紧急送料还是可以等下一趟配送不用跑到现场再看一次。产量统计对接则简单很多。ANDON系统里的“首件完成”和“本工位生产完成”按钮按下的时间戳本身就是很好的实际产出数据。把这些事件按工位和班次聚合后通过HTTP POST定时推给MESMES侧按工单号关联。这个对接要在设计文档里预留开关如果MES还不成熟先把这些事件存在ANDON本地数据库等MES能力到位再启用推送。贸然在MES不完善时做双向强耦合后期维护成本会很高。5. ANDON系统避坑指南上线后最容易翻车的5个现场问题5.1 按下呼叫按钮看板没反应现象是有员工反馈“按钮按了灯不亮看板也没反应”重启服务后能好一阵但隔几天又犯。到现场排查发现IO模块在服务端的设备列表上处于离线状态网线一碰就恢复。原因基本是两条一是网线水晶头压接质量差工业环境下震动导致接触不良二是车间网络存在广播域冲突交换机上接了摄像头和办公设备流量一大就把IO模块的报文挤掉了。解决方法是做三层防护。第一服务端加IO模块心跳监控每5秒检测一次在线状态掉线立即弹告警给运维第二IO模块单独划VLAN并配置交换机的组播抑制第三施工阶段强制使用机制水晶头并要求电气工程师逐根网线用测试仪验线不能顺手用压线钳一压了事。另外按钮的LED灯要接在硬线回路上保证它亮不亮不依赖网络这样员工至少能判断按钮本身没坏排查范围能缩小一半。5.2 误报比真实异常还多员工开始无视报警现象是系统上线第二周缺料报警一天触发30多次其中一大半是员工正常取料时衣袖蹭到按钮产生的误触甚至有人用胳膊肘支着按钮休息。到第三周员工对报警声已经麻木了真正缺料时也没人处理。原因是按钮安装位置不当加上软件没有防抖机制。按钮装在料盒正上方手伸进料盒取料必然会碰到而系统在按钮状态变化的一瞬间就触发了事件。解决要软硬一起做。硬件上把普通平头按钮换成带凹陷保护圈的按钮或者改成“两个按钮同时按下才有效”的组合触发方式软件上加延时确认逻辑按钮状态必须持续保持500毫秒才判定为一次有效呼叫。同时增加同一工位同一异常类型10秒内的重复触发锁定。这个防抖参数不要拍脑袋定建议上线后观察一周的真实触发数据再微调。5.3 广播喊不到人SLA形同虚设现象是P0质量异常已经发出报警3分钟了系统在车间里循环播放语音但质量工程师没出现。班长跑去找人发现他在车间另一头的办公室里根本听不到报警声。原因是全车间共用一路功放音量开大了刺耳开小了远端听不清。而且没有做分区广播报的是3号工位的异常和这件事无关的区域也被迫听了三分钟噪音。解决方法是把广播按物理区域分区每个区域对应附近的工位群中央服务根据异常工位选择对应区域广播。P0异常同时触发就近声光报警器和该区域的定向扩音其他区域保持安静。每个响应人的手机端也要收到消息提醒不能只依赖声音。另外在上线前要模拟一次喷胶机和空压机同时运行的噪音环境实测语音播报的清晰距离而不是只在安静时段做验收。5.4 缺料数据对不上WMS说要等明天对账现象是ANDON看板显示3号工位缺料物料员跑过去一看料盒里明明还剩不少或者说WMS显示有库存但ANDON却报了缺料物料员白跑一趟。原因是对接接口采用了“每5分钟拉一次库存快照”的方式而库存数据在拉取后又被其他产线领用了ANDON看到的永远是一个滞后时点。还有一些情况是WMS的库存单位是“箱”而ANDON计算缺料用的是“张”单位没换算直接比较数据自然错乱。解决方法是把对接方式从“拉”改为“推”WMS在工位物料剩余量低于阈值时实时推送消息ANDON侧只负责接收展示。数据契约里加上物料单位和批次号物料员去查料时直接定位到库位和批次而不是看一个总库存数字。上线前用100条历史缺料记录做回放测试逐条核对ANDON收到的缺料事件与真实缺料时间是否一致偏差超过1分钟就要查原因。5.5 新系统用了三个月报表没人看现象是设计文档里做了异常次数、停线时长、响应超时率这些报表功能齐全界面也好看但车间主任很少打开班组长更是从不登录。原因是报表指标是IT按数据规范做的不是车间管理按真实诉求要的。资料总装车间是人工密集线看“停线时长”不如看“呼叫闭环率”来得直接。车间主任要的是“今天有没有异常没处理”“哪个班组响应最慢”而不是一份复杂的统计分析报告。解决方法是在设计阶段就把报表指标改成三个生产导向指标呼叫率即实际发生异常有没有被员工按出来闭环率即按出来的异常有没有在SLA内处理完复发率即同一工位同一异常类型一周内是否再次发生。每天早会投屏播报前一日的闭环率排名让班组自己看着数据说话。技术设计文档里这一节可以命名为“管理驾驶舱”而不是“统计报表”。6. 设计文档的验收清单用四步验证法在车间里证伪你的设计6.1 断网与断电演练一份看起来完美的ANDON设计不通过故障演练都只是纸面方案。我习惯在正式上线前安排一个下午做断电和断网验证。先关闭中央服务电源观察现场按钮和报警器是否按设计保持工作再切断IO模块所在交换机的电源观察恢复后事件缓存是否补发、看板能否自动重连。每做一步都记录系统状态恢复所用的时间。6.2 响应计时抽测与故障注入用脚本模拟10次P0呼叫事件验证从事件进入系统到看板刷新、广播触发、责任人收到通知的总耗时是否在SLA范围内。同时可以做一次并发测试5个工位同时按下呼叫检查看板会不会丢事件。for i in $(seq 1 10); do curl -s -X POST http://andonserver:8080/api/v1/events \ -d {event_type:quality_alarm,workstation:W03,level:P0} \ -o /dev/null -w inject $i: %{http_code}\n sleep 0.5 done这个脚本验证的是接口幂等和并发处理能力返回值不是重点重点是在服务端日志里核对10条事件是否全部落库看板是否按顺序显示了10次记录。故障注入的价值在于它证明系统在异常流量下不会悄悄丢数据。6.3 数据一致性核对与报告闭环最后一项是和WMS联动对账。取一个完整班次的缺料记录逐条核对ANDON的事件时间戳和WMS推送的缺料时间偏差超过1分钟的部分单独挑出来分析原因。同时对整个闭环做一次复盘异常有没有被按出来、有没有人在规定时间内响应、有没有处理后恢复生产。我用这套方法验收过多个项目每次都能在现场发现至少一个设计文档里没考虑到的问题。每个系统都会有不完美的角落这不可怕。验收的目的不是证明设计正确而是在投入全部资源前把风险找出来。这么多年下来我最大的教训是无论方案本身多完善一定要在正式上线前安排至少三天的试运行让班组长和操作工用真实的动作去“骂”这个系统然后逐条记录、逐条改。这个习惯帮我避开了很多翻车现场。做ANDON真正重要的不是一次通过而是每一次异常都被看见、被处理、被记住。希望帮到你。本文还有配套的精品资源点击获取