1. 项目缘起与整体设计思路工厂车间里挂几块大屏做可视化看板这件事听起来简单真到落地的时候坑一点都不少。我前后参与过三个工厂的电子看板项目从最初用一台工控机拖一块屏到后来十几块屏分布在车间不同区域、需要同步刷新同一组生产数据中间踩过的坑足够写一本小册子。这个项目标题里的“上海工厂可视化电子看板”和“多块大屏同步数据显示调试”核心要解决的就是两个问题第一数据从哪来、怎么保证实时准确第二多块屏幕怎么做到画面一致、刷新同步、长时间运行不崩。先说清楚这个项目适合谁看。如果你是工厂的IT运维、自动化工程师、MES实施顾问或者接了小工厂数字化改造私活的独立开发者这篇内容应该能帮你省下不少试错时间。如果你只是好奇车间里那些花花绿绿的大屏是怎么跑起来的也能看个明白。整个方案不依赖特定厂商的闭源产品核心思路是用开源工具加标准协议搭一套可控的系统成本压得住后期维护也不用求人。为什么强调“多块大屏同步”因为工厂场景和商场广告屏完全不同。商场里每块屏放不同内容无所谓但车间看板如果A线显示产量1200、B线显示产量1180而实际是同一条产线的两个视角工人立刻就会质疑数据的可信度。更严重的是如果看板数据滞后于实际生产超过一个节拍班组长就会直接忽略看板继续用对讲机喊话整个可视化项目就白做了。所以同步性和实时性是这类项目的生命线不是锦上添花的功能。整体架构我采用的是“数据采集层—数据处理层—数据分发层—展示层”四层结构。采集层从MES、PLC、传感器或者手工录入终端拿数据处理层做清洗、聚合、计算分发层负责把同一份数据推给所有屏幕展示层就是浏览器全屏或者专用播放器。这个分层的好处是每一层可以独立替换比如MES换了供应商只需要改采集层的适配器上面的分发和展示完全不用动。下面我逐层拆开讲把每个环节的关键参数和踩坑点都摆出来。1.1 为什么不用传统组态软件而选自研Web方案很多工厂第一反应是买组态软件比如WinCC、组态王、力控这些。它们确实能快速拖拽出画面但多屏同步这个需求一上来组态软件的短板就暴露了。传统组态软件通常是每台工控机独立运行一个工程数据源各自连接时间戳对不齐是常态。你可能会说可以配OPC服务器做统一数据源但组态软件的画面刷新机制往往是本地定时器驱动两块屏的刷新周期差个几百毫秒太正常了。而且组态软件授权按点数卖十几块屏加上几百个变量授权费用轻松上六位数后期加一块屏还要加授权。自研Web方案的核心优势在于所有屏幕访问的是同一个URL数据来自同一个后端接口浏览器渲染同一份DOM天然就是同步的。你不需要去协调多台工控机的时间也不需要担心某台机器上的工程文件被误改。后端用Node.js或者Python写一个轻量服务前端用Vue或React做看板页面部署在内网服务器上任何一台能访问内网的设备打开浏览器全屏就是一块看板。加屏就是加一个浏览器窗口边际成本几乎为零。当然自研方案也有代价。组态软件自带大量工业图元和报警控件自研的话这些都要自己画或者找开源库。我的做法是前期只做核心的产量、状态、报警三类展示用ECharts和CSS动画搞定后期再逐步丰富。事实证明这个取舍是对的工厂最关心的就是那几个数字和红绿灯状态花哨的图表反而分散注意力。1.2 多屏同步的技术选型WebSocket还是轮询数据分发层最关键的决策是推送机制。早期我用过HTTP轮询前端每3秒发一次请求拉数据。问题很明显十几块屏同时发请求后端压力大不说每块屏的请求到达时间有先后返回时间也不一致导致画面刷新有肉眼可见的差异。更麻烦的是轮询间隔内数据变了屏幕要等到下一个周期才更新实时性差。后来换成WebSocket长连接后端在数据变化时主动推给所有连接的客户端。这里有个细节推送的时机不是数据一变就推而是按一个固定的刷新周期比如1秒批量推。因为MES数据可能每秒变好几次如果每次变化都推前端渲染压力大而且人眼也分辨不出来。我的做法是后端维护一个“最新数据快照”每500毫秒或1秒向所有WebSocket连接广播一次快照。这样所有客户端收到的是同一份数据、同一个时间戳同步性有保障。WebSocket的另一个好处是连接状态可感知。如果某块屏的网络断了后端能立刻知道可以在看板上显示“离线”标识或者触发告警。轮询模式下你很难区分是网络断了还是数据没变。实测下来用WebSocket方案十几块屏的画面刷新差异在50毫秒以内人眼完全看不出不同步。2. 核心细节解析与实操要点这一部分我把项目拆成几个关键模块每个模块讲清楚做什么、怎么做、为什么这么做。涉及具体参数的地方我会给出计算过程方便你根据自己的工厂情况调整。2.1 数据采集从MES和PLC拿数据的三种方式工厂数据源无非三类MES系统、PLC控制器、人工录入终端。MES通常提供数据库直连或者API接口PLC需要走OPC UA或者Modbus TCP人工录入可能就是一个网页表单或者扫码枪。先说MES。大部分MES的数据库是SQL Server或者Oracle直接读库是最快的方式但要注意权限和性能。我一般会建一个只读账号只授权看板需要的几张表或视图避免误操作影响生产系统。查询频率控制在1秒一次用增量查询而不是全表扫描。比如产量表有个自增ID或者时间戳字段每次只取上次最大ID之后的数据。如果MES有WebService或REST API优先走API因为数据库表结构可能随MES升级而变化API相对稳定。PLC这边如果PLC支持OPC UA直接用node-opcua或者Python的opcua库订阅变量变化。如果不支持就用Modbus TCP轮询寄存器。这里有个坑Modbus寄存器的地址和数据类型必须和PLC工程师确认清楚是16位整数还是32位浮点数字节序是大端还是小端。我遇到过把两个16位寄存器拼成32位浮点数时高低字反了读出来的温度是几万度排查了半天。人工录入终端我建议单独做一个轻量页面扫码枪扫工单条码后弹出输入框工人填数量提交。这个页面的数据直接写看板数据库不经过MES避免污染生产系统。但要注意做防重复提交和权限控制否则工人误操作会搞乱数据。2.2 数据处理聚合计算与异常值过滤原始数据拿到后不能直接展示需要做几件事。第一是单位统一比如MES里产量单位可能是“件”PLC计数可能是“个”看板上要统一。第二是聚合比如每5分钟计算一次平均节拍、累计产量、良品率。第三是异常值过滤传感器抖动或者网络重传可能导致某个值突然跳变如果直接展示看板会闪来闪去。我的做法是在后端维护一个滑动窗口比如最近10个数据点计算中位数和标准差。如果新来的值偏离中位数超过3倍标准差就标记为可疑暂时用上一个有效值代替同时记录日志。这个逻辑不复杂但能大幅提升看板的稳定性。参数方面窗口大小10、阈值3倍标准差是我在多个项目里验证过的既不会过滤掉真实的生产波动又能挡住大部分噪声。聚合计算要注意时间对齐。比如计算“最近一小时产量”如果每块屏各自算各自的可能因为请求时间不同导致结果差几个数。正确做法是后端统一计算好把结果推给所有屏。时间窗口的起止时间也要统一我一般用整点对齐比如10:00:00到11:00:00而不是“最近3600秒”这样不同时间打开看板的人看到的数据是一致的。2.3 数据分发WebSocket服务的关键配置WebSocket服务我用Node.js的ws库或者Python的websockets库都实现过核心逻辑差不多。服务启动后监听一个端口比如8080所有看板客户端连接上来后加入一个广播组。后端有一个定时器每500毫秒或1秒执行一次从数据缓存里取最新快照序列化成JSON遍历广播组发送。这里有几个关键参数。心跳间隔设30秒如果客户端30秒没响应就断开防止死连接占用资源。消息大小限制设1MB看板数据通常只有几KB设太大反而容易被异常数据撑爆。广播时用try-catch包住每个发送操作某个客户端发送失败不影响其他客户端。还有一个容易被忽略的点WebSocket连接数。十几块屏加上可能的管理端连接数在20左右Node.js单进程轻松处理。但如果工厂有上百块屏就要考虑用Redis的发布订阅做多进程广播或者用Nginx做WebSocket代理分流。我目前经手的项目最多30块屏单进程足够但架构上留了扩展余地。2.4 展示层浏览器全屏与防休眠设置展示层最简单也最容易出问题。每块屏配一台迷你主机或者工控机装Chrome或Edge浏览器开机自动打开看板URL并全屏。这里有几个必须做的设置第一关闭浏览器自动更新否则某天早上发现浏览器升级后全屏失效第二设置开机自启动脚本断电恢复后自动打开看板第三禁用屏幕保护和休眠Windows下用powercfg命令Linux下用xset命令。防休眠这件事我踩过坑。有次工厂反映看板半夜黑屏白天正常。排查发现是Windows的电源计划里“关闭显示器”设了30分钟而看板页面没有视频播放系统认为空闲就关屏了。后来统一用脚本设置成“从不关闭显示器”和“从不休眠”。另外建议把看板主机的电源键功能改成“不采取任何操作”防止保洁人员误按关机。浏览器全屏可以用F11但F11全屏后地址栏还在鼠标移到顶部会露出来。更彻底的方式是用Chrome的kiosk模式启动参数加--kiosk这样连地址栏都没有完全像一块专用屏。如果需要在多个看板页面之间切换可以用--kiosk加多个URL或者写一个简单的轮播页面。3. 实操过程与核心环节实现这一章我把整个落地过程按时间顺序拆开从环境准备到最终调试每一步都给出具体命令和配置。你可以直接照着做也可以根据自己工厂的情况调整。3.1 服务器环境准备与依赖安装服务器我推荐用Ubuntu Server 22.04 LTS稳定且社区支持好。硬件配置看屏幕数量10块屏以内4核8G足够30块屏建议8核16G。硬盘不用太大128G SSD装系统和日志绰绰有余但要注意日志轮转否则WebSocket的调试日志几天就能撑满。安装Node.js用nvm管理版本避免系统自带的旧版本。命令如下curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash source ~/.bashrc nvm install 18 nvm use 18然后建项目目录初始化package.json安装ws和expressmkdir kanban-server cd kanban-server npm init -y npm install ws express数据库我用SQLite做看板自己的缓存库轻量且不需要额外服务。如果数据量大或者需要多实例部署换成PostgreSQL。SQLite的安装很简单sudo apt install sqlite3NTP时间同步是必须做的否则服务器和MES数据库时间不一致增量查询会漏数据。Ubuntu默认用systemd-timesyncd检查一下状态timedatectl status如果显示“System clock synchronized: yes”就没问题。如果工厂内网有NTP服务器改一下配置文件指向内网地址没有的话用公共NTP池也行但要注意工厂网络可能限制外网访问。我一般建议工厂IT在内网搭一个NTP服务所有设备包括看板服务器、工控机、PLC都指向它时间统一了后面很多问题都不会有。3.2 数据采集服务编写与MES对接采集服务我单独写一个Node.js脚本用node-cron做定时任务。先定义MES数据库连接配置用mssql库连接SQL Serverconst sql require(mssql); const config { user: kanban_readonly, password: your_password, server: 192.168.1.100, database: MES_DB, options: { encrypt: false, trustServerCertificate: true } };查询语句用增量方式先查上次最大IDSELECT MAX(RecordID) as lastId FROM ProductionOutput然后取新数据SELECT RecordID, LineCode, OutputQty, GoodQty, RecordTime FROM ProductionOutput WHERE RecordID lastId拿到数据后写入SQLite缓存表同时更新内存中的最新快照。这里要注意时区问题MES数据库里的时间可能是UTC也可能是本地时间必须和MES供应商确认。我遇到过MES存UTC时间但看板按本地时间展示导致产量数据差了8小时夜班产量显示到白班去了。PLC数据采集用modbus-serial库配置如下const ModbusRTU require(modbus-serial); const client new ModbusRTU(); await client.connectTCP(192.168.1.200, { port: 502 }); client.setID(1); const data await client.readHoldingRegisters(0, 2);读到的两个寄存器拼成32位浮点数const buffer Buffer.alloc(4); buffer.writeUInt16BE(data.data[0], 0); buffer.writeUInt16BE(data.data[1], 2); const value buffer.readFloatBE(0);如果字节序不对把writeUInt16BE换成writeUInt16LE试试。这个调试过程建议用Modbus调试工具先确认比如Modbus Poll能看到原始寄存器值比在代码里猜快得多。3.3 WebSocket广播服务实现广播服务的核心是一个定时器和一组客户端连接。代码骨架如下const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080 }); let clients new Set(); let latestSnapshot {}; wss.on(connection, (ws) { clients.add(ws); ws.send(JSON.stringify(latestSnapshot)); ws.on(close, () clients.delete(ws)); ws.on(error, () clients.delete(ws)); }); setInterval(() { const message JSON.stringify(latestSnapshot); clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) { try { ws.send(message); } catch (e) { clients.delete(ws); } } }); }, 1000);刷新周期设1秒是权衡的结果。500毫秒更流畅但服务器和网络压力翻倍2秒更省资源但工人可能觉得卡顿。1秒在大多数工厂场景下够用。如果看板上有动画效果比如数字滚动前端可以用CSS过渡让1秒的更新看起来更平滑。心跳检测用ws库自带的ping/pongsetInterval(() { clients.forEach((ws) { if (!ws.isAlive) return ws.terminate(); ws.isAlive false; ws.ping(); }); }, 30000); wss.on(connection, (ws) { ws.isAlive true; ws.on(pong, () { ws.isAlive true; }); });这段代码每30秒检查一次如果客户端没回应pong就断开。工厂网络偶尔抖动没有心跳的话死连接会越积越多最后广播变慢。3.4 前端看板页面开发与多屏适配前端我用Vue 3加ECharts打包后就是静态文件用Nginx托管。看板页面布局按工厂需求来通常顶部是标题和时间中间是几个大数字卡片显示产量、良品率、节拍底部是产线状态灯和报警列表。连接WebSocket的代码const ws new WebSocket(ws://192.168.1.50:8080); ws.onmessage (event) { const data JSON.parse(event.data); updateDashboard(data); }; ws.onclose () { setTimeout(() location.reload(), 5000); };断线后5秒自动刷新页面重连这是最简单的容错方式。更优雅的做法是指数退避重连但看板场景下刷新页面更彻底能清掉可能的内存泄漏。多屏适配要注意分辨率。工厂大屏可能是1920x1080也可能是3840x2160甚至拼接屏。我的做法是用CSS的vw/vh单位加媒体查询让布局自适应。字体大小用rem根字体大小根据屏幕宽度动态设置function setRootFontSize() { const width window.innerWidth; document.documentElement.style.fontSize (width / 1920 * 16) px; } window.addEventListener(resize, setRootFontSize); setRootFontSize();这样在4K屏上字体自动放大不用为每种分辨率单独做页面。3.5 多屏同步调试与验证方法调试同步性最直接的方法是所有屏幕并排放在一起看数字变化是否同时。但工厂屏幕分散在不同区域不可能都搬到一起。我的替代方案是做一个调试页面显示当前服务器时间戳和收到数据的时间戳精确到毫秒。在每块屏上打开这个页面截图对比时间差。实测下来局域网内WebSocket推送的延迟在10到50毫秒之间十几块屏的最大差异不超过100毫秒。人眼对100毫秒以内的差异基本无感所以同步性达标。如果发现某块屏明显滞后先检查它的网络是不是走了无线或者跨了交换机有线直连通常没问题。还有一个验证点是长时间运行稳定性。我一般会让看板连续跑72小时观察内存占用和WebSocket连接数。Node.js服务如果内存持续增长可能是clients集合里有死连接没清理检查心跳逻辑。前端浏览器如果内存增长可能是ECharts实例没销毁每次更新数据时复用实例而不是重建。4. 常见问题与排查技巧实录这一章是我在实际项目中遇到的各种问题汇总按现象、原因、解决方法整理成速查表方便你遇到类似情况时快速定位。4.1 数据不同步的三种典型场景第一种部分屏幕数据滞后几秒到几十秒。原因通常是这些屏幕的WebSocket连接断了但没触发重连或者重连后没收到最新快照。检查方法是在浏览器控制台看WebSocket的readyState如果是CLOSED或CLOSING就是断了。解决方法是完善onclose重连逻辑并且后端在客户端连接时立即发送一次最新快照。第二种所有屏幕数据都滞后。原因可能是采集服务挂了或者MES查询超时。检查后端日志看采集任务是否按时执行。我遇到过MES数据库夜间备份导致查询阻塞采集服务等超时后没重试第二天早上看板数据停在昨晚。后来加了查询超时和重试机制超时设5秒重试3次间隔1秒。第三种屏幕之间数据差一个周期。比如A屏显示1200B屏显示1198过一秒都变成1200。这是正常的因为广播周期是1秒两块屏收到消息的时间有微小差异。如果这个差异让人不适可以把前端更新做成动画过渡让数字平滑变化而不是跳变视觉上就不明显了。4.2 WebSocket连接不稳定的排查思路连接不稳定通常表现为频繁断线重连看板上的数据偶尔卡住然后恢复。排查步骤先看服务器端的连接数是否异常增长如果只增不减说明死连接没清理再看网络设备工厂里常见的无线AP切换、交换机端口协商问题都会导致WebSocket断连最后看客户端浏览器标签页如果被系统休眠也会断。我遇到过一个案例看板主机是Windows 10系统更新后网卡驱动被替换导致每10分钟断一次网。后来回滚驱动解决。所以看板主机建议关闭自动更新或者用LTSC版本。还有一个坑是Nginx代理WebSocket需要额外配置location /ws { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }少了Upgrade和Connection头WebSocket握手会失败退化成轮询或者直接连不上。proxy_read_timeout设长一点否则Nginx会在默认60秒后断开空闲连接。4.3 看板主机断电恢复后的自启动配置工厂断电是常态看板主机必须能自动恢复。Windows下用任务计划程序创建一个“计算机启动时”触发的任务操作是启动Chrome并带上kiosk参数chrome.exe --kiosk http://192.168.1.50/kanban --noerrdialogs --disable-infobarsLinux下用systemd服务写一个kanban-display.service[Unit] DescriptionKanban Display Afternetwork.target [Service] Typesimple Userkanban EnvironmentDISPLAY:0 ExecStart/usr/bin/chromium-browser --kiosk http://192.168.1.50/kanban Restartalways [Install] WantedBygraphical.targetRestartalways保证浏览器崩溃后自动重启。EnvironmentDISPLAY:0是必须的否则Chromium找不到显示服务。4.4 常见问题速查表现象可能原因排查方法解决措施所有屏数据不更新采集服务停止查看后端进程和日志重启服务加守护进程部分屏数据滞后WebSocket断连浏览器控制台看readyState完善重连逻辑加心跳数据跳变异常传感器噪声对比原始值和展示值加滑动窗口滤波看板半夜黑屏电源计划休眠检查系统电源设置设为从不休眠禁用屏保时间显示错误时区不一致对比服务器和MES时间统一用UTC存储前端转本地页面卡顿内存泄漏浏览器任务管理器看内存复用ECharts实例定时刷新页面断电后不恢复自启动未配置手动重启看是否自动打开配置任务计划或systemd数字不同步广播周期不一致对比各屏时间戳统一后端广播周期4.5 几个容易被忽略的实操心得第一个心得看板上的时间显示一定要用服务器时间不要用浏览器本地时间。看板主机的时间可能不准如果显示的是本地时间工人会发现看板时间和自己的手表不一样进而怀疑所有数据。我在后端快照里带上服务器时间戳前端直接展示这个时间。第二个心得报警信息的展示要克制。早期我把所有报警都推到看板上结果屏幕上红字滚动工人反而不看了。后来改成只显示当前未处理的最高等级报警最多三条处理完自动消失。报警音也要慎用车间噪音大声音小了听不见大了扰民最后干脆不用声音用颜色和闪烁代替。第三个心得给看板加一个“数据更新时间”的小字。工人看到这个时间就知道数据是不是最新的。如果超过10秒没更新时间变红工人就知道系统可能有问题会主动找IT。这比IT自己发现要快得多。第四个心得MES接口的字段名和含义一定要和MES供应商书面确认。我遇到过MES里“产量”字段实际是“报工数量”包含返工返修和看板需要的“合格产量”不是一回事。如果直接拿过来展示数据会虚高。后来让MES供应商提供了一个视图专门给看板用字段含义清晰。第五个心得看板服务器和MES数据库之间如果有防火墙要确认端口开放。SQL Server默认1433Oracle默认1521MySQL默认3306。有些工厂IT为了安全会改端口必须提前问清楚。我就因为没确认端口在现场调试时连不上数据库多待了一天。5. 多屏同步的进阶优化与扩展思路基础功能跑通后如果工厂有更高要求可以考虑几个进阶方向。这些不是必须做的但做了之后看板的可靠性和扩展性会更好。5.1 用NTP保证全厂时间统一前面提过NTP这里展开说一下。工厂里如果有多台服务器、工控机、看板主机时间不统一会导致很多诡异问题。比如MES记录的生产时间是10:00:00看板主机时间是10:00:05采集服务按看板主机时间查询“最近5秒数据”就会漏掉MES里那5秒的数据。所以NTP不是可选项是必选项。具体做法在内网找一台服务器做NTP服务Windows Server自带NTP服务Linux用chrony。其他设备配置成从这台服务器同步。看板服务器上检查同步状态chronyc sources -v如果显示“^*”表示同步成功。同步间隔默认64秒可以改成16秒提高精度。工厂内网延迟低同步精度能到毫秒级。5.2 看板数据的持久化与历史回放有些工厂要求看板能回放历史数据比如查看昨天某个时间段的产量曲线。这需要在后端把每次快照写入数据库按时间戳索引。SQLite单表存几个月的数据没问题查询时按时间范围过滤。如果数据量大可以按天分表或者用TimescaleDB这类时序数据库。历史回放的前端实现是加一个时间选择器用户选好时间段后前端从历史接口拉数据用ECharts画曲线。注意历史数据和实时数据的刷新机制不同历史数据是一次性加载实时数据是WebSocket推送两者要分开处理避免冲突。5.3 多车间多看板的权限与内容隔离如果工厂有多个车间每个车间只看自己的数据就需要做内容隔离。简单做法是看板URL带参数比如/kanban?lineA后端根据参数过滤数据。复杂一点的做法是加登录每个看板主机用不同的账号登录后端根据账号权限返回对应数据。我倾向于URL参数方案因为看板主机通常固定位置不需要频繁切换。配置简单出问题也好排查。权限控制放在网络层不同车间的看板主机划分到不同VLAN只能访问对应的看板URL。5.4 看板内容的动态配置工厂的生产线会调整看板内容也要跟着变。如果每次改看板都要改代码重新部署IT会疯掉。我的做法是把看板布局做成配置驱动用一个JSON文件定义显示哪些指标、什么顺序、什么颜色阈值。前端读取这个JSON渲染页面改配置只需要改文件刷新页面就生效。配置文件的例子{ title: 一号线看板, refreshInterval: 1000, cards: [ { key: output, label: 当日产量, unit: 件, threshold: { warning: 800, danger: 500 } }, { key: goodRate, label: 良品率, unit: %, threshold: { warning: 95, danger: 90 } } ] }这样IT不需要懂前端代码改改JSON就能调整看板。阈值也可以动态改比如旺季和淡季的产量目标不同改配置就行。6. 项目落地后的运维建议看板上线不是终点运维才是长期考验。我总结了几条运维建议都是实际踩坑后得出的。第一每天上班前花5分钟检查所有看板是否正常显示。可以写一个巡检脚本用HTTP请求检查看板页面是否返回200用WebSocket客户端检查数据是否在更新。脚本跑完后发邮件或企业微信通知。这样IT还没到办公室就知道哪块屏有问题。第二保留至少一台备用看板主机。看板主机故障时直接替换不耽误生产。备用主机装好系统和浏览器配置好自启动放在IT办公室需要时搬过去插上网线和电源就能用。第三日志保留至少30天。WebSocket的连接日志、采集服务的查询日志、前端的错误日志都要存。出问题时翻日志比猜快得多。日志文件按天切割避免单个文件过大。第四和工厂IT确认网络变更计划。工厂网络调整、IP变更、防火墙策略更新都会影响看板。提前知道就能提前调整避免看板突然断线。第五定期更新看板主机的操作系统补丁但要在非生产时间做并且做好回滚准备。我有次白天更新补丁重启后浏览器打不开看板原因是补丁改了显卡驱动Chromium渲染异常。后来改成周末更新更新前拍快照出问题回滚。这套方案从最初的一台工控机一块屏到现在十几块屏同步运行前后迭代了两年多。最大的体会是工厂看板的核心不是技术多先进而是稳定、实时、数据可信。工人信任看板上的数字看板才有价值。如果数字经常不对或者滞后再漂亮的界面也是摆设。所以我在每个项目里都会花大量时间在数据采集的准确性和同步性上展示层反而做得简单。这个取舍希望对你有参考价值。
上海工厂可视化电子看板：多块大屏同步数据显示调试实战
1. 项目缘起与整体设计思路工厂车间里挂几块大屏做可视化看板这件事听起来简单真到落地的时候坑一点都不少。我前后参与过三个工厂的电子看板项目从最初用一台工控机拖一块屏到后来十几块屏分布在车间不同区域、需要同步刷新同一组生产数据中间踩过的坑足够写一本小册子。这个项目标题里的“上海工厂可视化电子看板”和“多块大屏同步数据显示调试”核心要解决的就是两个问题第一数据从哪来、怎么保证实时准确第二多块屏幕怎么做到画面一致、刷新同步、长时间运行不崩。先说清楚这个项目适合谁看。如果你是工厂的IT运维、自动化工程师、MES实施顾问或者接了小工厂数字化改造私活的独立开发者这篇内容应该能帮你省下不少试错时间。如果你只是好奇车间里那些花花绿绿的大屏是怎么跑起来的也能看个明白。整个方案不依赖特定厂商的闭源产品核心思路是用开源工具加标准协议搭一套可控的系统成本压得住后期维护也不用求人。为什么强调“多块大屏同步”因为工厂场景和商场广告屏完全不同。商场里每块屏放不同内容无所谓但车间看板如果A线显示产量1200、B线显示产量1180而实际是同一条产线的两个视角工人立刻就会质疑数据的可信度。更严重的是如果看板数据滞后于实际生产超过一个节拍班组长就会直接忽略看板继续用对讲机喊话整个可视化项目就白做了。所以同步性和实时性是这类项目的生命线不是锦上添花的功能。整体架构我采用的是“数据采集层—数据处理层—数据分发层—展示层”四层结构。采集层从MES、PLC、传感器或者手工录入终端拿数据处理层做清洗、聚合、计算分发层负责把同一份数据推给所有屏幕展示层就是浏览器全屏或者专用播放器。这个分层的好处是每一层可以独立替换比如MES换了供应商只需要改采集层的适配器上面的分发和展示完全不用动。下面我逐层拆开讲把每个环节的关键参数和踩坑点都摆出来。1.1 为什么不用传统组态软件而选自研Web方案很多工厂第一反应是买组态软件比如WinCC、组态王、力控这些。它们确实能快速拖拽出画面但多屏同步这个需求一上来组态软件的短板就暴露了。传统组态软件通常是每台工控机独立运行一个工程数据源各自连接时间戳对不齐是常态。你可能会说可以配OPC服务器做统一数据源但组态软件的画面刷新机制往往是本地定时器驱动两块屏的刷新周期差个几百毫秒太正常了。而且组态软件授权按点数卖十几块屏加上几百个变量授权费用轻松上六位数后期加一块屏还要加授权。自研Web方案的核心优势在于所有屏幕访问的是同一个URL数据来自同一个后端接口浏览器渲染同一份DOM天然就是同步的。你不需要去协调多台工控机的时间也不需要担心某台机器上的工程文件被误改。后端用Node.js或者Python写一个轻量服务前端用Vue或React做看板页面部署在内网服务器上任何一台能访问内网的设备打开浏览器全屏就是一块看板。加屏就是加一个浏览器窗口边际成本几乎为零。当然自研方案也有代价。组态软件自带大量工业图元和报警控件自研的话这些都要自己画或者找开源库。我的做法是前期只做核心的产量、状态、报警三类展示用ECharts和CSS动画搞定后期再逐步丰富。事实证明这个取舍是对的工厂最关心的就是那几个数字和红绿灯状态花哨的图表反而分散注意力。1.2 多屏同步的技术选型WebSocket还是轮询数据分发层最关键的决策是推送机制。早期我用过HTTP轮询前端每3秒发一次请求拉数据。问题很明显十几块屏同时发请求后端压力大不说每块屏的请求到达时间有先后返回时间也不一致导致画面刷新有肉眼可见的差异。更麻烦的是轮询间隔内数据变了屏幕要等到下一个周期才更新实时性差。后来换成WebSocket长连接后端在数据变化时主动推给所有连接的客户端。这里有个细节推送的时机不是数据一变就推而是按一个固定的刷新周期比如1秒批量推。因为MES数据可能每秒变好几次如果每次变化都推前端渲染压力大而且人眼也分辨不出来。我的做法是后端维护一个“最新数据快照”每500毫秒或1秒向所有WebSocket连接广播一次快照。这样所有客户端收到的是同一份数据、同一个时间戳同步性有保障。WebSocket的另一个好处是连接状态可感知。如果某块屏的网络断了后端能立刻知道可以在看板上显示“离线”标识或者触发告警。轮询模式下你很难区分是网络断了还是数据没变。实测下来用WebSocket方案十几块屏的画面刷新差异在50毫秒以内人眼完全看不出不同步。2. 核心细节解析与实操要点这一部分我把项目拆成几个关键模块每个模块讲清楚做什么、怎么做、为什么这么做。涉及具体参数的地方我会给出计算过程方便你根据自己的工厂情况调整。2.1 数据采集从MES和PLC拿数据的三种方式工厂数据源无非三类MES系统、PLC控制器、人工录入终端。MES通常提供数据库直连或者API接口PLC需要走OPC UA或者Modbus TCP人工录入可能就是一个网页表单或者扫码枪。先说MES。大部分MES的数据库是SQL Server或者Oracle直接读库是最快的方式但要注意权限和性能。我一般会建一个只读账号只授权看板需要的几张表或视图避免误操作影响生产系统。查询频率控制在1秒一次用增量查询而不是全表扫描。比如产量表有个自增ID或者时间戳字段每次只取上次最大ID之后的数据。如果MES有WebService或REST API优先走API因为数据库表结构可能随MES升级而变化API相对稳定。PLC这边如果PLC支持OPC UA直接用node-opcua或者Python的opcua库订阅变量变化。如果不支持就用Modbus TCP轮询寄存器。这里有个坑Modbus寄存器的地址和数据类型必须和PLC工程师确认清楚是16位整数还是32位浮点数字节序是大端还是小端。我遇到过把两个16位寄存器拼成32位浮点数时高低字反了读出来的温度是几万度排查了半天。人工录入终端我建议单独做一个轻量页面扫码枪扫工单条码后弹出输入框工人填数量提交。这个页面的数据直接写看板数据库不经过MES避免污染生产系统。但要注意做防重复提交和权限控制否则工人误操作会搞乱数据。2.2 数据处理聚合计算与异常值过滤原始数据拿到后不能直接展示需要做几件事。第一是单位统一比如MES里产量单位可能是“件”PLC计数可能是“个”看板上要统一。第二是聚合比如每5分钟计算一次平均节拍、累计产量、良品率。第三是异常值过滤传感器抖动或者网络重传可能导致某个值突然跳变如果直接展示看板会闪来闪去。我的做法是在后端维护一个滑动窗口比如最近10个数据点计算中位数和标准差。如果新来的值偏离中位数超过3倍标准差就标记为可疑暂时用上一个有效值代替同时记录日志。这个逻辑不复杂但能大幅提升看板的稳定性。参数方面窗口大小10、阈值3倍标准差是我在多个项目里验证过的既不会过滤掉真实的生产波动又能挡住大部分噪声。聚合计算要注意时间对齐。比如计算“最近一小时产量”如果每块屏各自算各自的可能因为请求时间不同导致结果差几个数。正确做法是后端统一计算好把结果推给所有屏。时间窗口的起止时间也要统一我一般用整点对齐比如10:00:00到11:00:00而不是“最近3600秒”这样不同时间打开看板的人看到的数据是一致的。2.3 数据分发WebSocket服务的关键配置WebSocket服务我用Node.js的ws库或者Python的websockets库都实现过核心逻辑差不多。服务启动后监听一个端口比如8080所有看板客户端连接上来后加入一个广播组。后端有一个定时器每500毫秒或1秒执行一次从数据缓存里取最新快照序列化成JSON遍历广播组发送。这里有几个关键参数。心跳间隔设30秒如果客户端30秒没响应就断开防止死连接占用资源。消息大小限制设1MB看板数据通常只有几KB设太大反而容易被异常数据撑爆。广播时用try-catch包住每个发送操作某个客户端发送失败不影响其他客户端。还有一个容易被忽略的点WebSocket连接数。十几块屏加上可能的管理端连接数在20左右Node.js单进程轻松处理。但如果工厂有上百块屏就要考虑用Redis的发布订阅做多进程广播或者用Nginx做WebSocket代理分流。我目前经手的项目最多30块屏单进程足够但架构上留了扩展余地。2.4 展示层浏览器全屏与防休眠设置展示层最简单也最容易出问题。每块屏配一台迷你主机或者工控机装Chrome或Edge浏览器开机自动打开看板URL并全屏。这里有几个必须做的设置第一关闭浏览器自动更新否则某天早上发现浏览器升级后全屏失效第二设置开机自启动脚本断电恢复后自动打开看板第三禁用屏幕保护和休眠Windows下用powercfg命令Linux下用xset命令。防休眠这件事我踩过坑。有次工厂反映看板半夜黑屏白天正常。排查发现是Windows的电源计划里“关闭显示器”设了30分钟而看板页面没有视频播放系统认为空闲就关屏了。后来统一用脚本设置成“从不关闭显示器”和“从不休眠”。另外建议把看板主机的电源键功能改成“不采取任何操作”防止保洁人员误按关机。浏览器全屏可以用F11但F11全屏后地址栏还在鼠标移到顶部会露出来。更彻底的方式是用Chrome的kiosk模式启动参数加--kiosk这样连地址栏都没有完全像一块专用屏。如果需要在多个看板页面之间切换可以用--kiosk加多个URL或者写一个简单的轮播页面。3. 实操过程与核心环节实现这一章我把整个落地过程按时间顺序拆开从环境准备到最终调试每一步都给出具体命令和配置。你可以直接照着做也可以根据自己工厂的情况调整。3.1 服务器环境准备与依赖安装服务器我推荐用Ubuntu Server 22.04 LTS稳定且社区支持好。硬件配置看屏幕数量10块屏以内4核8G足够30块屏建议8核16G。硬盘不用太大128G SSD装系统和日志绰绰有余但要注意日志轮转否则WebSocket的调试日志几天就能撑满。安装Node.js用nvm管理版本避免系统自带的旧版本。命令如下curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash source ~/.bashrc nvm install 18 nvm use 18然后建项目目录初始化package.json安装ws和expressmkdir kanban-server cd kanban-server npm init -y npm install ws express数据库我用SQLite做看板自己的缓存库轻量且不需要额外服务。如果数据量大或者需要多实例部署换成PostgreSQL。SQLite的安装很简单sudo apt install sqlite3NTP时间同步是必须做的否则服务器和MES数据库时间不一致增量查询会漏数据。Ubuntu默认用systemd-timesyncd检查一下状态timedatectl status如果显示“System clock synchronized: yes”就没问题。如果工厂内网有NTP服务器改一下配置文件指向内网地址没有的话用公共NTP池也行但要注意工厂网络可能限制外网访问。我一般建议工厂IT在内网搭一个NTP服务所有设备包括看板服务器、工控机、PLC都指向它时间统一了后面很多问题都不会有。3.2 数据采集服务编写与MES对接采集服务我单独写一个Node.js脚本用node-cron做定时任务。先定义MES数据库连接配置用mssql库连接SQL Serverconst sql require(mssql); const config { user: kanban_readonly, password: your_password, server: 192.168.1.100, database: MES_DB, options: { encrypt: false, trustServerCertificate: true } };查询语句用增量方式先查上次最大IDSELECT MAX(RecordID) as lastId FROM ProductionOutput然后取新数据SELECT RecordID, LineCode, OutputQty, GoodQty, RecordTime FROM ProductionOutput WHERE RecordID lastId拿到数据后写入SQLite缓存表同时更新内存中的最新快照。这里要注意时区问题MES数据库里的时间可能是UTC也可能是本地时间必须和MES供应商确认。我遇到过MES存UTC时间但看板按本地时间展示导致产量数据差了8小时夜班产量显示到白班去了。PLC数据采集用modbus-serial库配置如下const ModbusRTU require(modbus-serial); const client new ModbusRTU(); await client.connectTCP(192.168.1.200, { port: 502 }); client.setID(1); const data await client.readHoldingRegisters(0, 2);读到的两个寄存器拼成32位浮点数const buffer Buffer.alloc(4); buffer.writeUInt16BE(data.data[0], 0); buffer.writeUInt16BE(data.data[1], 2); const value buffer.readFloatBE(0);如果字节序不对把writeUInt16BE换成writeUInt16LE试试。这个调试过程建议用Modbus调试工具先确认比如Modbus Poll能看到原始寄存器值比在代码里猜快得多。3.3 WebSocket广播服务实现广播服务的核心是一个定时器和一组客户端连接。代码骨架如下const WebSocket require(ws); const wss new WebSocket.Server({ port: 8080 }); let clients new Set(); let latestSnapshot {}; wss.on(connection, (ws) { clients.add(ws); ws.send(JSON.stringify(latestSnapshot)); ws.on(close, () clients.delete(ws)); ws.on(error, () clients.delete(ws)); }); setInterval(() { const message JSON.stringify(latestSnapshot); clients.forEach((ws) { if (ws.readyState WebSocket.OPEN) { try { ws.send(message); } catch (e) { clients.delete(ws); } } }); }, 1000);刷新周期设1秒是权衡的结果。500毫秒更流畅但服务器和网络压力翻倍2秒更省资源但工人可能觉得卡顿。1秒在大多数工厂场景下够用。如果看板上有动画效果比如数字滚动前端可以用CSS过渡让1秒的更新看起来更平滑。心跳检测用ws库自带的ping/pongsetInterval(() { clients.forEach((ws) { if (!ws.isAlive) return ws.terminate(); ws.isAlive false; ws.ping(); }); }, 30000); wss.on(connection, (ws) { ws.isAlive true; ws.on(pong, () { ws.isAlive true; }); });这段代码每30秒检查一次如果客户端没回应pong就断开。工厂网络偶尔抖动没有心跳的话死连接会越积越多最后广播变慢。3.4 前端看板页面开发与多屏适配前端我用Vue 3加ECharts打包后就是静态文件用Nginx托管。看板页面布局按工厂需求来通常顶部是标题和时间中间是几个大数字卡片显示产量、良品率、节拍底部是产线状态灯和报警列表。连接WebSocket的代码const ws new WebSocket(ws://192.168.1.50:8080); ws.onmessage (event) { const data JSON.parse(event.data); updateDashboard(data); }; ws.onclose () { setTimeout(() location.reload(), 5000); };断线后5秒自动刷新页面重连这是最简单的容错方式。更优雅的做法是指数退避重连但看板场景下刷新页面更彻底能清掉可能的内存泄漏。多屏适配要注意分辨率。工厂大屏可能是1920x1080也可能是3840x2160甚至拼接屏。我的做法是用CSS的vw/vh单位加媒体查询让布局自适应。字体大小用rem根字体大小根据屏幕宽度动态设置function setRootFontSize() { const width window.innerWidth; document.documentElement.style.fontSize (width / 1920 * 16) px; } window.addEventListener(resize, setRootFontSize); setRootFontSize();这样在4K屏上字体自动放大不用为每种分辨率单独做页面。3.5 多屏同步调试与验证方法调试同步性最直接的方法是所有屏幕并排放在一起看数字变化是否同时。但工厂屏幕分散在不同区域不可能都搬到一起。我的替代方案是做一个调试页面显示当前服务器时间戳和收到数据的时间戳精确到毫秒。在每块屏上打开这个页面截图对比时间差。实测下来局域网内WebSocket推送的延迟在10到50毫秒之间十几块屏的最大差异不超过100毫秒。人眼对100毫秒以内的差异基本无感所以同步性达标。如果发现某块屏明显滞后先检查它的网络是不是走了无线或者跨了交换机有线直连通常没问题。还有一个验证点是长时间运行稳定性。我一般会让看板连续跑72小时观察内存占用和WebSocket连接数。Node.js服务如果内存持续增长可能是clients集合里有死连接没清理检查心跳逻辑。前端浏览器如果内存增长可能是ECharts实例没销毁每次更新数据时复用实例而不是重建。4. 常见问题与排查技巧实录这一章是我在实际项目中遇到的各种问题汇总按现象、原因、解决方法整理成速查表方便你遇到类似情况时快速定位。4.1 数据不同步的三种典型场景第一种部分屏幕数据滞后几秒到几十秒。原因通常是这些屏幕的WebSocket连接断了但没触发重连或者重连后没收到最新快照。检查方法是在浏览器控制台看WebSocket的readyState如果是CLOSED或CLOSING就是断了。解决方法是完善onclose重连逻辑并且后端在客户端连接时立即发送一次最新快照。第二种所有屏幕数据都滞后。原因可能是采集服务挂了或者MES查询超时。检查后端日志看采集任务是否按时执行。我遇到过MES数据库夜间备份导致查询阻塞采集服务等超时后没重试第二天早上看板数据停在昨晚。后来加了查询超时和重试机制超时设5秒重试3次间隔1秒。第三种屏幕之间数据差一个周期。比如A屏显示1200B屏显示1198过一秒都变成1200。这是正常的因为广播周期是1秒两块屏收到消息的时间有微小差异。如果这个差异让人不适可以把前端更新做成动画过渡让数字平滑变化而不是跳变视觉上就不明显了。4.2 WebSocket连接不稳定的排查思路连接不稳定通常表现为频繁断线重连看板上的数据偶尔卡住然后恢复。排查步骤先看服务器端的连接数是否异常增长如果只增不减说明死连接没清理再看网络设备工厂里常见的无线AP切换、交换机端口协商问题都会导致WebSocket断连最后看客户端浏览器标签页如果被系统休眠也会断。我遇到过一个案例看板主机是Windows 10系统更新后网卡驱动被替换导致每10分钟断一次网。后来回滚驱动解决。所以看板主机建议关闭自动更新或者用LTSC版本。还有一个坑是Nginx代理WebSocket需要额外配置location /ws { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_read_timeout 3600s; }少了Upgrade和Connection头WebSocket握手会失败退化成轮询或者直接连不上。proxy_read_timeout设长一点否则Nginx会在默认60秒后断开空闲连接。4.3 看板主机断电恢复后的自启动配置工厂断电是常态看板主机必须能自动恢复。Windows下用任务计划程序创建一个“计算机启动时”触发的任务操作是启动Chrome并带上kiosk参数chrome.exe --kiosk http://192.168.1.50/kanban --noerrdialogs --disable-infobarsLinux下用systemd服务写一个kanban-display.service[Unit] DescriptionKanban Display Afternetwork.target [Service] Typesimple Userkanban EnvironmentDISPLAY:0 ExecStart/usr/bin/chromium-browser --kiosk http://192.168.1.50/kanban Restartalways [Install] WantedBygraphical.targetRestartalways保证浏览器崩溃后自动重启。EnvironmentDISPLAY:0是必须的否则Chromium找不到显示服务。4.4 常见问题速查表现象可能原因排查方法解决措施所有屏数据不更新采集服务停止查看后端进程和日志重启服务加守护进程部分屏数据滞后WebSocket断连浏览器控制台看readyState完善重连逻辑加心跳数据跳变异常传感器噪声对比原始值和展示值加滑动窗口滤波看板半夜黑屏电源计划休眠检查系统电源设置设为从不休眠禁用屏保时间显示错误时区不一致对比服务器和MES时间统一用UTC存储前端转本地页面卡顿内存泄漏浏览器任务管理器看内存复用ECharts实例定时刷新页面断电后不恢复自启动未配置手动重启看是否自动打开配置任务计划或systemd数字不同步广播周期不一致对比各屏时间戳统一后端广播周期4.5 几个容易被忽略的实操心得第一个心得看板上的时间显示一定要用服务器时间不要用浏览器本地时间。看板主机的时间可能不准如果显示的是本地时间工人会发现看板时间和自己的手表不一样进而怀疑所有数据。我在后端快照里带上服务器时间戳前端直接展示这个时间。第二个心得报警信息的展示要克制。早期我把所有报警都推到看板上结果屏幕上红字滚动工人反而不看了。后来改成只显示当前未处理的最高等级报警最多三条处理完自动消失。报警音也要慎用车间噪音大声音小了听不见大了扰民最后干脆不用声音用颜色和闪烁代替。第三个心得给看板加一个“数据更新时间”的小字。工人看到这个时间就知道数据是不是最新的。如果超过10秒没更新时间变红工人就知道系统可能有问题会主动找IT。这比IT自己发现要快得多。第四个心得MES接口的字段名和含义一定要和MES供应商书面确认。我遇到过MES里“产量”字段实际是“报工数量”包含返工返修和看板需要的“合格产量”不是一回事。如果直接拿过来展示数据会虚高。后来让MES供应商提供了一个视图专门给看板用字段含义清晰。第五个心得看板服务器和MES数据库之间如果有防火墙要确认端口开放。SQL Server默认1433Oracle默认1521MySQL默认3306。有些工厂IT为了安全会改端口必须提前问清楚。我就因为没确认端口在现场调试时连不上数据库多待了一天。5. 多屏同步的进阶优化与扩展思路基础功能跑通后如果工厂有更高要求可以考虑几个进阶方向。这些不是必须做的但做了之后看板的可靠性和扩展性会更好。5.1 用NTP保证全厂时间统一前面提过NTP这里展开说一下。工厂里如果有多台服务器、工控机、看板主机时间不统一会导致很多诡异问题。比如MES记录的生产时间是10:00:00看板主机时间是10:00:05采集服务按看板主机时间查询“最近5秒数据”就会漏掉MES里那5秒的数据。所以NTP不是可选项是必选项。具体做法在内网找一台服务器做NTP服务Windows Server自带NTP服务Linux用chrony。其他设备配置成从这台服务器同步。看板服务器上检查同步状态chronyc sources -v如果显示“^*”表示同步成功。同步间隔默认64秒可以改成16秒提高精度。工厂内网延迟低同步精度能到毫秒级。5.2 看板数据的持久化与历史回放有些工厂要求看板能回放历史数据比如查看昨天某个时间段的产量曲线。这需要在后端把每次快照写入数据库按时间戳索引。SQLite单表存几个月的数据没问题查询时按时间范围过滤。如果数据量大可以按天分表或者用TimescaleDB这类时序数据库。历史回放的前端实现是加一个时间选择器用户选好时间段后前端从历史接口拉数据用ECharts画曲线。注意历史数据和实时数据的刷新机制不同历史数据是一次性加载实时数据是WebSocket推送两者要分开处理避免冲突。5.3 多车间多看板的权限与内容隔离如果工厂有多个车间每个车间只看自己的数据就需要做内容隔离。简单做法是看板URL带参数比如/kanban?lineA后端根据参数过滤数据。复杂一点的做法是加登录每个看板主机用不同的账号登录后端根据账号权限返回对应数据。我倾向于URL参数方案因为看板主机通常固定位置不需要频繁切换。配置简单出问题也好排查。权限控制放在网络层不同车间的看板主机划分到不同VLAN只能访问对应的看板URL。5.4 看板内容的动态配置工厂的生产线会调整看板内容也要跟着变。如果每次改看板都要改代码重新部署IT会疯掉。我的做法是把看板布局做成配置驱动用一个JSON文件定义显示哪些指标、什么顺序、什么颜色阈值。前端读取这个JSON渲染页面改配置只需要改文件刷新页面就生效。配置文件的例子{ title: 一号线看板, refreshInterval: 1000, cards: [ { key: output, label: 当日产量, unit: 件, threshold: { warning: 800, danger: 500 } }, { key: goodRate, label: 良品率, unit: %, threshold: { warning: 95, danger: 90 } } ] }这样IT不需要懂前端代码改改JSON就能调整看板。阈值也可以动态改比如旺季和淡季的产量目标不同改配置就行。6. 项目落地后的运维建议看板上线不是终点运维才是长期考验。我总结了几条运维建议都是实际踩坑后得出的。第一每天上班前花5分钟检查所有看板是否正常显示。可以写一个巡检脚本用HTTP请求检查看板页面是否返回200用WebSocket客户端检查数据是否在更新。脚本跑完后发邮件或企业微信通知。这样IT还没到办公室就知道哪块屏有问题。第二保留至少一台备用看板主机。看板主机故障时直接替换不耽误生产。备用主机装好系统和浏览器配置好自启动放在IT办公室需要时搬过去插上网线和电源就能用。第三日志保留至少30天。WebSocket的连接日志、采集服务的查询日志、前端的错误日志都要存。出问题时翻日志比猜快得多。日志文件按天切割避免单个文件过大。第四和工厂IT确认网络变更计划。工厂网络调整、IP变更、防火墙策略更新都会影响看板。提前知道就能提前调整避免看板突然断线。第五定期更新看板主机的操作系统补丁但要在非生产时间做并且做好回滚准备。我有次白天更新补丁重启后浏览器打不开看板原因是补丁改了显卡驱动Chromium渲染异常。后来改成周末更新更新前拍快照出问题回滚。这套方案从最初的一台工控机一块屏到现在十几块屏同步运行前后迭代了两年多。最大的体会是工厂看板的核心不是技术多先进而是稳定、实时、数据可信。工人信任看板上的数字看板才有价值。如果数字经常不对或者滞后再漂亮的界面也是摆设。所以我在每个项目里都会花大量时间在数据采集的准确性和同步性上展示层反而做得简单。这个取舍希望对你有参考价值。
