1. 项目缘起与整体设计思路1.1 为什么要在工厂里搞可视化电子看板我在制造业信息化这行摸爬滚打十来年进过汽车零部件厂、电子代工厂、精密五金厂几乎每一家做到一定规模之后都会遇到同一个问题车间里的数据是死的。生产进度靠班组长拿本子记设备状态靠人巡检良率数据要等下班后文员录入Excel第二天早上开会才能看到昨天的结果。信息滞后至少半天异常发现全靠运气。可视化电子看板要解决的就是这个信息时差。它的本质是把MES、设备PLC、传感器里的实时数据抽出来经过清洗和聚合推到大屏上滚动显示让车间里所有人抬头就能看到当前产量、良率、设备稼动率、异常工单。上海这边很多工厂的车间面积大、产线分散单块屏幕根本覆盖不过来所以实际落地时往往是多块大屏同步显示——装配区一块、注塑区一块、质检区一块、办公区一块数据源统一展示内容按区域定制。这个项目适合谁参考如果你是企业IT、自动化工程师、MES实施顾问或者正在被老板要求搞个看板出来的技术负责人这篇内容基本能覆盖你从选型到调试落地的全流程。我不讲虚的只讲我实际踩过的坑和验证过的方案。1.2 整体架构怎么搭三层结构最稳看板系统看起来简单无非是取数—传输—显示但真做起来架构设计决定了后期维护是轻松还是痛苦。我推荐三层结构数据采集层负责从MES数据库、PLC、串口设备、OPC UA服务端拿数据。这一层的关键是解耦——不要让看板程序直接去查MES的生产库因为MES库的负载本来就高你再加几十个看板轮询查询DBA会来找你麻烦。正确做法是建一个中间库或者用消息队列做缓冲。数据处理层做数据清洗、聚合、计算。比如MES里存的是每道工序的过站记录看板要显示的是今日累计产量这就需要按班次、按产线做聚合。这一层我一般用定时任务或者流处理来做频率控制在5到15秒一次太快没必要太慢看板就不活了。展示层就是大屏端。多块大屏同步的核心难点在这里如何保证所有屏幕显示的数据一致、刷新同步、不闪烁。我的方案是统一数据源统一推送所有屏幕订阅同一个数据接口由服务端主动推送而不是各屏幕自己去轮询。提示架构设计阶段一定要和车间主任、班组长聊清楚他们到底想看什么。我见过太多项目IT部门闷头做了三个月上线后发现车间想看的是当前工单还差多少件而系统显示的是本月累计良率完全对不上需求。1.3 技术选型背后的取舍逻辑选型这块我踩过不少坑说几个关键决策点。数据采集方式MES如果提供WebService或REST接口优先用接口取数稳定且不侵入。如果MES是老系统只有数据库那就走中间库同步。设备层如果支持OPC UA最好不支持就用Modbus TCP或者串口转网口模块。上海很多老厂房的设备还是RS232/RS485串口这时候串口调试助手和网口调试助手就是你的救命工具。通信协议看板推送我强烈推荐WebSocket而不是HTTP轮询。HTTP轮询的问题是每块屏幕都在独立请求10块屏幕就是10倍压力而且刷新时间不同步会出现这块屏显示100那块屏显示98的尴尬。WebSocket由服务端统一推送所有屏幕同一时刻收到同一份数据天然同步。时间同步这是最容易被忽视但最致命的点。多块大屏如果系统时间不一致显示的时间戳就会打架车间的人会质疑数据准确性。必须部署NTP服务所有看板终端、服务器、采集网关统一对时。Linux下部署NTP服务器是标准操作Windows端用系统自带的时间同步指向内网NTP服务器即可。前端框架大屏展示不需要复杂的SPA框架Vue或者原生JS配合ECharts就够了。关键是做好自适应和防内存泄漏因为看板是7x24小时运行的内存泄漏跑几天就卡死了。2. 核心细节解析与实操要点2.1 数据采集从MES到看板中间库MES系统是整个看板的数据源头。不管你的MES是商业产品还是开源的核心数据都逃不出这几类工单信息、过站记录、设备状态、质量数据。我一般会在MES数据库之外建一个独立的看板库通过定时任务做增量同步。增量同步的关键是找到增量标识。大多数MES的过站记录表都有自增ID或者时间戳字段用这两个做水位线最靠谱。我常用的策略是记录上次同步的最大ID每次只取大于这个ID的记录。代码逻辑大概是这样# 增量同步核心逻辑示意 last_id get_last_sync_id() new_records query_mes(SELECT * FROM station_log WHERE id %s ORDER BY id, last_id) if new_records: batch_insert_kanban_db(new_records) update_last_sync_id(new_records[-1].id)这里有个坑如果MES的过站记录会被修改比如返工返修后更新状态单纯靠ID增量就会漏掉更新。汽车水冷板这类产品的MES返工返修模块尤其要注意返工记录往往是插入新记录更新原记录的组合操作。我的做法是对关键表加一个update_time字段的增量窗口每次同步最近15分钟内被修改过的记录做一次幂等写入。注意同步频率不要设得太激进。我见过有人设成1秒一次结果MES数据库CPU直接飙到90%。一般5到10秒一次足够看板使用车间又不是炒股不需要毫秒级实时。2.2 多屏同步的核心机制服务端推送多块大屏同步显示说起来简单做起来有几个层次的问题要解决。第一层是数据一致性。所有屏幕必须拿到同一份数据。如果每块屏幕各自去查数据库由于查询时间点不同结果必然有差异。解决方案是服务端定时取一次数据缓存起来然后广播给所有连接的客户端。第二层是刷新同步。理想状态下所有屏幕应该在同一时刻刷新。WebSocket广播天然满足这一点服务端一次推送所有客户端同时收到。但要注意客户端的渲染时间可能有微小差异对于数字滚动动画这类效果可以在推送消息里带一个生效时间戳客户端根据这个时间戳对齐动画起始点。第三层是断线重连。车间网络环境复杂网线被叉车压断、交换机重启都是常事。客户端必须实现自动重连重连后要能补齐断线期间的数据。我的做法是服务端维护一个最近N条消息的环形缓冲区客户端重连时带上最后收到的消息序号服务端把缺失的消息补发过去。// 客户端WebSocket重连与补数据示意 let lastSeq 0; function connect() { const ws new WebSocket(ws://kanban-server:8080/ws); ws.onopen () ws.send(JSON.stringify({type: resume, seq: lastSeq})); ws.onmessage (e) { const msg JSON.parse(e.data); lastSeq msg.seq; render(msg.data); }; ws.onclose () setTimeout(connect, 3000); }2.3 时间同步NTP部署不能省多块大屏时间不一致是看板项目里最隐蔽的bug。表面上看每块屏都在正常显示但细心的车间主任会发现这块屏的产量数字比那块屏晚了几秒进而怀疑整个系统的可靠性。NTP部署分两步。第一步是在内网找一台服务器做NTP ServerLinux下用chrony或者ntpd都行。配置文件里指定上游时间源如果工厂内网完全隔离可以用本地时钟做基准但精度会差一些。第二步是所有看板终端、采集网关、数据库服务器都指向这台内网NTP Server。# Linux下chrony服务端配置示意 # /etc/chrony.conf server ntp.aliyun.com iburst allow 192.168.1.0/24 local stratum 10Windows终端同步很简单命令行执行w32tm /config /manualpeerlist:192.168.1.100 /syncfromflags:manual /update然后重启时间服务即可。看板程序启动时最好也做一次时间校验如果本地时间和服务器偏差超过阈值在界面上给出警告。提示华为云、阿里云都有公网NTP服务器地址但工厂内网通常不允许访问外网。所以内网NTP Server是必须的不要指望每台设备自己去连公网。3. 实操过程与核心环节实现3.1 环境准备与基础服务搭建正式动手之前先把环境理清楚。我以一台典型的看板服务器为例配置不用太高4核8G足够跑几十块屏幕的数据推送。操作系统我习惯用Ubuntu Server 22.04 LTS稳定且社区支持好。基础服务包括MySQL或者PostgreSQL做看板中间库、Redis做数据缓存和消息队列、Nginx做前端静态资源服务、Node.js或者Java做WebSocket推送服务。数据库建表这块看板中间库不需要太复杂的范式设计反而要适当冗余因为看板查询都是读多写少查询性能优先。我一般会建几张核心表产线实时状态表、工单进度表、质量统计表、设备稼动表。每张表都带一个update_time字段方便前端做数据新鲜度判断。Redis在这里的角色很关键。看板服务每次从数据库取完数据后写入Redis并设置较短的过期时间。WebSocket推送服务直接从Redis读数据广播避免频繁查库。同时Redis的发布订阅机制可以用来做多实例部署时的消息分发。3.2 数据采集程序开发与调试采集程序我一般用Python写因为对接各种数据源方便MES的WebService、数据库、OPC UA、Modbus都有成熟的库。对接MES WebService时先用网口调试助手确认接口地址和端口通不通再用Postman或者curl测试接口返回。我遇到过MES接口返回的JSON里时间字段是2024-01-15T08:30:0008:00这种带时区的格式而看板需要的是本地时间这里要做转换否则显示会差8小时。对接PLC和串口设备时串口调试助手是必备工具。先用它确认波特率、数据位、停止位、校验位这些参数对不对能收到正确数据了再写代码。我踩过的坑是有些设备的串口参数文档写的是9600-8-N-1实际却是9600-7-E-1用调试助手一试就露馅了。# Modbus TCP采集示意 from pymodbus.client import ModbusTcpClient client ModbusTcpClient(192.168.1.50, port502) result client.read_holding_registers(address100, count10, slave1) if not result.isError(): process_data(result.registers)采集程序一定要加日志而且要分级别。正常采集记DEBUG数据异常记WARN连接失败记ERROR。日志按天切割保留30天。我见过采集程序跑了一个月没人管某天突然发现数据不对结果日志早就被覆盖了排查无从下手。3.3 大屏端页面开发与多屏适配大屏端页面开发有几个硬性要求自适应分辨率、防烧屏、低内存占用。自适应这块我推荐用rem或者vw/vh做布局配合CSS的transform: scale()做整体缩放。设计稿按1920x1080做实际屏幕可能是4K或者拼接屏用scale缩放最省事。但要注意字体渲染在缩放后可能模糊关键数字可以用SVG或者canvas绘制。防烧屏是针对LCD大屏的。如果某个区域长期显示固定内容几个月后就会留下残影。我的做法是让看板内容每隔几分钟做一次微小的位置偏移或者用半透明遮罩做缓慢移动。OLED屏幕更要注意但工厂一般用LCD问题没那么严重。多屏适配的关键是配置化。不要为每块屏幕写一套代码而是做一个配置文件指定每块屏幕显示哪些模块、数据源是什么、刷新频率多少。屏幕通过URL参数或者设备ID来加载对应的配置。// 屏幕配置示例 const screenConfig { screen-assembly-01: { modules: [output, quality, andon], refreshInterval: 5000, lineId: L01 }, screen-injection-02: { modules: [output, equipment, oee], refreshInterval: 10000, lineId: L02 } };3.4 联调与上线从单屏到多屏同步验证联调阶段我建议分三步走。第一步单屏调试确认数据准确、刷新正常、样式没问题。第二步双屏对比把两块屏放在一起观察同一时刻显示的数据是否完全一致。第三步全屏压测所有屏幕同时上线观察服务端CPU、内存、网络带宽。多屏同步验证有个简单方法在数据里加一个递增的序号或者时间戳所有屏幕显示这个序号。如果任意时刻所有屏幕的序号都相同说明同步没问题。如果出现某块屏序号落后那就是该屏幕的网络或者渲染有问题。上线后要观察至少一周。重点看几个指标数据延迟从MES产生记录到看板显示的时间差、推送成功率、客户端内存增长曲线。数据延迟一般控制在10秒以内车间就能接受推送成功率要在99.9%以上客户端内存如果持续增长说明有泄漏必须排查。4. 常见问题与排查技巧实录4.1 数据不同步问题排查数据不同步是看板项目最高频的问题表现是不同屏幕显示的数字对不上。排查思路从后往前推先看服务端推送是否正常。在服务端日志里查每次广播的消息序号如果序号连续且所有客户端都收到了那问题在客户端渲染。如果服务端推送就有问题查数据采集和缓存环节。再看客户端。打开浏览器的开发者工具看WebSocket连接状态和收到的消息。如果某块屏幕的WebSocket频繁断开重连那就是网络问题。车间里网线走线要避开变频器、大功率电机这些干扰源实在避不开就用屏蔽网线。还有一个隐蔽原因是浏览器缓存。看板页面更新后某些屏幕加载的还是旧版JS导致渲染逻辑不一致。解决办法是在静态资源URL上加版本号或者时间戳强制刷新缓存。现象可能原因排查方法解决措施个别屏幕数据滞后该屏幕网络延迟高ping测试、查看WebSocket重连日志检查网线、更换交换机端口所有屏幕数据都不刷新采集程序挂了查看采集程序进程和日志重启采集程序加守护进程数字跳动不一致客户端渲染时间差异对比消息序号和渲染时间推送消息带生效时间戳时间显示差几秒NTP未同步各终端执行时间查询命令统一指向内网NTP服务器4.2 网络与连接稳定性问题车间网络环境比办公室恶劣得多粉尘、震动、电磁干扰都会影响网络稳定性。我总结了几条经验交换机要选工业级的普通商用交换机在车间里寿命短。网线用超五类以上屏蔽线水晶头压接要规范我见过因为水晶头没压好导致间歇性断网的案例排查了一整天。如果看板终端距离交换机超过100米普通网线就不行了要用光纤收发器。上海有些老厂房跨度大这个问题很常见。无线方案我不推荐用于看板WiFi在车间里干扰太严重而且漫游切换时会断连。如果实在要拉不了网线用电力猫也比WiFi稳但电力猫受车间用电设备影响也大只能作为临时方案。4.3 大屏显示异常与性能优化大屏显示异常常见的有花屏、闪烁、分辨率不对、颜色偏差。花屏和闪烁多半是HDMI线或者显卡问题。HDMI线不要用太便宜的长距离传输要用带信号放大的。显卡驱动要装官方版Windows自动更新的驱动有时候会有兼容问题。分辨率不对是EDID识别问题。有些拼接屏或者工业显示器EDID信息不规范电脑识别不到正确分辨率。解决办法是用EDID模拟器或者手动在显卡驱动里添加自定义分辨率。性能优化方面看板页面要避免频繁的DOM操作。数据更新时只更新变化的数字节点不要整个页面重绘。ECharts图表要合理使用setOption的notMerge参数避免内存泄漏。我一般会加一个定时器每隔几小时自动刷新一次页面释放累积的内存。提示看板终端建议用瘦客户端或者迷你主机不要用普通办公电脑。瘦客户端功耗低、无风扇、适合7x24运行而且系统可以做成只读模式防止车间人员误操作。4.4 与MES系统的对接避坑和MES对接是最容易扯皮的环节。MES厂商往往不愿意开放数据库接口文档也写得含糊。我的经验是提前和MES厂商确认接口的并发限制和调用频率限制。有些MES接口有防刷机制调用太频繁会被封IP。如果MES不提供接口只能读数据库那一定要和MES厂商书面确认读库不会影响主系统性能并且只读从库不要读主库。MES的数据字典要拿到特别是状态码的含义。比如工单状态1代表生产中还是待生产不同MES定义不一样。我见过因为状态码理解错误看板上把已完工的工单显示成生产中车间主任直接打电话来骂人。返工返修的数据要特别注意。汽车水冷板这类产品的返工流程复杂一个产品可能经过多次返工。看板显示产量时返工品算不算产量返工后重新过站算不算重复计数这些业务规则必须在开发前和品质、生产部门确认清楚写进需求文档。5. 上线后的运维与持续优化5.1 日常巡检与监控看板系统上线不是终点而是运维的起点。我一般会配一套简单的监控服务端用Prometheus加Grafana监控CPU、内存、WebSocket连接数采集程序用心跳机制超过一定时间没心跳就告警看板终端用定时截图对比如果画面长时间不变就说明可能卡死了。巡检频率不用太高每天上班前看一眼监控面板就行。但要有告警机制服务挂了要能主动通知到人。通知方式用企业微信或者钉钉机器人最方便车间IT人员手机就能收到。5.2 数据准确性校验看板数据不准比没有看板更糟糕。车间一旦发现数据不对就会彻底不信任这个系统。所以数据校验机制必须要有。我的做法是每天做一次对账看板统计的当日产量和MES报表的当日产量做比对差异超过阈值就告警。差异原因可能是采集漏数据、聚合逻辑错误、或者MES本身数据有问题。对账报告自动生成发给生产主管确认。另外看板上要显示数据更新时间。如果数据超过一定时间没更新数字变灰或者加个警示图标让车间知道当前数据不是最新的。5.3 后续功能扩展方向看板跑稳之后可以逐步扩展功能。常见的扩展方向有增加安灯呼叫功能车间发现问题可以直接在看板上呼叫维修增加设备点检功能看板显示点检计划和完成情况增加能耗监控把电表、气表数据接进来。再进一步可以和MES的排产模块联动看板显示当前工单的预计完成时间根据实际进度动态调整。这个就需要和MES做更深的集成开发量比较大但价值也高。我个人在实际操作中的体会是看板项目成功的关键不在于技术多先进而在于是否真正解决了车间的一线问题。我见过用最简单的HTML页面做的看板因为数据准、刷新快、界面清爽车间用得很满意也见过用最新框架做的花哨看板因为数据延迟大、经常卡顿上线三个月就被弃用。技术是为业务服务的把数据搞准、把稳定性做好比什么都重要。最后分享一个小技巧看板上线初期每天去车间转一圈听听工人和班组长的反馈。他们提出的往往是最真实的需求比如这个数字太小了看不清、这个颜色在灯光下反光这些细节改起来不难但能极大提升使用体验。
