工厂电子看板多屏数据不同步？从数据链路到调试避坑指南

工厂里装了几块可视化电子看板本来想着大屏一挂车间数据一目了然。结果真到交付那天现场几块大屏各显示各的一块显示“今日产量 3200”另一块还是“3100”过一会儿又变了再过一会儿两块一起闪。车间主任站在中间左看右看问你是不是系统坏了。这种场景我遇到了不下十次说白了不是屏幕坏了而是多块大屏的数据同步出了问题。这篇东西就是写给做工厂可视化项目、电子看板实施和维护的工程师看的从数据链路开始拆讲清楚多屏不同步的调试方法、常见坑和从源头避免问题的手段。也适合准备上电子看板项目的生产主管阅读看完至少能知道该盯哪些技术点不会被供应商几句话搪塞过去。1. 大屏数据不同步的根源别急着调屏幕先看数据链路先给一个结论工厂可视化电子看板本质上是一个“数据采集-计算-呈现”的闭环。数据从PLC、MES、ERP、传感器或者手工录入的Excel来经过中间服务处理再到前端大屏渲染。大多数情况下多块大屏数据不同步问题不出在“屏”上而是出在中间任何一个环节。我调试过不少项目发现不少同事一看到多屏不一致就跑去大屏前面调参数、扣缓存其实很多时候冤枉了屏幕。真正要做的是把整条数据链路走一遍找到那个“最先说谎”的节点。1.1 数据链路模型先搞清楚数据从哪来到哪去所有工厂可视化项目都可以把数据链路粗略分成三层。第一层是数据源层。车间里的PLC控制器、传感器网关、MES数据库、ERP接口甚至人工上报的Excel都属于这一层。第二层是数据处理层通常是一台服务器或者云平台上的后台服务负责把原始数据清洗、聚合、按规则计算再封装成前端友好的JSON或者其他格式。第三层是展示层就是那些挂在车间里的LED屏、办公室的液晶拼接屏、工位上的安卓一体机或者PC端的浏览器看板。多屏不同步的问题几乎都发生在第二层和第三层之间的“数据分发”环节。常见的早期设计是每块屏定时去后台拉数据后台再查一次数据库。因为每块屏请求发起的时间不同、网络延迟不同、数据库查询耗时有波动所以它们拿到同一份数据的时间点天然就不一样。只要一块屏慢了两三秒现场看就是“不同步”。这里要理解一个底层概念绝对同步在分布式系统里很难做到我们追求的其实是“最终一致”。对车间看板来说只要所有屏幕在可接受的时间窗口内比如3秒内显示同一份数据基本就满足生产要求。如果你能做到所有屏幕同一瞬间刷新那是理想状态但这往往需要额外的技术手段比如统一发送刷新指令、用精确同步协议等。我一般会在项目启动时就跟客户对齐这个“可接受延迟窗口”。有的客户说“必须一秒都不差”那就要上硬同步方案成本高很多有的客户说“10秒内一致就行”那就用常规方案省时省力。工厂里的大部分指标比如产量、OEE、能耗3到5秒的延迟完全可以接受。如果有人说“看板上跳动的数字必须和实际一模一样”你就要解释清楚数据采集本身也有延迟不是纯显示问题。1.2 三种常见同步模式轮询、推送、共享状态多屏需要共享数据常见的技术方案有三种。理解它们各自的脾气排查起来心里才有底。模式机制优点缺点适用场景前端定时轮询每块大屏每隔几秒请求后台接口拿到最新数据渲染实现简单调试方便不需要维护长连接时间与网络开销浪费多屏启动时间不同会自然错开刷新时刻屏数量少、实时性要求不高、数据量不大的场景后端推送WebSocket / MQTT服务器在数据变化时主动把更新推送到所有订阅端实时性好所有订阅端几乎同时收到数据需要维护长连接断线重连、处理重复消息都要专门设计多屏实时显示、数据变化频繁、对同步性要求较高的场景共享状态Redis发布订阅 / 分布式缓存数据更新后写入Redis等中间件并发布一个事件所有前端监听这个事件后拉取最新数据数据一致性好适合多端多屏扩展性高依赖额外中间件运维复杂度上升需要关注网络分区问题大规模看板集群、跨车间跨区域大屏联动重点说一说“为什么轮询会不同步”。假设两块屏都是10秒轮询一次A屏8点整打开页面B屏8点零1秒打开页面那么A屏下次刷新是在8点整之后的第10秒B屏是在8点零1秒之后的第10秒两个刷新时刻永远差1秒。更糟的是如果后台接口响应时间不稳定A屏这次请求用了800毫秒B屏用了300毫秒那显示新数据的时刻差距会更大。如果恰好有人在8点06秒去看两块屏一块刚刷新完显示新数据另一块还要熬4秒才刷新这就是典型的“不同步”。那有人会说把轮询间隔改成1秒不就好了确实可以缩短时间差但会带来更高的接口压力和带宽消耗。车间里几十块屏幕同时1秒轮询一次后台很容易被拖垮。所以更稳的办法是改推送模式让服务器统一发号施令而不是让客户端自己抢跑。还要警惕一种情况每块屏直连不同的数据库实例。有些项目为了给主库减负做了读写分离或者分库分表不同屏被路由到不同实例上。假如主库更新后从库同步延迟了2秒那读从库的屏幕就比读主库的屏幕慢。这种不一致并不是同步策略的问题而是数据源本身没有统一。在处理之前一定要先确认所有终端连的是同一个数据出口。我见过一个项目某块屏连的数据库是另一个区域的灾备库数据延迟了将近1分钟查了半天才发现是配置问题。2. 多屏同步调试实操从时钟到刷新机制逐一排查在实际调试时我会遵循一套固定的排查顺序先看时间再看数据再看刷新最后才看网络和资源。这个顺序能避免很多无用功。2.1 第一步统一时间别让“时间戳”打架多块大屏上一般都会显示“最后更新时间”“数据刷新于xxx”这类字段。如果每块屏的系统时间都不一致哪怕数据值完全一样显示的时间也是错开的。比如A屏显示“更新于14:00:01”B屏显示“更新于13:59:48”现场用户第一反应就是“这两块屏不同步”。数据没问题但时间戳制造了差异感。方法在工厂局域网内部搭建一台NTP时间服务器或者直接使用工业路由器自带的时间同步功能让所有大屏、工控机、后台服务器都指向这个时间源定期同步。如果没有条件搭NTP至少把每块大屏的系统时间手动校到与服务器一致。这里有个细节Windows系统的“自动同步时间”默认走微软的公共NTP服务器如果工厂内网没有联网这个功能会一直失败。所以必须手动指定内网NTP地址。另外系统内部的时间显示格式也要统一。我见过有的大屏用“HH:mm:ss”有的大屏用“HH:mm”还有一个用“yyyy/MM/dd”看起来就乱七八糟。建议统一为“yyyy-MM-dd HH:mm:ss”或者“HH:mm:ss”精确到秒并在所有前端样式和接口返回格式里保持一致。时间戳统一之后排查问题时会轻松很多。2.2 第二步确认每个屏拉的是不是同一份数据这一步看起来简单但实际踩坑率极高。检查每块大屏对应的接口地址、数据库连接串、配置文件。常见问题包括有的屏连的是测试库有的屏连的是正式库有的屏读的是Redis缓存有的屏直接查数据库有的屏还在使用本地生成的模拟数据忘了改回真实数据源。我的调试技巧是在后台接口的返回报文里增加一个“数据版本号”或者“服务器时间戳”字段然后在每块大屏上打开浏览器的开发者工具或者系统日志看一下返回的数据源地址、版本号是否一致。如果在同一时刻两块屏拿到的版本号和时间戳完全一样说明它们拉的是同一份数据如果不一样就要顺着配置查下去。还要注意实例级缓存的问题。如果后台服务做了多实例负载均衡而每个实例的内存里都各自缓存了一份数据那么同样一个接口命中不同实例可能返回不同的缓存结果。解决办法是把缓存层换成Redis之类的共享中间件或者干脆关掉实例级缓存让所有实例都查同一个数据源。我曾经在一个项目里遇到一台服务器上的实例没有及时更新代码导致它返回的是旧数据格式只有特定几块屏被负载到了那个实例上表现就是“有的屏正常、有的屏异常”。2.3 第三步统一刷新节奏让更新命令同时落地很多人没意识到浏览器里的setInterval定时器是每个页面独立计时的。两台大屏同时打开同一个网址页面的加载时间不同JS定时器从页面加载完成后就开始跑所以每个周期是错开的。结果就是两块屏永远有一个时间差这个时间差不是固定的因为加载时间、CPU占用、事件循环阻塞都会影响定时器的精度。解决办法其实很简单如果用的是轮询把轮询的“相位”对齐。具体做法是在前端代码里加一个“整点对齐”的机制。第一步获取当前时间计算到下一个5秒节点或者其他统一周期还剩多少毫秒第二步用setTimeout休眠这个毫秒数第三步睡眠结束后开始循环执行setInterval。这样所有屏幕会在同一个毫秒级发起请求当然网络波动还是会有但至少比毫无章法的乱跳强很多。但轮询再怎么对齐也做不到真正的同时刷新因为HTTP请求从发出到返回需要时间每块屏的网络路径不同。所以更好的做法是用后端推送。用WebSocket或者MQTT让服务器在数据变化时主动向所有订阅端广播新数据。刷新时刻由服务器统一掌控而不是客户端自己拍脑袋。注意推送间隔不要过密否则大屏渲染压力大反而卡顿。一般工业看板数据1到3秒推送一次就够了没必要追求毫秒级。2.4 第四步用日志和抓包工具定位“迟到”的报文如果统一了时间、数据源、刷新节奏但还是有个别屏数据滞后那就需要抓网络包了。在大屏端打开浏览器开发者工具的Network面板观察接口请求时间和响应时间在服务器端查看访问日志看同一个请求是否在某个时间点才到达。用Wireshark可以过滤指定IP和端口直观看到TCP握手、数据包重传等细节。这里可以提一下“网络调试助手”这类小工具它们常用于设备通信调试但在大屏数据不同步的问题上更多是用Wireshark或者浏览器F12辅助。如果大屏本身是串口屏比如工控机通过串口连接一块工业显示屏就要检查串口波特率、数据位、校验位是否一致。串口参数不匹配会导致屏幕收到乱码或者丢包表现可能是某块屏长时间不刷新或者显示残缺数据。有一次我发现两块屏明明用一样的代码和配置但其中一块偶发性延迟了10秒。抓包发现这块屏连接的交换机端口类型配错了导致TCP握手包频繁重传数据包到达时间变得很长。调整交换机的端口配置为正确的access或者trunk类型后问题立刻消失。所以排查时一定要把“网络配置是否一致”纳入检查清单。2.5 第五步热点大屏的性能调优多屏不同步还有一个容易被忽略的原因某块屏太卡渲染跟不上。比如一台工控机带了两块4K分辨率的液晶屏显卡性能不足动画一多帧率就掉操作起来像放PPT。这种情况下哪怕后台数据准时推送到了前端因为渲染线程被占满也没办法及时更新画面。从用户视角看就是那块屏的数据比其他屏“慢半拍”。解决办法是单独优化前端性能。减少不必要的动画特效合并DOM更新操作给图表组件开启GPU加速用canvas替代复杂的DOM图表。如果用的是ECharts可以设置动画过度时间为0避免数据更新时因为动画导致视觉上的迟滞。另外降低大屏的分辨率或者刷新率也有可能改善比如把4K输出降到1080P把60Hz刷新率降到30Hz能显著降低显卡负载。但注意不要为了省资源把所有屏都降级尤其是车间现场的LED屏刷新率太低会有明显闪烁感反而影响观感。如果硬件确实太弱还要限制大屏同时加载的图表数量。我曾经在一个项目里一块屏上塞了12个图表还带滚动列表结果数据一刷新CPU占用100%屏幕像冻住一样。后来砍掉了一些不必要的图表把数据滚动改成大数据量的虚拟滚动问题就解决了。性能问题解决后视觉上的“不同步”自然也就消失了。3. 避坑指南我在这类项目里踩过的几个坑这一部分是压箱底的干货。以下坑我基本都实战踩过每一个都可能让你在客户现场多熬两个通宵。3.1 坑1时间基准没统一日志和画面各说各话某次项目现场有8块大屏系统刚上线时一切正常运行几天后开始出现“数据更新时间为空”的异常。排查了很久最后发现其中一台工控机的主板CMOS电池没电了系统时间回退到了2015年。前端拿到这个离谱的时间后计算出来的“最后更新时间”比服务器时间晚了十年显示出来就是一个非常诡异的空值或者错误值。更换电池并配置NTP后解决。教训硬件设备一定要接NTP时间服务不能依赖系统初始时间。就算新设备出厂时时间是准的运行几个月后也会因为CMOS电池老化而漂移。同时后台日志记录的客户端时间戳如果来自设备本地时间出现漂移后会导致排查问题时的前后顺序完全对不上。3.2 坑2前端二次计算导致口径不一致有些开发为了省事把“产量完成率”“设备综合效率OEE”“良率”这类指标的计算逻辑写在大屏前端。不同大屏因为需求不同可能引用了不同版本的代码段或者某块屏临时给客户加了一个功能而另一块屏没有同步升级。结果就是同一份源头数据经过不同前端代码算出来显示结果完全不同。这种问题特别恶心因为从数据链路看接口返回的数据是一样的屏上数字却不一样。解决起来也简单把计算逻辑全部收拢到后端前端只负责渲染后端返回的结果。如果确实需要前端做一些格式化比如单位换算、千分位分隔也要封装成统一公共函数并锁定版本。宁可多费一点带宽也不能让前端各算各的。3.3 坑3缓存策略捣乱明明数据源更新了页面没变有一回客户反馈某块屏一直显示旧数据但接口返回的新数据完全没有问题。后来发现那块屏用的是图片容器图片的URL固定不变浏览器直接走了HTTP缓存没有重新请求新的内容。解决方法是给图片URL后面加上时间戳参数比如?t1678320000强制浏览器重新加载。类似的情况还有后台接口设置了Cache-Control: max-age3600导致大屏一小时才会重新请求一次或者前端用了Service Worker缓存了旧页面。排查时如果发现接口返回的JSON明明是最新的但页面展示还是旧值一定要看看是不是缓存层在作怪。最简单的验证方式是在开发者工具里勾选Disable cache强制刷新一次。如果页面显示正常了说明就是缓存策略的问题。3.4 坑4网络配置缺失交换机端口和VLAN背锅多块大屏分布在车间的不同工位如果横跨了几台交换机VLAN配置不一致或者端口隔离策略设置不当就会导致后台推送的消息到不了某块屏。我遇到过用UDP广播协议的大屏系统交换机如果没有开启组播处理IGMP snooping或者广播转发权限部分屏幕会收不到广播包。但这里要注意不要为了图方便把整个网络划成一个大的广播域那样虽然所有屏都能收到但网络负载剧增机房交换机的CPU占用会迅速飙升反而导致整体延迟。正确的做法是让后台服务通过TCP点对点向每块屏的地址推送或者使用组播而不是用广播。排查网络类问题时先ping测各端到端的连通性再测TCP端口是否开放。如果是MQTT协议就要检查Broker的端口是否被防火墙拦截。还可以在两台大屏上同时抓包看看它们收到同一份推送消息的时间差到底有多大这样能区分是网络延迟还是应用层处理延迟。3.5 坑5大屏拼接器刷新限制成了隐形瓶颈很多工厂的“一块大屏”实际上是由多块液晶单元拼接而成的数据信号先送到拼接处理器再由处理器分发到各个单元显示。如果视频源的分辨率和刷新率拼接器不支持或者某一路信号源不稳定就会出现某个单元黑屏、闪屏、画面冻结的现象。这类问题表象是“某块区域数据不同步”实际是硬件链路问题跟软件毫无关系。建议在采购拼接器时就要确认它支持每个输入通道的独立刷新率并做好信号源热备份。调试时先用测试图比如ColorBar或者彩条信号确认每个显示单元接收到的画面完全一致再叠加业务数据去验证。如果测试图本身都是花的、飘的就不要浪费时间调软件了赶紧联系拼接器厂商。4. 防患于未然从设计阶段避免多屏不同步调试的经验再多也不如设计时就把问题挡掉。下面几条建议建议在项目规划阶段就落实能省下后面无数个加班的晚上。4.1 架构建议中央数据网关模式让所有大屏只跟一个“中央数据网关”通信不要每块屏单独对接数据源。网关负责从各类数据源采集、清洗、计算然后通过统一的接口对外输出。这样数据只有一份口径不同步的可能性会大幅下降。网关还可以做流控、权限控制和日志审计出问题时方便回溯是谁在什么时候改了数据。我在设计这类系统时会把网关单独部署成一个小服务内部连接生产数据库、PLC采集程序、人工录入模块等多个上游对外只暴露一套HTTP/WebSocket接口。每块大屏在启动时注册到网关网关记录所有终端的IP、设备编号、最后活跃时间。这样即使后来屏幕上出了问题也能在网关侧看到哪块屏多久没来上报心跳了。4.2 升级机制数据推送中的增量更新和版本号设计推送协议时除了数据本身以外一定要携带“数据版本号”可以是一个单调递增的整数也可以是统一时间戳。大屏收到新数据后先比较版本号只有比当前版本新才刷新界面否则忽略。这样做能避免因为网络重传或者消息乱序导致的旧数据覆盖新数据。界面展示上建议把版本号和更新时间印在角落字体可以小一点但一定要存在。运维人员到了现场看一眼版本号就能判断这块屏的数据是不是最新不需要打开后台或者拿对讲机跟中控室核对。这个习惯救过我很多次客户也觉得很专业。4.3 运维层面给每块屏打好标记建立台账每一块大屏都应该有独立的设备编号、IP地址、刷新方式、依赖服务名称、所在工位等信息登记在运维台账里。出现不同步时能快速定位是哪类屏、哪个区域、哪个软件版本。我见过很多项目屏挂得挺多配置和代码一塌糊涂每个人记的还不一样排查效率极低。台账可以用简单的Excel表格维护也可以纳入资产管理系统。字段至少包括设备编号、所在位置、分辨率、系统类型、浏览器版本、网络VLAN、对接的网关地址、前端代码版本、后端接口版本、最近一次变更人和变更时间。每次改动代码或者配置都要更新台账版本。别嫌麻烦真出了问题这份台账能让你少走一半弯路。4.4 经验之谈先跑单机再上多机项目调试阶段一定要先单屏跑通确认数据链路、刷新逻辑、UI渲染都正确然后再接第二块屏、第三块屏。不要一开机就同时逼着七八块屏工作否则出了问题你根本不知道是共性原因还是单点问题。我调试时习惯把所有屏的日志打开统一时间戳对齐然后同时触发一次数据更新观察各屏收到消息的先后顺序很快就能找到滞后节点。具体做法是先在后台添加一个“数据广播测试”按钮点击后向所有在线大屏推送一条包含当前服务器时间戳的测试消息。各屏收到后在前端右上角显示“某年某月某日某时某分某秒收到广播”。通过对比这些时间戳之间的差值可以快速判断网络延迟和队列积压情况。这个功能简单但极其有效。做过多屏项目的人应该都有一个体会多屏不同步80%的情况下都不是屏幕本身的问题而是数据链路和同步策略的问题。调试时不要一头扎进屏幕前瞎调先理清链路再看策略。我这里最想强调的一个小技巧就是给每块大屏的角落加上“数据版本号服务器时间戳”这条短短的信息能让所有模棱两可的问题瞬间现出原形。剩下的就是按链路一层层查而已。这套流程我用了好几年几乎没遇到过解决不了的同步问题希望也能帮你省下几个通宵。