上个季度我在上海金山那边一家汽车零部件工厂做了一套可视化电子看板项目前后从需求对接到验收花了大概三周。项目本身不复杂但调试过程比预想的要折腾得多尤其是多块大屏同步显示这块牵扯到数据链路、网络环境、硬件兼容、前端渲染好几个层面踩了不少坑。今天把整个落地过程整理出来从架构设计到调试细节再到我实际遇到的坑和排查方法一次性说清楚给正在做或者准备做同类项目的朋友一个参考。这套系统的核心诉求其实就三句话把车间里的生产数据、设备状态、能耗数据实时摆到大屏上让管理人员和一线员工都能一眼看懂同时做到多块大屏显示内容一致、刷新同步不能出现一块屏显示产量1000、旁边一块屏还是980的情况最后要保证长期稳定运行不能动不动就卡死、花屏、断线。最终交付了什么形态呢厂里一共装了四块屏三个生产车间各一块中控室一块。每块屏配一台迷你主机通过网线接到工厂局域网浏览器全屏显示可视化页面。数据源主要是三块设备PLC通过Modbus TCP协议采集、MES系统的MySQL数据库、车间的智能电表。采集服务统一跑在一台服务器上把数据汇总到Redis和消息队列再推送给四块屏的前端页面做渲染。后面所有章节都会围绕这套架构展开。1. 项目背景与需求拆解1.1 工厂为什么要上可视化电子看板这个厂之前的模式估计很多制造业朋友都熟悉车间主任靠对讲机问产量班组长用白板手写当班数据每天下班后由统计员去各工位抄表、做Excel报表第二天早会再汇报。流程本身不能说错但有几个致命问题。第一是实时性差。白板上的数据永远滞后至少几个小时而且抄写过程容易出错经常出现账实不符。第二是管理层决策靠“猜”。老板想看看今天哪个工位效率低、哪台设备OEE不达标得等第二天的报表才能知道发现问题的时候往往已经过去了半天甚至一天损失已经造成了。第三是车间与车间之间信息割裂。一车间和三车间之间互相不知道对方的进度导致上下游工序衔接只能靠电话确认。可视化电子看板解决的正是这三个痛点数据实时上屏、异常及时报警、全局信息透明。产线每完成一件产品PLC计数加一看板上的数字几乎同步更新设备报警信号触发看板上马上弹红色告警同时推送到中控室。这种体验上的差距用过的人基本都回不去了。1.2 多块大屏同步显示的核心需求拆解项目初始需求描述很简单——“四个屏幕显示一样的内容”但真做起来远没有这么简单。“一样的内容”背后至少可以拆出三个层面数据内容同步。所有屏幕必须展示来自同一份数据源不能出现每块屏各自跟数据库交互、各自读一份数据的情况否则几乎必然产生不一致。时间轴同步。四块屏的显示内容不仅页面结构要一致曲线图、柱状图这些动态元素的刷新时刻也要尽量对齐。如果A屏的产量趋势图已经画到10:03这一分钟B屏还在10:02那看起来就是明显的“不同步”。交互状态同步。比如中控室的操作员在大屏上点开了一个设备的实时参数弹窗或者切换了车间页面现场的大屏也要做出同样的响应。换句话说这不只是数据同步还包括页面状态的分发。搞清楚这三个层面之后后续的架构选型和调试方向就清晰了很多。需要强调一点需求拆解阶段多做一点功夫后面调试阶段就能少走很多弯路。我当时专门列了一个需求清单表格逐条跟工厂的信息化负责人和车间主管确认避免后期返工。2. 系统架构与技术选型2.1 整体数据链路设计这套系统的完整数据链路是传感器/PLC/电表 → 采集服务 → Redis 消息队列 → WebSocket → 前端大屏页面。每一环都有自己的角色不能混为一谈。工业设备层是数据的生产者。PLC负责输出设备状态、产量计数、报警信息智能电表输出电压、电流、功率、电耗数据。MES数据库里则有订单进度、工单信息、质量检验结果等经营性数据。采集服务是连接设备和上层系统之间的桥梁。它既要通过Modbus TCP协议跟PLC通信也要定时查询MES数据库增量数据还要通过串口或Modbus RTU读取电表数据。采集完成后把规范化处理过的数据写入Redis同时往消息队列里推一条实时事件通知。Redis在这里起到的是“状态仓库”的作用。最新产量、当前设备状态、当天的能耗累计值都放在缓存里前端无论什么时候连接上来都能立刻拿到一份最新快照。消息队列则承担“事件广播”的角色任何数据变化都变成一条消息推送出去四块屏同时收到各自更新对应的UI模块。前端展示层跑的是Vue 3 ECharts WebSocket浏览器全屏模式渲染。选择Vue是考虑到它的响应式数据模型很适合这种实时数据驱动的页面开发ECharts在工业可视化领域的生态和文档成熟度就不用多说了基本是首选。之所以设计成“数据共享、统一分发”而不是“各自取数”是从源头上杜绝数据不一致的问题。四块屏永远从同一份Redis快照和同一条事件流里取数数据自然就一致了。2.2 大屏硬件与主机选型要点大屏本身我这边不直接供货但需要配合现场的硬件方案做适配所以这块也要有些基本认知。工厂现场这类场景最常见的是两种方案LCD拼接屏和LED小间距屏。车间里灰尘大、光照强、有的区域还有震动这都得考虑到。LCD拼接屏的好处是分辨率高、近距离观看细腻、成本相对可控LED小间距屏则是亮度高、无拼缝、寿命长、适合远距离观看但价格明显更贵。这次项目的三个车间选的都是3×3的LCD拼接屏中控室用的是1.8小间距LED屏因为中控室离屏距离近LED的显示细腻度更好而且领导看方案汇报时视觉冲击力强。驱动大屏的主机建议用迷你工控机要求CPU四核以上、内存8GB以上、固态硬盘256GB起步、带千兆网口。这里有一个很多人忽略的点硬解码能力。大屏页面里跑了很多ECharts动画和地图特效如果CPU太弱或者集显性能不够帧率上不去画面会明显卡顿看起来就像“同步不流畅”。所以预算允许的话尽量选带Intel Iris Xe级别集显或以上性能的主机。2.3 数据采集与中间件选型Modbus TCP是目前工业设备通信最常见的协议之一但“常见”不代表“省心”。实际碰到的麻烦常常是PLC寄存器地址表跟实际点对不上或者数据类型对齐错误。比如有些老设备用32位浮点存储产量但配置的时候按16位整数读了读出来的数字就会翻车。这里需要用到Modbus Poll这类工具通过读写测试逐个确认点位再跟设备厂家提供的点表做交叉验证。MES数据库直接读取这块我的做法是建一个独立的查询账号只开放必要的视图或表的只读权限并且写查询SQL时尽量带时间戳增量条件避免每次全表扫描影响MES本身的业务性能。Redis选择7.x版本配置比较简单主要注意关闭持久化或者设置合理的RDB/AOF策略。因为这里Redis本质上是一个轻量级状态仓库数据都是从采集服务汇总来的即使挂了只需要让前端页面在短暂断连后重新拉取快照即可恢复过度追求持久化反而拖累性能。消息队列最初考虑过RabbitMQ后来实际用的是EMQXMQTT Broker原因也很实在MQTT天生支持发布订阅模式而且对弱网环境的容忍度比AMQP好。前端直接通过MQTT over WebSocket订阅主题链路最短、调起来最方便。生产数据、报警事件、能耗数据分别走不同的Topic前端根据主题去更新不同的UI模块。3. 多屏同步机制的实现细节3.1 时间同步一切同步的基础四块屏显示的内容要对齐第一步是四台主机的系统时间必须一致。时间都不统一的话谈何同步。这里用的是NTP内网时间同步方案。在采集服务器上搭建NTP服务四台大屏主机开机自启一个脚本定期执行ntpdate命令去同步服务器时间同时配置了计划任务每5分钟校时一次。Windows系统下也可以用w32tm工具完成同样的工作。这个坑我在项目里真真切切踩过一次。刚开始调试的时候有一块屏的曲线图总是比其他屏慢几十秒到一分钟怎么都找不到原因后来中控室的人说了一句“那台电脑的时钟好像不太准”我手动对了一下果然系统时间慢了两分钟。时间对不齐后面所有跟时间轴相关的图表全都会错位排查之前先把时间同步做扎实。3.2 数据同步统一数据源做分发数据同步这一步是系统设计的核心。我前面强调过架构上就避免了各屏幕单独拉取数据的问题。实现上具体分两层第一层是采集服务主动推送。采集服务从PLC读取到新的产量数据后先写入Redis的Key比如production:line1:total再往MQTT的data/production主题发布一条JSON消息里面包含产线编号、当前总产量、当班产量、时间戳等字段。第二层是前端订阅实时更新。所有大屏页面启动后同时连接MQTT订阅对应主题。消息一到达Vue组件直接更新dataECharts图表通过setOption增量更新。由于四块屏接收到的消息是同一份广播数据源完全一致所以在正常网络情况下数据层面的显示差异基本可以忽略。这里还要考虑到一个边界场景某块屏因为在重启或者网络闪断错过了中间的几条消息。怎么补救我的处理是前端在MQTT重连成功之后立即从Redis通过HTTP接口拉取一次全量最新快照数据把关键指标一次性补齐再回到实时消息驱动模式这样就做到了“断点续传”的效果。3.3 页面状态与交互同步从被动到主动四块屏不只是被动显示数据还需要主动响应操作者的交互指令。例如中控室的人双击某台设备的OEE数据打开详情弹窗车间大屏也要自动打开同样的弹窗——这就是页面状态的同步。实现方式我用的是“指令级同步”。每类操作定义一个指令对象如{type:OPEN_DETAIL,deviceId:MC-003,timestamp:...}通过MQTT另一个主题control/screen广播出去。每块屏上运行一个指令监听器收到指令后在自己的页面上下文中执行对应的操作。这套机制的好处是松耦合。大屏端不需要知道中控室究竟做了哪些操作只需要关心“这个指令当前的页面状态能不能执行”。如果某块屏恰好处于告警弹窗状态与“打开设备详情”指令冲突了那它可以选择忽略或者排队执行灵活性更高。需要提醒的是在写这个机制的时候指令必须带上唯一的messageId前端要做幂等处理防止同一条指令因为网络重发而被重复执行两次。这个细节我是在一次测试中偶然发现的当时中控室点了一下切换页面车间大屏居然连续弹了两次相同页面排查半天才发现是MQTT的重试机制引起的。3.4 刷新策略与心跳保活机制多屏画面从观感上做到“同步”还有一个隐性问题容易被忽视——图表动画的节奏对齐。ECharts里的曲线移动动画、柱状图增长动画如果每块屏的执行节奏不一样即使数据一致看起来也像“各跳各的”。解决办法是所有图表动画都绑定一个全局时钟变量前端每秒更新一次时钟数据所有需要触发的动画都从这个全局时钟读取时间基准而不是各自去获取系统时间。这样只要四块屏的系统时间基本一致动画节奏就是对齐的。心跳保活机制也不能省。前端每5秒向采集服务发一个心跳包服务端负责记录每个屏幕的在线状态。中控室的大屏上有一个机房的拓扑小图能直观显示四块屏当前是否在线。一旦某块屏心跳超时中控室立刻能发现不用等到车间班组打电话报故障。4. 实际调试过程与关键环节实录4.1 现场网络环境的准备与检查网络环境是整个项目的“地基”地基没打好后面全是白做。我到了现场的第一件事不是接大屏而是画了一张网络拓扑图把每台设备的IP地址、网关、子网掩码、VLAN都规划好。工厂局域网经常有各种广播风暴和IP冲突问题尤其是车间里的设备五花八门。我个人的习惯是大屏主机和大屏相关的服务器单独划一个VLAN避免和办公网、生产控制网混在一起。所有主机IP固定分配不用DHCP免得哪天断电重启IP变了找不到设备。网络调通之后的检查项包括从大屏主机到采集服务器的延迟目标值5ms、丢包率目标值0%、是否能够稳定通过TCP连接访问Redis和MQTT端口。这里推荐用网口调试助手之类的工具做TCP/UDP测试简单直接。4.2 PLC点位对接与Modbus调试对接PLC的过程是整个项目里我花时间最多的部分。厂里的PLC主要有两个品牌一部分是西门子S7系列另一部分是比较老的三菱FX系列。三菱这台还是走串口转网口的老方案协议用的是Modbus RTU over TCP调试起来比较费劲。工具方面我推荐用Modbus Poll做点位测试。它可以把一个或多个寄存器地址的实时值拉出来以数值或者图表方式展示非常直观。我拿点表逐项核对每个寄存器的地址、数据类型、读写属性再用Modbus Poll验证一遍确认采集服务读上来的数据跟现场仪表一致。有个具体的坑值得说一说三菱FX系列的老PLC里有些地址需要做地址偏移比如D100在Modbus里的实际地址是400101但转换规则跟标准的Modbus地址映射不一样容易对不上。我当时是把点表里的每一个地址都用Modbus Poll手动测一遍花了大半天时间才全部确认虽然累但值得。4.3 Redis与MQTT的配置及参数调优Redis的配置相对简单重点关注几个参数maxmemory设置成2GB左右防止数据积压占用过多系统内存maxmemory-policy设置为allkeys-lru做简单的缓存淘汰禁用或者限制CONFIG命令避免安全风险。MQTT侧的调优重点在会话保持。如果现场网络不稳定要设置合理的session expiry interval和keepalive参数。我实际设置的keepalive是30秒过期时间120秒在保证断线检测及时的同时又不会因为网络抖动导致设备频繁掉线。用EMQX的话它的Dashboard面板本身就支持查看连接数、消息速率、订阅关系调起来很直观。这里顺带一提Redis可视化管理工具和EMQX的Dashboard对于排查“数据到底有没有到”这类问题非常有用别只看前端页面盲猜。4.4 前端大屏页面的联调与视觉调优页面联调阶段的重点是前端与MQTT数据的配合、图表加载性能、以及在大分辨率屏上的显示效果。四块屏中有两块的物理分辨率达到了3840×2160页面设计稿如果不能自适应就会出现字体过小或者图表拉伸变形的问题。我的经验是前端用rem vw/vh的组合方案根字号根据屏幕实际宽度动态计算而不是用固定的px值。字号、间距、图表尺寸都用相对单位保证在不同分辨率下成比例缩放。图标和辅助纹理尽量用SVG避免位图在大屏上发虚。ECharts的初始化技巧也有讲究尤其在数据高频更新的场景下避免频繁dispose和重新init图表实例否则GPU和CPU开销很高页面容易变得卡顿。正确做法是初始化一次后面更新数据时用setOption增量更新同时设置notMerge: true来避免旧数据残留造成的视觉错乱。还有个很影响观感的细节ECharts默认的animation动画在大屏高频更新时会产生“过渡卡一卡”的现象。这种场景我建议把animationDurationUpdate调短一点比如300毫秒或者直接关闭不需要的动态效果保持更新干脆利落看起来更“即时”。4.5 四屏一致性的整体验收调试所有部分单独都通了之后最后一步就是把四块屏摆在一起做整体验收。步骤是这样首先同步四台主机的系统时间然后同时刷新四块屏的页面让它们处于同一个初始状态接着人为制造几个事件比如在MES里更新一条工单数据、触发一个报警、切换一次页面观察四块屏的反应是否一致。验收过程中我录了好几次视频把四块屏放在同一个画面里用慢动作逐帧对比曲线变化的时间点。正常情况四块屏的响应差不应该超过一秒我实测下来数据更新的时间差基本在200毫秒以内符合预期。如果哪块屏慢了或者数据不一致马上钉到对应的主机上排查网络或者订阅关系。还有一个比较隐蔽的验收项断电重启后的自恢复能力。工厂的车间供电并不是绝对稳定突然断电再来电的情况并不罕见。四台主机BIOS里设置成通电自启采集服务器上加了开机自启服务前端页面设置开机后自动打开浏览器进入全屏模式。我在交付前专门做了一次断电恢复测试整体恢复时间大约在3分钟以内。5. 常见问题与排查技巧实录5.1 大屏之间数据差异典型表现是两块屏刷新后显示的总产量差了几个数或者某一项的百分比跟其他屏对不上。针对这种问题排查路径一般是先看MQTT消息是不是每一块屏都收到再检查Redis里的最新值再逐块屏确认浏览器的订阅状态。我遇到的一次比较典型的情况是其中一块屏因为浏览器缓存的原因加载了旧版本的JavaScript代码导致对消息的处理逻辑比别的屏幕老了一版。处理方法是每次发版后在浏览器设置里关闭缓存或者使用带版本号的静态资源URL比如app.js?v20241016。5.2 屏幕显示卡顿或渲染延迟大屏页面运行久了偶尔会出现鼠标转圈、图表半天不动的情况。排查思路是打开浏览器的开发者工具看Performance面板定位CPU占用和内存是否持续高位。如果发现内存不断上涨大多是ECharts实例没有被正确销毁或者是WebSocket消息处理链路中有未释放的引用。我的处理原则是组件卸载时一定要做dispose图表实例关页面的时候还要主动断开MQTT连接释放资源。同时如果单页面上图表数量过多可以考虑做懒加载只渲染当前视口可见范围内的图表。后面实测同样的页面做了释放处理后内存占用明显稳定长时间挂机也不涨。5.3 指令同步失败或状态不一致这个问题的根源往往不是技术而是设计层面的“指令语义冲突”。比如中控室发了一个“关闭设备详情弹窗”的指令但车间大屏当前本来就处于没有弹窗的状态处理逻辑报错或者直接忽略那么后面再发的其他指令就可能被堵住。我自己的改进方式是所有指令在同一块屏上允许同时存在多个状态栈而不是单一全局页面状态。每个指令带优先级和执行条件不能执行的指令直接丢弃并打一条日志到中控室。中控室增加“全局归位”按钮一键把所有屏幕恢复到默认首页状态用于快速复位。5.4 网络闪断引起的离线滞后工厂车间的网络环境相对复杂偶尔有交换机重启、网线松动的情况导致某块屏断线。MQTT本身有断线重连机制但从前端页面的感知上可能会出现一段时间的数据空白或者显示“连接中”的提示。我给前端加了三重保障断线后立即切换成“离线模式”显示用页面上的黄色横幅提示重连成功后自动请求一次Redis全量快照补齐漏掉的数据连续重连失败5次以上时自动刷新整个页面彻底重建浏览器与WebSocket的连接。5.5 分辨率适配和字体模糊问题前面提过用rem方案但实测发现还有一个相对隐蔽的问题Windows系统在4K分辨率下默认的DPI缩放比例是150%甚至更高这会导致浏览器拿到的窗口尺寸偏小页面布局错乱。我的处理方式是在主机上把浏览器单独设置成“高DPI设置时替代缩放行为”为“应用程序”且页面内部通过JavaScript读取window.devicePixelRatio去做二次适配。字体模糊的问题主要体现在细体字的渲染上。大屏的字体尽量用思源黑体这类为屏幕设计的中文字体字号不要小于28px保证远距离观看时也清晰。抗锯齿在画布类元素上也算常见问题ECharts方面可以开启devicePixelRatio: 2的配置来提升清晰度。6. 收尾建议与经验心得这套项目从需求梳理到最终验收我最大的体会是可视化电子看板项目里技术方案只占不到一半的工作量另一半几乎都花在了需求澄清、现场环境适配和排障上。客户描述“看起来同步”、实际要的是数据一致和操作一致现场说“网络很好”实际一测丢包率2%还带IP冲突。网络拓扑、点表核对、定时校时、断线告警这些事情听起来不如“做一个炫酷的可视化大屏”有冲击力但恰恰是决定系统能不能在车间稳定运行的关键。如果正在准备做类似项目我建议把时间分配为全局统筹考虑把三分之一的时间留给现场调研和点表核对三分之一的时间留给联调和排障剩下三分之一的时间才留给你真正去写页面。在工厂现场调试的时候也有一点要提醒备好一把串口转网口工具和一台预装了调试软件、抓包工具、Modbus Poll的笔记本关键时候能帮你省下大量的排查时间。回到项目本身这套看板跑稳定之后厂里还提了后续扩展方向把能耗看板跟产线排产联动起来做预测分析和把看板数据同步到手机端做远程监控。数据链路和同步机制修改起来比较方便换条HTTP接口就能对接外部系统整体架构扩展空间还是有富余的。以后如果真做了手机端和新功能我再来补充一篇后续的实践记录。