1. 项目背景与整体设计思路1.1 为什么工厂车间需要可视化电子看板我在汽车零部件行业做过好几个车间的数字化改造项目上海这边的制造工厂有个很普遍的特点产线密度高、设备品牌杂、班组交接频繁。车间主任最头疼的事情就是——数据散落在各个角落。A线的产量在PLC里B线的良率在MES里C线的设备状态在SCADA里每次开早会要三个人分别报数报完还要对一遍对完发现口径不一致。可视化电子看板要解决的核心问题就一个把分散的数据源汇聚到统一的大屏上让车间里所有人看到同一份实时数据。听起来简单但落地的时候坑非常多。多块大屏同步显示就是其中最典型的难点——你不可能给每块屏单独配一台工控机跑一套程序成本扛不住维护也扛不住。这个项目的目标很明确在上海某汽车零部件工厂的冲压和装配两个车间部署6块55寸工业大屏分别挂在车间入口、两条产线中段、质检区、设备维修间和车间办公室。所有屏幕显示同一套数据包括实时产量、节拍、良率、设备OEE、异常报警。数据来源涉及MES系统、PLC采集网关和一个独立的Andon报警系统。1.2 整体架构选型与背后的考量架构设计上我走过弯路第一版方案是每块屏配一台迷你主机各自跑浏览器全屏打开看板页面。这个方案的问题在调试阶段就暴露了6台机器要分别配置网络、分别设置开机自启、分别处理浏览器缓存问题。更致命的是当看板页面需要更新时你要逐台远程操作万一某台机器离线了那块屏就挂着旧版本跑。第二版方案改成了中心渲染多屏同步的架构。具体来说一台性能足够的工控机作为渲染主机负责运行看板前端程序通过HDMI分配器或者视频矩阵把画面分发到多块大屏数据层由后端服务统一从MES、PLC网关拉取通过WebSocket推送给前端这个架构的好处是只需要维护一套渲染逻辑屏幕数量增加时只需要加分配器端口。缺点是HDMI线缆传输距离有限超过15米就需要用光纤HDMI或者走网络方案。最终我们采用的是混合方案车间办公室和入口的两块屏用HDMI分配器直连距离渲染主机不超过10米产线中段和质检区的四块屏走网络推流方案每块屏配一个支持RTSP或者HTTP流的网络播放盒渲染主机把画面编码后推给播放盒。这样既控制了成本又解决了远距离传输问题。注意网络推流方案的延迟比HDMI直连高实测在200ms到500ms之间。对于产量看板这种秒级更新的场景完全够用但如果是设备急停报警这种要求实时性的场景建议还是走HDMI直连或者单独的Andon灯系统。1.3 数据链路的关键设计决策数据链路这块我重点说一下为什么选择NTP时间同步作为整个系统的基础设施。多块大屏显示同一份数据如果各屏幕的时间不一致会出现一个很尴尬的情况A屏显示10:30:15 产量120B屏显示10:30:12 产量118。操作工看到会质疑数据准确性班组长会怀疑系统有bug。NTP同步在这个项目里做了两层第一层是渲染主机和所有数据源服务器MES应用服务器、PLC网关、Andon服务器都指向同一个NTP源。上海工厂这边我们用的是华为云NTP服务器地址延迟低、稳定性好。具体配置后面会详细说。第二层是网络播放盒和渲染主机之间的时间同步。播放盒本身不产生数据但它渲染的画面里如果有时间戳组件就需要和渲染主机保持一致。我们通过播放盒的NTP客户端配置让它也指向同一个NTP源。这个设计决策看起来简单但在实际调试中NTP同步没做好导致的灵异问题占了总调试时间的30%以上。后面我会专门用一节来讲NTP调试的坑。2. 核心硬件选型与现场部署实操2.1 大屏与播放设备的选型要点工业大屏和商用大屏是两回事。车间环境有粉尘、有震动、有电磁干扰商用大屏用不了几个月就会出现色差、坏点甚至黑屏。我们选的是工业级液晶屏亮度至少500cd/m²对比度3000:1以上支持7x24小时连续运行。尺寸上55寸是车间看板的黄金尺寸——太小了远处看不清太大了安装支架成本飙升。播放设备这块HDMI直连的屏幕不需要额外设备但网络推流的屏幕需要网络播放盒。市面上常见的方案有三种方案类型典型延迟成本稳定性适用场景安卓播放盒300-800ms低一般非实时看板工控机解码软件200-500ms中高工业看板专用解码器100-300ms高很高安防监控我们最终选了工控机解码软件的方案。原因很简单安卓播放盒在长时间运行后会出现内存泄漏画面卡顿甚至黑屏需要定期重启。工控机虽然贵一点但跑Linux系统稳定性有保障而且可以通过SSH远程批量管理。2.2 网络规划与布线实操车间网络规划有个原则看板网络和设备控制网络物理隔离。这不是小题大做我见过因为看板网络广播风暴导致PLC通信中断的案例。具体做法是看板系统单独走一个VLAN用独立的交换机如果需要从MES取数据通过防火墙策略只开放必要的端口网络播放盒的IP地址用DHCP保留不要用静态IP手动配置后期维护会疯掉布线方面网线用超六类屏蔽线车间里变频器、伺服驱动器一大堆非屏蔽线跑千兆会丢包。走线槽要和动力线保持至少30cm距离交叉时垂直交叉。这些细节看起来琐碎但后期排查网络问题时你会发现当初多花的那点线材钱太值了。HDMI线缆超过10米一定要用光纤HDMI普通铜缆HDMI在15米以上就会出现闪屏、无信号。光纤HDMI有方向性Source端和Display端不能接反接反了直接黑屏。我第一次用的时候没注意排查了半天以为是大屏坏了。2.3 渲染主机的配置与优化渲染主机不需要顶级配置但有几个关键点CPU至少4核主频3.0GHz以上。看板前端如果有复杂动画CPU占用会比较高内存16GB起步。浏览器全屏跑看板页面加上WebSocket长连接内存占用不小显卡支持多路输出如果走HDMI分配器显卡只需要一个输出口硬盘SSD256GB足够。系统盘用SSD日志和数据盘可以用机械盘操作系统Ubuntu Server 22.04 LTS。不要用Windows自动更新和杀毒软件会打断看板运行系统优化方面我做了这几件事# 关闭不必要的系统服务 sudo systemctl disable bluetooth.service sudo systemctl disable cups.service # 设置看板程序开机自启 sudo systemctl enable kanban-renderer.service # 配置自动登录和自动启动浏览器全屏 # 在 ~/.config/autostart/ 下创建 desktop 文件浏览器用的是Chromium启动参数很关键chromium-browser --kiosk --noerrdialogs --disable-infobars \ --disable-session-crashed-bubble --disable-translate \ --autoplay-policyno-user-gesture-required \ --touch-eventsdisabled \ http://localhost:8080/kanban--kiosk参数让浏览器全屏且无地址栏--noerrdialogs禁止错误弹窗--disable-session-crashed-bubble防止崩溃恢复提示遮挡画面。这些参数少一个现场就可能出问题。3. 数据采集与MES对接的核心细节3.1 MES数据接口的选型与调试MES系统对接是看板项目里最耗时的环节没有之一。上海这家工厂用的是某国产MES接口方式有WebService和REST API两种。我们最终选了REST API原因有三第一WebService的SOAP协议解析起来太啰嗦前端直接调用不方便需要中间层转换。第二REST API返回JSON格式前端处理起来简单直接。第三MES厂商的REST API文档更完整调试工具也更好用。调试MES接口的时候网口调试助手和串口调试助手是我的左膀右臂。网口调试助手用来测试HTTP接口串口调试助手用来调试PLC网关的串口通信。这里要提醒一句网口调试助手选择支持HTTP和WebSocket的版本普通的TCP/UDP调试工具不够用。MES接口的典型调用流程是这样的import requests import json from datetime import datetime # MES接口配置 MES_BASE_URL http://mes-server:8080/api/v1 API_KEY your-api-key-here def get_production_data(line_code): 获取指定产线的实时产量数据 headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } params { line: line_code, shift: get_current_shift(), date: datetime.now().strftime(%Y-%m-%d) } try: response requests.get( f{MES_BASE_URL}/production/realtime, headersheaders, paramsparams, timeout5 ) response.raise_for_status() return response.json() except requests.exceptions.Timeout: # 超时处理返回上一次缓存数据 return get_cached_data(line_code) except requests.exceptions.RequestException as e: log_error(fMES接口调用失败: {e}) return None这段代码里有个关键设计超时返回缓存数据。MES系统偶尔会重启或者响应慢如果看板直接显示数据获取失败车间主任会打电话来问是不是系统坏了。返回上一次的缓存数据同时在看板角落显示一个小提示数据延迟体验会好很多。3.2 PLC数据采集与协议转换PLC数据采集这块工厂里常见的有西门子、三菱、欧姆龙几个品牌。上海这家工厂冲压线用的是西门子S7-1200装配线用的是三菱FX系列。两种PLC的通信协议完全不同需要分别处理。西门子S7-1200支持S7协议可以通过开源库python-snap7直接读取。三菱FX系列用的是MC协议需要用到pymcprotocol这个库。如果PLC型号比较老只有串口输出那就需要串口转网口的网关设备。串口调试助手在这里的作用是先确认PLC的串口输出格式再配置网关的转换规则。我遇到过一个问题PLC输出的数据是十六进制字符串但网关默认按ASCII解析导致数据完全对不上。用串口调试助手抓包一看发现是解析模式设错了改成HEX模式就正常了。PLC数据采集的频率不需要太高1秒一次足够了。采集太频繁会给PLC增加负担有些老型号PLC的通信模块处理不过来会导致通信超时。import snap7 from snap7.util import get_int, get_real def read_s7_plc(plc_ip, rack, slot): 读取西门子S7-1200 PLC数据 client snap7.client.Client() try: client.connect(plc_ip, rack, slot) # 读取DB块数据 # DB100.DBD0 存储产量DB100.DBD4 存储节拍 data client.db_read(100, 0, 8) production_count get_int(data, 0) cycle_time get_real(data, 4) return { production: production_count, cycle_time: cycle_time, timestamp: datetime.now().isoformat() } except Exception as e: log_error(fPLC读取失败: {e}) return None finally: client.disconnect()3.3 数据缓存与断线重连机制工厂网络不是实验室网络断线是常态。看板系统必须能扛住网络抖动。我的做法是在后端服务里加一层内存缓存本地持久化每次从MES或PLC取到数据先写入内存缓存同时异步写入本地SQLite数据库作为持久化备份前端通过WebSocket订阅数据后端每500ms推送一次最新缓存如果数据源断线后端继续推送缓存数据同时标记数据状态为延迟WebSocket的重连机制也很重要。前端要监听onclose事件断开后自动重连重连间隔采用指数退避策略1秒、2秒、4秒、8秒最大30秒。let reconnectDelay 1000; const MAX_DELAY 30000; function connectWebSocket() { const ws new WebSocket(ws://localhost:8080/ws/kanban); ws.onopen function() { console.log(WebSocket连接成功); reconnectDelay 1000; // 重置重连延迟 }; ws.onmessage function(event) { const data JSON.parse(event.data); updateKanbanDisplay(data); }; ws.onclose function() { console.log(连接断开${reconnectDelay}ms后重连); setTimeout(connectWebSocket, reconnectDelay); reconnectDelay Math.min(reconnectDelay * 2, MAX_DELAY); }; ws.onerror function(error) { console.error(WebSocket错误:, error); ws.close(); }; }这套机制上线后即使MES系统半夜重启看板也只是短暂显示数据延迟不会黑屏或者报错。4. 多屏同步显示的核心技术与调试4.1 NTP时间同步的配置与排错NTP同步是整个多屏系统的基石。我前面说过时间不一致会导致数据看起来打架。具体配置分三步第一步确认渲染主机和所有数据源服务器都能访问NTP服务器。# 测试NTP服务器连通性 ntpdate -q ntp.huaweicloud.com # 输出示例 # server 120.46.128.100, stratum 2, offset 0.003421, delay 0.02567 # offset 0.003421 表示本地时间比NTP服务器快3.4毫秒这个精度完全够用第二步配置chrony作为NTP客户端。Ubuntu 22.04默认用chrony而不是ntpd配置文件在/etc/chrony/chrony.conf# 华为云NTP服务器 server ntp.huaweicloud.com iburst server ntp1.huaweicloud.com iburst server ntp2.huaweicloud.com iburst # 允许本地网络的其他设备同步 allow 192.168.1.0/24 # 即使无法访问外部NTP也作为本地时间源提供服务 local stratum 10iburst参数让chrony在启动时快速发送多个NTP请求加快同步速度。local stratum 10这行很关键——如果工厂外网断了渲染主机还能作为本地NTP服务器给播放盒提供时间同步。第三步播放盒配置NTP客户端。播放盒的NTP配置通常在系统设置里指向渲染主机的IP地址。配置完成后用chronyc sources命令检查同步状态。NTP调试中最常见的坑问题现象可能原因解决方法时间偏差几小时时区配置错误检查/etc/timezone是否为Asia/Shanghai时间偏差几秒NTP未同步检查防火墙是否放行UDP 123端口时间忽快忽慢硬件时钟问题检查主板电池更换CR2032电池播放盒时间不同步NTP客户端未启用在播放盒设置中手动启用NTP注意NTP同步不是一劳永逸的。工厂电网波动会导致工控机硬件时钟漂移建议每周检查一次chronyc tracking的输出确认时间偏差在可接受范围内。4.2 画面同步的三种技术方案对比多块大屏显示同一份数据画面同步有三种技术路线方案一HDMI分配器直连。渲染主机的HDMI输出接到分配器分配器分出多路HDMI信号到各屏幕。优点是零延迟、零配置插上就能用。缺点是传输距离受限超过15米信号衰减严重而且所有屏幕必须显示完全相同的内容无法单独控制某块屏。方案二网络推流。渲染主机把画面编码成H.264或H.265流通过网络推送给各播放盒。优点是传输距离不受限可以跨楼层甚至跨厂区。缺点是延迟较高而且编码解码会消耗CPU资源。方案三分布式渲染。每块屏配一台播放设备各自从后端拉取数据并渲染。优点是灵活性最高每块屏可以显示不同内容。缺点是维护成本高而且如果各设备渲染逻辑有细微差异会出现显示不一致。我们最终采用的是方案一和方案二的混合近距离的屏幕用HDMI分配器远距离的屏幕用网络推流。这个决策的依据是车间办公室和入口的屏幕距离渲染主机近走HDMI最稳定产线中段和质检区的屏幕距离远走网络推流更实际。网络推流的具体配置# 使用ffmpeg进行屏幕捕获和推流 ffmpeg -f x11grab -video_size 1920x1080 -framerate 30 -i :0.0 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -b:v 4M -maxrate 4M -bufsize 8M \ -f rtsp rtsp://192.168.1.100:8554/kanban-preset ultrafast和-tune zerolatency这两个参数是降低延迟的关键。-b:v 4M设置码率为4Mbps对于看板这种画面变化不大的场景4Mbps足够清晰。播放盒端用ffplay或者VLC接收RTSP流ffplay -fflags nobuffer -flags low_delay -framedrop \ rtsp://192.168.1.100:8554/kanban-fflags nobuffer禁用缓冲-flags low_delay启用低延迟模式-framedrop在解码跟不上时丢帧而不是卡顿。这三个参数组合下来端到端延迟可以控制在300ms以内。4.3 画面撕裂与不同步的排查实录调试阶段遇到的最诡异问题是两块相邻的大屏一块显示产量120另一块显示产量118而且持续了好几秒。操作工看到后直接找班组长说系统有问题。排查过程第一步确认数据源是否一致。检查后端日志发现同一时刻只推送了一次数据所有WebSocket客户端收到的都是120。说明数据源没问题。第二步检查播放盒的接收时间。在两块屏对应的播放盒上分别抓包发现一块播放盒在10:30:15收到数据另一块在10:30:18才收到。差了3秒。第三步排查网络延迟。用ping测试渲染主机到两个播放盒的延迟都在1ms以内。网络没问题。第四步检查播放盒的解码缓冲设置。发现其中一块播放盒的缓冲设置是默认的2000ms另一块被之前调试时改成了500ms。缓冲设置不同导致画面更新时机不一致。解决方法统一所有播放盒的缓冲设置为500ms并且在渲染主机端启用帧同步标记——每帧画面携带一个时间戳播放盒根据时间戳对齐显示。# 在ffmpeg推流时添加时间戳 ffmpeg -f x11grab -video_size 1920x1080 -framerate 30 -i :0.0 \ -c:v libx264 -preset ultrafast -tune zerolatency \ -b:v 4M -maxrate 4M -bufsize 8M \ -vf drawtexttext%{localtime}:fontsize24:fontcolorwhite:x10:y10 \ -f rtsp rtsp://192.168.1.100:8554/kanban这个drawtext滤镜在画面左上角叠加了本地时间播放盒端如果发现时间戳不一致可以自动调整缓冲。虽然增加了少量CPU开销但解决了同步问题。实操心得多屏同步问题80%出在缓冲设置不一致上。建议在项目初期就统一所有播放设备的缓冲参数并且把这个参数写进设备配置文档后期维护时不要随意改动。5. 看板前端开发与性能优化5.1 前端框架选型与页面布局看板前端不需要复杂的框架React或Vue都可以关键是轻量和稳定。我选的是Vue 3 Vite构建原因是Vue的响应式系统对于数据频繁更新的场景更友好而且打包体积比React小。页面布局采用栅格系统1920x1080的分辨率下划分成12列x8行。核心区域包括顶部状态栏显示当前时间、班次、系统状态左侧产量区各产线实时产量、目标产量、完成率中间设备状态区设备OEE、运行状态、故障报警右侧质量区良率、缺陷类型分布、返修数量底部滚动区异常事件滚动播报字体大小很关键。车间看板是给操作工在3-5米外看的正文至少24px关键数据至少48px标题至少36px。颜色对比度要足够高深色背景配浅色文字避免使用相近色。5.2 数据更新与渲染性能优化看板页面需要长时间运行内存泄漏和渲染性能是两大挑战。我做了这几件事第一虚拟DOM的更新频率控制。数据每500ms推送一次但并不是所有数据都需要每500ms更新。产量数据可以500ms更新设备状态可以2秒更新质量数据可以5秒更新。通过分组更新减少不必要的DOM操作。// 数据更新分组 const updateGroups { production: { interval: 500, lastUpdate: 0 }, equipment: { interval: 2000, lastUpdate: 0 }, quality: { interval: 5000, lastUpdate: 0 } }; function handleWebSocketMessage(data) { const now Date.now(); if (now - updateGroups.production.lastUpdate updateGroups.production.interval) { updateProductionDisplay(data.production); updateGroups.production.lastUpdate now; } if (now - updateGroups.equipment.lastUpdate updateGroups.equipment.interval) { updateEquipmentDisplay(data.equipment); updateGroups.equipment.lastUpdate now; } // 质量数据更新... }第二使用Canvas绘制图表。ECharts这类图表库在数据频繁更新时会产生大量DOM操作长时间运行后内存占用会持续上升。对于产量趋势图这种简单图表直接用Canvas绘制性能好很多。第三定期清理浏览器缓存。Chromium长时间运行后缓存和GPU内存会累积。我配置了一个定时任务每天凌晨3点自动重启浏览器# 在crontab中添加 0 3 * * * pkill chromium sleep 5 \ DISPLAY:0 chromium-browser --kiosk http://localhost:8080/kanban 这个操作会导致看板短暂黑屏约10秒但凌晨3点车间没有生产影响可以忽略。5.3 异常状态的可视化设计看板不只是显示正常数据更重要的是异常状态要醒目。我的设计原则是正常状态绿色或白色文字无背景色警告状态黄色文字浅黄色背景异常状态红色文字红色背景闪烁离线状态灰色文字显示数据延迟标记闪烁效果用CSS动画实现频率控制在1Hz左右太快了会让人眼疲劳keyframes alarm-blink { 0%, 100% { background-color: #ff4444; } 50% { background-color: #ff8888; } } .alarm-active { animation: alarm-blink 1s infinite; color: white; font-weight: bold; }报警声音是可选项。车间噪音大声音报警效果有限而且多个报警同时触发时声音会重叠。我们最终没有启用声音报警而是通过Andon灯系统做声音提示看板只负责视觉显示。6. 常见问题排查与调试技巧实录6.1 网络与通信类问题速查问题现象排查步骤常见原因解决方法看板显示连接失败1. ping渲染主机2. 检查WebSocket端口防火墙拦截开放8080端口数据更新延迟超过10秒1. 检查MES接口响应时间2. 查看后端日志MES接口超时增加超时时间启用缓存播放盒黑屏1. 检查RTSP流是否正常2. 检查播放盒网络推流中断重启ffmpeg推流进程画面卡顿1. 检查CPU占用2. 检查网络带宽编码参数过高降低码率或分辨率时间显示不一致1. 检查NTP同步状态2. 检查时区设置NTP未同步重新配置chrony6.2 显示与渲染类问题排查问题一大屏出现色差。两块相邻的屏幕同一张图片显示出来的颜色不一样。这是工业大屏常见问题原因是面板批次不同或者背光老化程度不同。解决方法进入大屏的工厂菜单调整RGB增益和偏移尽量让两块屏的颜色接近。如果色差太大只能更换同批次面板。问题二画面撕裂。快速移动的画面出现横向撕裂。这是垂直同步没开导致的。在渲染主机的显卡设置里启用垂直同步或者在ffmpeg推流时添加-vsync cfr参数强制恒定帧率。问题三文字模糊。看板上的文字边缘模糊看不清。检查分辨率设置确保渲染主机输出分辨率和屏幕物理分辨率一致。如果屏幕是4K但渲染主机输出1080P文字会被拉伸导致模糊。6.3 我踩过的三个大坑第一个坑NTP服务器地址写错。项目初期我随手填了一个NTP服务器地址结果那个地址已经失效了。chrony一直同步不上但系统没有报错只是时间慢慢漂移。过了两周才发现看板时间和实际时间差了3分钟。教训NTP配置完成后一定要用chronyc tracking验证同步状态确认System time的偏差在1秒以内。第二个坑WebSocket心跳缺失。看板运行了几天后发现有些屏幕的数据不更新了但WebSocket连接显示还是已连接。原因是中间的网络设备防火墙、负载均衡会主动断开长时间没有数据传输的连接。解决方法在前端和后端之间加心跳机制每30秒发送一个ping消息。// 前端心跳 setInterval(() { if (ws.readyState WebSocket.OPEN) { ws.send(JSON.stringify({ type: ping })); } }, 30000); // 后端响应 ws.on(message, (message) { const data JSON.parse(message); if (data.type ping) { ws.send(JSON.stringify({ type: pong })); } });第三个坑浏览器内存泄漏。Chromium连续运行一周后内存占用从500MB涨到了4GB页面开始卡顿。原因是看板页面里的某些JavaScript对象没有被正确回收。解决方法除了每天定时重启浏览器外还在页面里加了performance.memory监控当内存超过1GB时自动刷新页面。// 内存监控 setInterval(() { if (performance.memory) { const usedMB performance.memory.usedJSHeapSize / 1024 / 1024; if (usedMB 1024) { console.warn(内存占用过高: ${usedMB}MB即将刷新页面); location.reload(); } } }, 60000);6.4 调试工具与命令速查调试这个项目用到的工具和命令我整理了一份速查表# 检查NTP同步状态 chronyc tracking chronyc sources -v # 检查网络连通性 ping -c 4 192.168.1.100 traceroute 192.168.1.100 # 检查端口监听 netstat -tlnp | grep 8080 ss -tlnp | grep 8080 # 检查WebSocket连接 # 在浏览器控制台执行 ws.readyState // 1表示已连接 # 检查ffmpeg推流状态 ps aux | grep ffmpeg tail -f /var/log/ffmpeg.log # 检查系统资源 top -b -n 1 | head -20 free -h df -h网口调试助手在这个项目里主要用于测试MES接口和PLC网关的TCP通信。串口调试助手用于调试PLC的串口输出。这两个工具在Windows和Linux下都有替代品Linux下可以用ncnetcat和minicom。# 用nc测试TCP端口 nc -zv 192.168.1.100 8080 # 用nc发送HTTP请求 echo -e GET /api/v1/production HTTP/1.1\r\nHost: mes-server\r\n\r\n | nc mes-server 8080 # 用minicom调试串口 minicom -D /dev/ttyUSB0 -b 96006.5 上线后的运维建议看板系统上线后运维比开发更重要。我的建议是第一建立巡检制度。每天上班前检查所有屏幕是否正常显示数据是否更新。发现异常及时处理不要等到车间主任打电话来。第二保留回滚方案。每次更新看板程序前先备份当前版本。如果新版本有问题能在5分钟内回滚到旧版本。第三日志集中管理。渲染主机、播放盒、后端服务的日志统一收集到一个地方方便排查问题。我们用的是一个简单的ELK栈对于看板系统来说够用了。第四定期演练故障恢复。模拟MES宕机、网络中断、渲染主机故障等场景验证备用方案是否有效。我见过太多项目备用方案写在文档里但从来没测试过真出问题时发现备用方案根本跑不起来。这个项目从进场调试到稳定运行前后花了大约六周时间。其中硬件安装和布线一周MES接口对接两周多屏同步调试一周前端开发和优化一周试运行和问题修复一周。最大的体会是多屏同步的难点不在技术而在细节。NTP配置、缓冲设置、心跳机制每一个细节没做好都会导致现场出现问题。把这些细节做到位系统就能稳定运行。