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和express：

mkdir kanban-server && cd kanban-server npm init -y npm install ws express

数据库我用SQLite做看板自己的缓存库，轻量且不需要额外服务。如果数据量大或者需要多实例部署，换成PostgreSQL。SQLite的安装很简单：

sudo apt install sqlite3

NTP时间同步是必须做的，否则服务器和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 Server：

const sql = require('mssql'); const config = { user: 'kanban_readonly', password: 'your_password', server: '192.168.1.100', database: 'MES_DB', options: { encrypt: false, trustServerCertificate: true } };

查询语句用增量方式，先查上次最大ID：

SELECT 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/pong：

setInterval(() => { 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屏显示1200，B屏显示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-infobars

Linux下用systemd服务，写一个kanban-display.service：

[Unit] Description=Kanban Display After=network.target [Service] Type=simple User=kanban Environment=DISPLAY=:0 ExecStart=/usr/bin/chromium-browser --kiosk http://192.168.1.50/kanban Restart=always [Install] WantedBy=graphical.target

Restart=always保证浏览器崩溃后自动重启。Environment=DISPLAY=:0是必须的，否则Chromium找不到显示服务。

4.4 常见问题速查表

4.5 几个容易被忽略的实操心得

第一个心得：看板上的时间显示一定要用服务器时间，不要用浏览器本地时间。看板主机的时间可能不准，如果显示的是本地时间，工人会发现看板时间和自己的手表不一样，进而怀疑所有数据。我在后端快照里带上服务器时间戳，前端直接展示这个时间。

第二个心得：报警信息的展示要克制。早期我把所有报警都推到看板上，结果屏幕上红字滚动，工人反而不看了。后来改成只显示当前未处理的最高等级报警，最多三条，处理完自动消失。报警音也要慎用，车间噪音大，声音小了听不见，大了扰民，最后干脆不用声音，用颜色和闪烁代替。

第三个心得：给看板加一个“数据更新时间”的小字。工人看到这个时间就知道数据是不是最新的。如果超过10秒没更新，时间变红，工人就知道系统可能有问题，会主动找IT。这比IT自己发现要快得多。

第四个心得：MES接口的字段名和含义一定要和MES供应商书面确认。我遇到过MES里“产量”字段实际是“报工数量”，包含返工返修，和看板需要的“合格产量”不是一回事。如果直接拿过来展示，数据会虚高。后来让MES供应商提供了一个视图，专门给看板用，字段含义清晰。

第五个心得：看板服务器和MES数据库之间如果有防火墙，要确认端口开放。SQL Server默认1433，Oracle默认1521，MySQL默认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?line=A，后端根据参数过滤数据。复杂一点的做法是加登录，每个看板主机用不同的账号登录，后端根据账号权限返回对应数据。

我倾向于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渲染异常。后来改成周末更新，更新前拍快照，出问题回滚。

这套方案从最初的一台工控机一块屏，到现在十几块屏同步运行，前后迭代了两年多。最大的体会是：工厂看板的核心不是技术多先进，而是稳定、实时、数据可信。工人信任看板上的数字，看板才有价值。如果数字经常不对或者滞后，再漂亮的界面也是摆设。所以我在每个项目里都会花大量时间在数据采集的准确性和同步性上，展示层反而做得简单。这个取舍希望对你有参考价值。