企业官网建设流程全解析

1. 从一块屏到一面墙：上海工厂看板项目的真实起点

去年秋天，我接到一个汽车零部件工厂的需求，对方在松江的车间里已经跑了三年的MES系统，但车间主任跟我抱怨说："数据都在系统里，可工人不看电脑，班组长也不看电脑，每天早会还是靠我拿个本子念昨天的产量。"这句话基本就是整个项目的起点——数据不缺，缺的是把数据推到人眼前的那块屏。

这个项目最终落地的形态是：车间主通道上方挂4块55寸工业大屏，横向拼接成一面"数据墙"，分别显示当日生产进度、设备OEE、质量异常看板和安灯呼叫状态。数据源来自工厂现有的MES数据库和PLC采集网关，刷新频率要求做到秒级同步，四块屏之间的数据不能出现"这块显示1200件、那块显示1180件"这种尴尬情况。

关键词里出现的电子看板、大屏同步、MES、LED、NTP，基本覆盖了这个项目的全部技术面。我写这篇东西，是想把从需求确认、方案选型、同步机制设计到现场调试的完整链路讲清楚，尤其是那些文档里不会写、只有蹲在现场才会遇到的坑。适合正在做工厂数字化看板、车间可视化项目的同行参考，也适合工厂IT负责人判断供应商方案是否靠谱。

先说一个反直觉的结论：大屏同步这件事，难点从来不在"显示"，而在"时间"和"数据一致性"。很多人以为买几块屏、写个网页、投上去就完事了，实际上四块屏各自独立渲染，如果没有统一的时间基准和数据快照机制，你看到的就是四个不同时刻的世界。

2. 需求拆解：车间到底需要看什么，而不是能显示什么

2.1 先搞清楚"谁在看"决定了"显示什么"

很多看板项目失败的根本原因，是IT部门按自己的理解做了一堆漂亮图表，结果车间没人看。我在这个项目里做的第一件事不是画原型，而是蹲在车间早会上听了三天。结论很明确：

• 一线操作工关心的是：我这个工位今天要做多少、已经做了多少、还差多少、有没有异常要处理。
• 班组长关心的是：整条线的节拍达成率、哪个工位是瓶颈、异常响应了多久。
• 车间主任/厂长关心的是：当日总产出对比计划、设备综合效率、质量直通率。

这三类人的关注点完全不同，如果硬塞到一块屏上，谁都看不清。所以最终方案是四块屏按角色分工，而不是按数据类型分工。这个决策直接影响了后面的数据刷新策略——操作工那块屏需要秒级刷新，厂长那块屏分钟级就够了。

2.2 数据源盘点：MES不是唯一来源

项目正文里虽然没写，但实际落地时数据源远比想象中杂。我整理了一张表，这是现场调研后确认的真实数据来源：

这里有个关键判断：不要试图让所有数据都走同一条链路。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:05+08: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架构跑浏览器内核兼容性最好，不会出现某些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数字孪生上，结果基础的生产进度数字还经常对不上，这就本末倒置了。

真正让这个项目被车间接受的，不是技术多先进，而是有一天车间主任跟我说："现在早会不用我念数字了，大家抬头看屏就行。"这句话比任何验收报告都有说服力。