1. 从一块屏到一面墙上海工厂看板项目的真实起点去年秋天我接到一个汽车零部件工厂的需求对方在松江的车间里已经跑了三年的MES系统但车间主任跟我抱怨说数据都在系统里可工人不看电脑班组长也不看电脑每天早会还是靠我拿个本子念昨天的产量。这句话基本就是整个项目的起点——数据不缺缺的是把数据推到人眼前的那块屏。这个项目最终落地的形态是车间主通道上方挂4块55寸工业大屏横向拼接成一面数据墙分别显示当日生产进度、设备OEE、质量异常看板和安灯呼叫状态。数据源来自工厂现有的MES数据库和PLC采集网关刷新频率要求做到秒级同步四块屏之间的数据不能出现这块显示1200件、那块显示1180件这种尴尬情况。关键词里出现的电子看板、大屏同步、MES、LED、NTP基本覆盖了这个项目的全部技术面。我写这篇东西是想把从需求确认、方案选型、同步机制设计到现场调试的完整链路讲清楚尤其是那些文档里不会写、只有蹲在现场才会遇到的坑。适合正在做工厂数字化看板、车间可视化项目的同行参考也适合工厂IT负责人判断供应商方案是否靠谱。先说一个反直觉的结论大屏同步这件事难点从来不在显示而在时间和数据一致性。很多人以为买几块屏、写个网页、投上去就完事了实际上四块屏各自独立渲染如果没有统一的时间基准和数据快照机制你看到的就是四个不同时刻的世界。2. 需求拆解车间到底需要看什么而不是能显示什么2.1 先搞清楚谁在看决定了显示什么很多看板项目失败的根本原因是IT部门按自己的理解做了一堆漂亮图表结果车间没人看。我在这个项目里做的第一件事不是画原型而是蹲在车间早会上听了三天。结论很明确一线操作工关心的是我这个工位今天要做多少、已经做了多少、还差多少、有没有异常要处理。班组长关心的是整条线的节拍达成率、哪个工位是瓶颈、异常响应了多久。车间主任/厂长关心的是当日总产出对比计划、设备综合效率、质量直通率。这三类人的关注点完全不同如果硬塞到一块屏上谁都看不清。所以最终方案是四块屏按角色分工而不是按数据类型分工。这个决策直接影响了后面的数据刷新策略——操作工那块屏需要秒级刷新厂长那块屏分钟级就够了。2.2 数据源盘点MES不是唯一来源项目正文里虽然没写但实际落地时数据源远比想象中杂。我整理了一张表这是现场调研后确认的真实数据来源看板模块数据来源采集方式刷新要求生产进度MES数据库直连只读库5秒设备OEEPLC 采集网关OPC UA / Modbus TCP10秒质量异常MES质检模块数据库轮询30秒安灯呼叫安灯硬件系统HTTP回调 轮询兜底实时3秒内这里有个关键判断不要试图让所有数据都走同一条链路。MES的数据走数据库直连最快PLC的数据必须经过采集网关做协议转换安灯系统本身有硬件按钮走事件推送最合理。强行统一反而会增加延迟和故障点。2.3 一个容易被忽略的需求断网了怎么办工厂网络不是实验室网络交换机重启、网线被叉车压断、MES升级维护这些都会发生。如果看板一断网就白屏车间主任第二天就会让你把屏拆了。所以我在方案里强制要求每块屏的播放端必须本地缓存最近一次成功获取的数据断网时显示数据更新于XX:XX并继续展示缓存内容而不是黑屏或报错。这个需求在合同里没写但如果没做验收时一定被挑刺。我见过太多项目栽在这个细节上。3. 大屏同步的核心机制NTP、数据快照与渲染节拍3.1 为什么NTP是同步的地基四块屏如果各自用自己的系统时间哪怕只差2秒在显示当前时间或数据更新时间时就会露馅。更严重的是如果数据刷新逻辑依赖本地时间做定时四块屏的刷新时刻会错开导致同一时刻屏幕上显示的是不同批次的数据。所以第一步是统一时间源。工厂内网通常没有外网访问方案是在内网部署一台NTP服务器所有看板播放端、采集网关、MES应用服务器全部指向这台内网NTP。如果工厂有华为云等云上资源也可以用云厂商提供的内网NTP服务地址做上游同步但车间设备必须指向内网那台避免外网抖动影响。Linux播放端的配置很简单# 编辑 /etc/systemd/timesyncd.conf 或 /etc/chrony.conf # 以chrony为例 server 192.168.10.5 iburst driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync配置完执行chronyc sources -v确认同步状态^*开头的那一行就是当前生效的时间源。Windows播放端则在注册表或命令行用w32tm配置w32tm /config /manualpeerlist:192.168.10.5 /syncfromflags:manual /reliable:yes /update w32tm /resync注意NTP同步不是配完就一劳永逸车间设备长期运行会有时钟漂移建议在播放端加一个定时任务每天凌晨强制校时一次并把校时结果写日志方便排查。3.2 数据快照让四块屏看到同一个瞬间时间统一了接下来是数据一致性。假设四块屏各自去查MES数据库查询语句执行时间不同返回的数据可能来自不同时刻。解决办法是引入数据快照层。具体做法后端服务每隔固定周期比如5秒从各数据源拉取一次数据生成一个带时间戳的JSON快照推送到一个共享的缓存Redis或内存队列。四块屏的播放端不直接查数据库而是订阅这个快照。这样无论多少块屏看到的都是同一份数据、同一个时间戳。{ snapshot_time: 2024-10-15T14:32:0508:00, production: {plan: 1200, actual: 876, line: A线}, oee: {value: 82.3, availability: 91.2, performance: 94.5}, quality: {pass_rate: 98.7, abnormal_count: 3} }这个设计的好处是同步问题从多端一致简化成了单点生成、多点消费。播放端只需要保证自己渲染的是最新快照即可不需要关心数据从哪来。3.3 渲染节拍对齐别让动画效果破坏同步感即使数据快照一致如果四块屏的渲染时机不同视觉上还是会有不同步的感觉。比如A屏的数字滚动动画刚开始B屏已经滚完了。所以我在播放端做了渲染节拍对齐所有播放端监听同一个快照推送通道收到快照后不立即渲染而是等待下一个整5秒边界再统一触发动画时长固定为800毫秒确保在下一个快照到来前完成。这套机制实测下来四块屏之间的视觉差异控制在100毫秒以内人眼基本感知不到。4. 播放端选型与硬件踩坑实录4.1 播放端到底用什么工控机、盒子还是树莓派这是被问得最多的问题。我三个方案都实际跑过直接给结论方案成本稳定性维护难度适用场景工控机x86高高低7x24长期运行推荐安卓播放盒低中中预算有限单屏简单展示树莓派中中高高有技术团队愿意折腾这个项目最终选了工控机原因很实际车间环境粉尘大、温度波动大安卓盒子跑半年后普遍出现发热降频、自动重启的问题。工控机虽然贵但胜在稳定而且x86架构跑浏览器内核兼容性最好不会出现某些CSS动画在安卓盒子上卡顿的情况。4.2 浏览器选型与Kiosk模式播放端本质就是一个全屏浏览器。我用的是Chromium内核的浏览器配置成Kiosk模式开机自启# Linux下启动命令示例 chromium-browser --kiosk --noerrdialogs --disable-infobars \ --disable-session-crashed-bubble --incognito \ http://192.168.10.20:8080/board/line-a几个关键参数说明--kiosk是全屏无边框--incognito避免缓存导致页面不更新--disable-session-crashed-bubble防止崩溃提示遮挡画面。这些参数看着琐碎但少一个都可能在现场出问题。踩坑提醒Chromium长时间运行会有内存泄漏尤其是页面里有大量动画和定时器时。我的做法是加一个守护脚本检测浏览器进程内存超过阈值就自动重启同时页面本身也做了定时刷新每2小时整点刷新一次双保险。4.3 大屏拼接的物理细节四块屏横向拼接物理上要注意两点一是边框宽度拼接后中间会有黑边设计页面时要把关键信息避开拼接缝二是色彩一致性不同批次的面板色温会有差异最好同批次采购并在播放端做统一的色彩校准。另外大屏的亮度要按车间光照调整。白天车间光线强亮度要拉高夜班光线暗亮度要降下来否则工人盯着看一天眼睛受不了。这个可以通过播放端定时切换CSS主题或调用屏幕的亮度接口实现。5. 数据链路搭建从MES到屏幕的完整通路5.1 MES数据读取只读账号是底线直连MES数据库读取数据时必须使用只读账号这是铁律。我见过有项目用MES的应用账号去查数据结果一条慢查询把MES主库拖垮整条产线停线。只读账号 独立从库 查询超时限制这三条缺一不可。查询语句也要注意不要写复杂的多表关联能走索引就走索引。看板查询的特点是频率高、数据量小所以更适合预计算让MES侧或中间层定时把看板需要的数据算好写进一张结果表看板只查这张结果表查询压力几乎为零。5.2 PLC数据采集OPC UA还是Modbus设备OEE数据来自PLC采集方式取决于PLC型号。新一点的设备支持OPC UA直接订阅变量即可老设备只有Modbus TCP需要轮询寄存器地址。这个项目两种都有所以采集网关同时跑了两套协议。Modbus轮询有个坑轮询频率不能太高。有些老PLC的通信处理能力有限你1秒轮询一次它可能就响应不过来了导致数据丢包甚至PLC通信模块死机。我的经验是Modbus轮询间隔不低于500毫秒且要加超时重试和失败告警。5.3 安灯系统的实时性处理安灯呼叫要求3秒内上屏这个实时性用数据库轮询很难保证。方案是安灯硬件系统在按钮触发时主动发HTTP请求到看板后端后端收到后立即生成快照并推送。同时保留一个10秒的轮询兜底防止HTTP请求丢失导致状态不同步。这里有个细节安灯状态是有状态的呼叫、响应、解除是三个不同状态后端要维护状态机不能简单地收到请求就显示红色。我见过有看板把安灯做成了按一下亮、再按一下灭结果工人按了呼叫没人响应屏幕上却显示正常这是典型的逻辑错误。6. 现场调试那些文档里不会写的问题6.1 屏幕闪烁与LED驱动的关系关键词里出现了LED驱动芯片消隐时间led闪灯驱动芯片这些词说明有人在做LED相关的看板。这里要区分清楚大屏拼接用的是LCD/LED显示屏和单颗LED灯珠的驱动完全是两回事。但车间里确实经常有LED安灯灯珠、LED状态指示灯这些和看板是配合关系。如果看板旁边有LED安灯灯柱要注意消隐时间的问题。LED驱动芯片在切换显示内容时如果消隐时间设置不当会出现鬼影——上一个状态的颜色残留。这个在安灯灯柱上表现为红灯灭了但还有微弱红光工人会误判状态。解决办法是选用带消隐功能的驱动芯片或在驱动电路上增加放电回路。6.2 网络抖动导致的画面卡顿车间网络最大的问题是抖动不是断而是时通时断。看板页面如果每次数据请求失败就报错画面会频繁闪烁。我的处理方式是前端请求加超时3秒和重试2次请求失败时不改变画面只更新角落的数据延迟提示连续失败超过5次才显示网络异常横幅。这样即使网络抖动画面也是稳定的只是数据更新慢一点不会让工人觉得系统坏了。6.3 早会高峰期的并发压力每天早上7:50到8:10是车间早会时间所有人都在看大屏这时候如果后端有定时任务在跑或者有人同时用手机访问看板页面就可能出现卡顿。我的做法是给看板数据通道做优先级隔离看板的快照推送走独立线程和独立连接池不和普通Web请求抢资源。另外早会前5分钟7:45做一次强制数据刷新确保早会开始时屏幕上是最新数据。这个定时任务要写在配置里方便不同车间按自己的早会时间调整。7. 上线后的运维让看板活过第一年7.1 监控看板本身看板系统自己也需要被监控。我部署了一个轻量的监控脚本每隔1分钟检查四块屏的播放端是否在线HTTP心跳快照生成服务是否正常检查最新快照时间戳各数据源连接是否正常。任何一项异常通过企业微信或短信告警给IT值班人员。不要等车间打电话来说屏黑了你才知道那时候已经被动了。7.2 数据准确性的人工校验自动化监控只能发现系统挂了发现不了数据错了。所以每周要安排一次人工校验拿看板上的产量数字和MES报表对一遍拿OEE数字和手工统计对一遍。我遇到过采集网关的寄存器地址配错导致OEE一直显示100%系统运行正常但数据是假的这种问题只有人工比对才能发现。7.3 版本管理与回滚看板页面和后端服务都要做版本管理。每次更新前先备份当前版本更新后观察至少一个班次8小时再确认。车间系统不像互联网产品可以随时热修一次错误的更新可能导致整条线的看板不可用影响生产节奏。8. 关于成本与周期的实话最后说点实在的。这个项目从调研到验收总共用了6周硬件成本4块55寸工业屏 4台工控机 采集网关 网络改造大约在8到10万软件开发和调试人力另算。如果预算紧张可以先做一块屏试点跑通数据链路后再扩展这样风险最小。我不建议一上来就追求炫酷的可视化效果。车间看板的第一原则是看得清、看得懂、看得准动画和特效是加分项不是必选项。我见过太多项目把钱花在了3D数字孪生上结果基础的生产进度数字还经常对不上这就本末倒置了。真正让这个项目被车间接受的不是技术多先进而是有一天车间主任跟我说现在早会不用我念数字了大家抬头看屏就行。这句话比任何验收报告都有说服力。
工厂大屏数据看板同步实战：NTP、数据快照与MES集成
1. 从一块屏到一面墙上海工厂看板项目的真实起点去年秋天我接到一个汽车零部件工厂的需求对方在松江的车间里已经跑了三年的MES系统但车间主任跟我抱怨说数据都在系统里可工人不看电脑班组长也不看电脑每天早会还是靠我拿个本子念昨天的产量。这句话基本就是整个项目的起点——数据不缺缺的是把数据推到人眼前的那块屏。这个项目最终落地的形态是车间主通道上方挂4块55寸工业大屏横向拼接成一面数据墙分别显示当日生产进度、设备OEE、质量异常看板和安灯呼叫状态。数据源来自工厂现有的MES数据库和PLC采集网关刷新频率要求做到秒级同步四块屏之间的数据不能出现这块显示1200件、那块显示1180件这种尴尬情况。关键词里出现的电子看板、大屏同步、MES、LED、NTP基本覆盖了这个项目的全部技术面。我写这篇东西是想把从需求确认、方案选型、同步机制设计到现场调试的完整链路讲清楚尤其是那些文档里不会写、只有蹲在现场才会遇到的坑。适合正在做工厂数字化看板、车间可视化项目的同行参考也适合工厂IT负责人判断供应商方案是否靠谱。先说一个反直觉的结论大屏同步这件事难点从来不在显示而在时间和数据一致性。很多人以为买几块屏、写个网页、投上去就完事了实际上四块屏各自独立渲染如果没有统一的时间基准和数据快照机制你看到的就是四个不同时刻的世界。2. 需求拆解车间到底需要看什么而不是能显示什么2.1 先搞清楚谁在看决定了显示什么很多看板项目失败的根本原因是IT部门按自己的理解做了一堆漂亮图表结果车间没人看。我在这个项目里做的第一件事不是画原型而是蹲在车间早会上听了三天。结论很明确一线操作工关心的是我这个工位今天要做多少、已经做了多少、还差多少、有没有异常要处理。班组长关心的是整条线的节拍达成率、哪个工位是瓶颈、异常响应了多久。车间主任/厂长关心的是当日总产出对比计划、设备综合效率、质量直通率。这三类人的关注点完全不同如果硬塞到一块屏上谁都看不清。所以最终方案是四块屏按角色分工而不是按数据类型分工。这个决策直接影响了后面的数据刷新策略——操作工那块屏需要秒级刷新厂长那块屏分钟级就够了。2.2 数据源盘点MES不是唯一来源项目正文里虽然没写但实际落地时数据源远比想象中杂。我整理了一张表这是现场调研后确认的真实数据来源看板模块数据来源采集方式刷新要求生产进度MES数据库直连只读库5秒设备OEEPLC 采集网关OPC UA / Modbus TCP10秒质量异常MES质检模块数据库轮询30秒安灯呼叫安灯硬件系统HTTP回调 轮询兜底实时3秒内这里有个关键判断不要试图让所有数据都走同一条链路。MES的数据走数据库直连最快PLC的数据必须经过采集网关做协议转换安灯系统本身有硬件按钮走事件推送最合理。强行统一反而会增加延迟和故障点。2.3 一个容易被忽略的需求断网了怎么办工厂网络不是实验室网络交换机重启、网线被叉车压断、MES升级维护这些都会发生。如果看板一断网就白屏车间主任第二天就会让你把屏拆了。所以我在方案里强制要求每块屏的播放端必须本地缓存最近一次成功获取的数据断网时显示数据更新于XX:XX并继续展示缓存内容而不是黑屏或报错。这个需求在合同里没写但如果没做验收时一定被挑刺。我见过太多项目栽在这个细节上。3. 大屏同步的核心机制NTP、数据快照与渲染节拍3.1 为什么NTP是同步的地基四块屏如果各自用自己的系统时间哪怕只差2秒在显示当前时间或数据更新时间时就会露馅。更严重的是如果数据刷新逻辑依赖本地时间做定时四块屏的刷新时刻会错开导致同一时刻屏幕上显示的是不同批次的数据。所以第一步是统一时间源。工厂内网通常没有外网访问方案是在内网部署一台NTP服务器所有看板播放端、采集网关、MES应用服务器全部指向这台内网NTP。如果工厂有华为云等云上资源也可以用云厂商提供的内网NTP服务地址做上游同步但车间设备必须指向内网那台避免外网抖动影响。Linux播放端的配置很简单# 编辑 /etc/systemd/timesyncd.conf 或 /etc/chrony.conf # 以chrony为例 server 192.168.10.5 iburst driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync配置完执行chronyc sources -v确认同步状态^*开头的那一行就是当前生效的时间源。Windows播放端则在注册表或命令行用w32tm配置w32tm /config /manualpeerlist:192.168.10.5 /syncfromflags:manual /reliable:yes /update w32tm /resync注意NTP同步不是配完就一劳永逸车间设备长期运行会有时钟漂移建议在播放端加一个定时任务每天凌晨强制校时一次并把校时结果写日志方便排查。3.2 数据快照让四块屏看到同一个瞬间时间统一了接下来是数据一致性。假设四块屏各自去查MES数据库查询语句执行时间不同返回的数据可能来自不同时刻。解决办法是引入数据快照层。具体做法后端服务每隔固定周期比如5秒从各数据源拉取一次数据生成一个带时间戳的JSON快照推送到一个共享的缓存Redis或内存队列。四块屏的播放端不直接查数据库而是订阅这个快照。这样无论多少块屏看到的都是同一份数据、同一个时间戳。{ snapshot_time: 2024-10-15T14:32:0508:00, production: {plan: 1200, actual: 876, line: A线}, oee: {value: 82.3, availability: 91.2, performance: 94.5}, quality: {pass_rate: 98.7, abnormal_count: 3} }这个设计的好处是同步问题从多端一致简化成了单点生成、多点消费。播放端只需要保证自己渲染的是最新快照即可不需要关心数据从哪来。3.3 渲染节拍对齐别让动画效果破坏同步感即使数据快照一致如果四块屏的渲染时机不同视觉上还是会有不同步的感觉。比如A屏的数字滚动动画刚开始B屏已经滚完了。所以我在播放端做了渲染节拍对齐所有播放端监听同一个快照推送通道收到快照后不立即渲染而是等待下一个整5秒边界再统一触发动画时长固定为800毫秒确保在下一个快照到来前完成。这套机制实测下来四块屏之间的视觉差异控制在100毫秒以内人眼基本感知不到。4. 播放端选型与硬件踩坑实录4.1 播放端到底用什么工控机、盒子还是树莓派这是被问得最多的问题。我三个方案都实际跑过直接给结论方案成本稳定性维护难度适用场景工控机x86高高低7x24长期运行推荐安卓播放盒低中中预算有限单屏简单展示树莓派中中高高有技术团队愿意折腾这个项目最终选了工控机原因很实际车间环境粉尘大、温度波动大安卓盒子跑半年后普遍出现发热降频、自动重启的问题。工控机虽然贵但胜在稳定而且x86架构跑浏览器内核兼容性最好不会出现某些CSS动画在安卓盒子上卡顿的情况。4.2 浏览器选型与Kiosk模式播放端本质就是一个全屏浏览器。我用的是Chromium内核的浏览器配置成Kiosk模式开机自启# Linux下启动命令示例 chromium-browser --kiosk --noerrdialogs --disable-infobars \ --disable-session-crashed-bubble --incognito \ http://192.168.10.20:8080/board/line-a几个关键参数说明--kiosk是全屏无边框--incognito避免缓存导致页面不更新--disable-session-crashed-bubble防止崩溃提示遮挡画面。这些参数看着琐碎但少一个都可能在现场出问题。踩坑提醒Chromium长时间运行会有内存泄漏尤其是页面里有大量动画和定时器时。我的做法是加一个守护脚本检测浏览器进程内存超过阈值就自动重启同时页面本身也做了定时刷新每2小时整点刷新一次双保险。4.3 大屏拼接的物理细节四块屏横向拼接物理上要注意两点一是边框宽度拼接后中间会有黑边设计页面时要把关键信息避开拼接缝二是色彩一致性不同批次的面板色温会有差异最好同批次采购并在播放端做统一的色彩校准。另外大屏的亮度要按车间光照调整。白天车间光线强亮度要拉高夜班光线暗亮度要降下来否则工人盯着看一天眼睛受不了。这个可以通过播放端定时切换CSS主题或调用屏幕的亮度接口实现。5. 数据链路搭建从MES到屏幕的完整通路5.1 MES数据读取只读账号是底线直连MES数据库读取数据时必须使用只读账号这是铁律。我见过有项目用MES的应用账号去查数据结果一条慢查询把MES主库拖垮整条产线停线。只读账号 独立从库 查询超时限制这三条缺一不可。查询语句也要注意不要写复杂的多表关联能走索引就走索引。看板查询的特点是频率高、数据量小所以更适合预计算让MES侧或中间层定时把看板需要的数据算好写进一张结果表看板只查这张结果表查询压力几乎为零。5.2 PLC数据采集OPC UA还是Modbus设备OEE数据来自PLC采集方式取决于PLC型号。新一点的设备支持OPC UA直接订阅变量即可老设备只有Modbus TCP需要轮询寄存器地址。这个项目两种都有所以采集网关同时跑了两套协议。Modbus轮询有个坑轮询频率不能太高。有些老PLC的通信处理能力有限你1秒轮询一次它可能就响应不过来了导致数据丢包甚至PLC通信模块死机。我的经验是Modbus轮询间隔不低于500毫秒且要加超时重试和失败告警。5.3 安灯系统的实时性处理安灯呼叫要求3秒内上屏这个实时性用数据库轮询很难保证。方案是安灯硬件系统在按钮触发时主动发HTTP请求到看板后端后端收到后立即生成快照并推送。同时保留一个10秒的轮询兜底防止HTTP请求丢失导致状态不同步。这里有个细节安灯状态是有状态的呼叫、响应、解除是三个不同状态后端要维护状态机不能简单地收到请求就显示红色。我见过有看板把安灯做成了按一下亮、再按一下灭结果工人按了呼叫没人响应屏幕上却显示正常这是典型的逻辑错误。6. 现场调试那些文档里不会写的问题6.1 屏幕闪烁与LED驱动的关系关键词里出现了LED驱动芯片消隐时间led闪灯驱动芯片这些词说明有人在做LED相关的看板。这里要区分清楚大屏拼接用的是LCD/LED显示屏和单颗LED灯珠的驱动完全是两回事。但车间里确实经常有LED安灯灯珠、LED状态指示灯这些和看板是配合关系。如果看板旁边有LED安灯灯柱要注意消隐时间的问题。LED驱动芯片在切换显示内容时如果消隐时间设置不当会出现鬼影——上一个状态的颜色残留。这个在安灯灯柱上表现为红灯灭了但还有微弱红光工人会误判状态。解决办法是选用带消隐功能的驱动芯片或在驱动电路上增加放电回路。6.2 网络抖动导致的画面卡顿车间网络最大的问题是抖动不是断而是时通时断。看板页面如果每次数据请求失败就报错画面会频繁闪烁。我的处理方式是前端请求加超时3秒和重试2次请求失败时不改变画面只更新角落的数据延迟提示连续失败超过5次才显示网络异常横幅。这样即使网络抖动画面也是稳定的只是数据更新慢一点不会让工人觉得系统坏了。6.3 早会高峰期的并发压力每天早上7:50到8:10是车间早会时间所有人都在看大屏这时候如果后端有定时任务在跑或者有人同时用手机访问看板页面就可能出现卡顿。我的做法是给看板数据通道做优先级隔离看板的快照推送走独立线程和独立连接池不和普通Web请求抢资源。另外早会前5分钟7:45做一次强制数据刷新确保早会开始时屏幕上是最新数据。这个定时任务要写在配置里方便不同车间按自己的早会时间调整。7. 上线后的运维让看板活过第一年7.1 监控看板本身看板系统自己也需要被监控。我部署了一个轻量的监控脚本每隔1分钟检查四块屏的播放端是否在线HTTP心跳快照生成服务是否正常检查最新快照时间戳各数据源连接是否正常。任何一项异常通过企业微信或短信告警给IT值班人员。不要等车间打电话来说屏黑了你才知道那时候已经被动了。7.2 数据准确性的人工校验自动化监控只能发现系统挂了发现不了数据错了。所以每周要安排一次人工校验拿看板上的产量数字和MES报表对一遍拿OEE数字和手工统计对一遍。我遇到过采集网关的寄存器地址配错导致OEE一直显示100%系统运行正常但数据是假的这种问题只有人工比对才能发现。7.3 版本管理与回滚看板页面和后端服务都要做版本管理。每次更新前先备份当前版本更新后观察至少一个班次8小时再确认。车间系统不像互联网产品可以随时热修一次错误的更新可能导致整条线的看板不可用影响生产节奏。8. 关于成本与周期的实话最后说点实在的。这个项目从调研到验收总共用了6周硬件成本4块55寸工业屏 4台工控机 采集网关 网络改造大约在8到10万软件开发和调试人力另算。如果预算紧张可以先做一块屏试点跑通数据链路后再扩展这样风险最小。我不建议一上来就追求炫酷的可视化效果。车间看板的第一原则是看得清、看得懂、看得准动画和特效是加分项不是必选项。我见过太多项目把钱花在了3D数字孪生上结果基础的生产进度数字还经常对不上这就本末倒置了。真正让这个项目被车间接受的不是技术多先进而是有一天车间主任跟我说现在早会不用我念数字了大家抬头看屏就行。这句话比任何验收报告都有说服力。
