工厂车间可视化电子看板：多屏同步与MES数据采集落地实践

1. 项目缘起与整体设计思路

1.1 为什么要在工厂里搞可视化电子看板

我在制造业信息化这行摸爬滚打十来年，进过汽车零部件厂、电子代工厂、精密五金厂，几乎每一家做到一定规模之后都会遇到同一个问题：车间里的数据是"死"的。生产进度靠班组长拿本子记，设备状态靠人巡检，良率数据要等下班后文员录入Excel，第二天早上开会才能看到昨天的结果。信息滞后至少半天，异常发现全靠运气。

可视化电子看板要解决的就是这个"信息时差"。它的本质是把MES、设备PLC、传感器里的实时数据抽出来，经过清洗和聚合，推到大屏上滚动显示，让车间里所有人抬头就能看到当前产量、良率、设备稼动率、异常工单。上海这边很多工厂的车间面积大、产线分散，单块屏幕根本覆盖不过来，所以实际落地时往往是"多块大屏同步显示"——装配区一块、注塑区一块、质检区一块、办公区一块，数据源统一，展示内容按区域定制。

这个项目适合谁参考？如果你是企业IT、自动化工程师、MES实施顾问，或者正在被老板要求"搞个看板出来"的技术负责人，这篇内容基本能覆盖你从选型到调试落地的全流程。我不讲虚的，只讲我实际踩过的坑和验证过的方案。

1.2 整体架构怎么搭：三层结构最稳

看板系统看起来简单，无非是"取数—传输—显示"，但真做起来，架构设计决定了后期维护是轻松还是痛苦。我推荐三层结构：

数据采集层负责从MES数据库、PLC、串口设备、OPC UA服务端拿数据。这一层的关键是"解耦"——不要让看板程序直接去查MES的生产库，因为MES库的负载本来就高，你再加几十个看板轮询查询，DBA会来找你麻烦。正确做法是建一个中间库或者用消息队列做缓冲。

数据处理层做数据清洗、聚合、计算。比如MES里存的是每道工序的过站记录，看板要显示的是"今日累计产量"，这就需要按班次、按产线做聚合。这一层我一般用定时任务或者流处理来做，频率控制在5到15秒一次，太快没必要，太慢看板就不"活"了。

展示层就是大屏端。多块大屏同步的核心难点在这里：如何保证所有屏幕显示的数据一致、刷新同步、不闪烁。我的方案是"统一数据源+统一推送"，所有屏幕订阅同一个数据接口，由服务端主动推送，而不是各屏幕自己去轮询。

提示：架构设计阶段一定要和车间主任、班组长聊清楚他们到底想看什么。我见过太多项目，IT部门闷头做了三个月，上线后发现车间想看的是"当前工单还差多少件"，而系统显示的是"本月累计良率"，完全对不上需求。

1.3 技术选型背后的取舍逻辑

选型这块我踩过不少坑，说几个关键决策点。

数据采集方式：MES如果提供WebService或REST接口，优先用接口取数，稳定且不侵入。如果MES是老系统只有数据库，那就走中间库同步。设备层如果支持OPC UA最好，不支持就用Modbus TCP或者串口转网口模块。上海很多老厂房的设备还是RS232/RS485串口，这时候串口调试助手和网口调试助手就是你的救命工具。

通信协议：看板推送我强烈推荐WebSocket，而不是HTTP轮询。HTTP轮询的问题是每块屏幕都在独立请求，10块屏幕就是10倍压力，而且刷新时间不同步，会出现"这块屏显示100，那块屏显示98"的尴尬。WebSocket由服务端统一推送，所有屏幕同一时刻收到同一份数据，天然同步。

时间同步：这是最容易被忽视但最致命的点。多块大屏如果系统时间不一致，显示的时间戳就会打架，车间的人会质疑数据准确性。必须部署NTP服务，所有看板终端、服务器、采集网关统一对时。Linux下部署NTP服务器是标准操作，Windows端用系统自带的时间同步指向内网NTP服务器即可。

前端框架：大屏展示不需要复杂的SPA框架，Vue或者原生JS配合ECharts就够了。关键是做好自适应和防内存泄漏，因为看板是7x24小时运行的，内存泄漏跑几天就卡死了。

2. 核心细节解析与实操要点

2.1 数据采集：从MES到看板中间库

MES系统是整个看板的数据源头。不管你的MES是商业产品还是开源的，核心数据都逃不出这几类：工单信息、过站记录、设备状态、质量数据。我一般会在MES数据库之外建一个独立的看板库，通过定时任务做增量同步。

增量同步的关键是找到"增量标识"。大多数MES的过站记录表都有自增ID或者时间戳字段，用这两个做水位线最靠谱。我常用的策略是记录上次同步的最大ID，每次只取大于这个ID的记录。代码逻辑大概是这样：

# 增量同步核心逻辑示意 last_id = get_last_sync_id() new_records = query_mes("SELECT * FROM station_log WHERE id > %s ORDER BY id", last_id) if new_records: batch_insert_kanban_db(new_records) update_last_sync_id(new_records[-1].id)

这里有个坑：如果MES的过站记录会被修改（比如返工返修后更新状态），单纯靠ID增量就会漏掉更新。汽车水冷板这类产品的MES返工返修模块尤其要注意，返工记录往往是"插入新记录+更新原记录"的组合操作。我的做法是对关键表加一个update_time字段的增量窗口，每次同步最近15分钟内被修改过的记录，做一次幂等写入。

注意：同步频率不要设得太激进。我见过有人设成1秒一次，结果MES数据库CPU直接飙到90%。一般5到10秒一次足够看板使用，车间又不是炒股，不需要毫秒级实时。

2.2 多屏同步的核心机制：服务端推送

多块大屏同步显示，说起来简单，做起来有几个层次的问题要解决。

第一层是数据一致性。所有屏幕必须拿到同一份数据。如果每块屏幕各自去查数据库，由于查询时间点不同，结果必然有差异。解决方案是服务端定时取一次数据，缓存起来，然后广播给所有连接的客户端。

第二层是刷新同步。理想状态下所有屏幕应该在同一时刻刷新。WebSocket广播天然满足这一点，服务端一次推送，所有客户端同时收到。但要注意客户端的渲染时间可能有微小差异，对于数字滚动动画这类效果，可以在推送消息里带一个"生效时间戳"，客户端根据这个时间戳对齐动画起始点。

第三层是断线重连。车间网络环境复杂，网线被叉车压断、交换机重启都是常事。客户端必须实现自动重连，重连后要能补齐断线期间的数据。我的做法是服务端维护一个最近N条消息的环形缓冲区，客户端重连时带上最后收到的消息序号，服务端把缺失的消息补发过去。

// 客户端WebSocket重连与补数据示意 let lastSeq = 0; function connect() { const ws = new WebSocket('ws://kanban-server:8080/ws'); ws.onopen = () => ws.send(JSON.stringify({type: 'resume', seq: lastSeq})); ws.onmessage = (e) => { const msg = JSON.parse(e.data); lastSeq = msg.seq; render(msg.data); }; ws.onclose = () => setTimeout(connect, 3000); }

2.3 时间同步：NTP部署不能省

多块大屏时间不一致，是看板项目里最隐蔽的bug。表面上看每块屏都在正常显示，但细心的车间主任会发现"这块屏的产量数字比那块屏晚了几秒"，进而怀疑整个系统的可靠性。

NTP部署分两步。第一步是在内网找一台服务器做NTP Server，Linux下用chrony或者ntpd都行。配置文件里指定上游时间源，如果工厂内网完全隔离，可以用本地时钟做基准，但精度会差一些。第二步是所有看板终端、采集网关、数据库服务器都指向这台内网NTP Server。

# Linux下chrony服务端配置示意 # /etc/chrony.conf server ntp.aliyun.com iburst allow 192.168.1.0/24 local stratum 10

Windows终端同步很简单，命令行执行w32tm /config /manualpeerlist:"192.168.1.100" /syncfromflags:manual /update，然后重启时间服务即可。看板程序启动时最好也做一次时间校验，如果本地时间和服务器偏差超过阈值，在界面上给出警告。

提示：华为云、阿里云都有公网NTP服务器地址，但工厂内网通常不允许访问外网。所以内网NTP Server是必须的，不要指望每台设备自己去连公网。

3. 实操过程与核心环节实现

3.1 环境准备与基础服务搭建

正式动手之前，先把环境理清楚。我以一台典型的看板服务器为例，配置不用太高，4核8G足够跑几十块屏幕的数据推送。

操作系统我习惯用Ubuntu Server 22.04 LTS，稳定且社区支持好。基础服务包括：MySQL或者PostgreSQL做看板中间库、Redis做数据缓存和消息队列、Nginx做前端静态资源服务、Node.js或者Java做WebSocket推送服务。

数据库建表这块，看板中间库不需要太复杂的范式设计，反而要适当冗余，因为看板查询都是"读多写少"，查询性能优先。我一般会建几张核心表：产线实时状态表、工单进度表、质量统计表、设备稼动表。每张表都带一个update_time字段，方便前端做数据新鲜度判断。

Redis在这里的角色很关键。看板服务每次从数据库取完数据后，写入Redis并设置较短的过期时间。WebSocket推送服务直接从Redis读数据广播，避免频繁查库。同时Redis的发布订阅机制可以用来做多实例部署时的消息分发。

3.2 数据采集程序开发与调试

采集程序我一般用Python写，因为对接各种数据源方便，MES的WebService、数据库、OPC UA、Modbus都有成熟的库。

对接MES WebService时，先用网口调试助手确认接口地址和端口通不通，再用Postman或者curl测试接口返回。我遇到过MES接口返回的JSON里时间字段是"2024-01-15T08:30:00+08:00"这种带时区的格式，而看板需要的是本地时间，这里要做转换，否则显示会差8小时。

对接PLC和串口设备时，串口调试助手是必备工具。先用它确认波特率、数据位、停止位、校验位这些参数对不对，能收到正确数据了再写代码。我踩过的坑是：有些设备的串口参数文档写的是9600-8-N-1，实际却是9600-7-E-1，用调试助手一试就露馅了。

# Modbus TCP采集示意 from pymodbus.client import ModbusTcpClient client = ModbusTcpClient('192.168.1.50', port=502) result = client.read_holding_registers(address=100, count=10, slave=1) if not result.isError(): process_data(result.registers)

采集程序一定要加日志，而且要分级别。正常采集记DEBUG，数据异常记WARN，连接失败记ERROR。日志按天切割，保留30天。我见过采集程序跑了一个月没人管，某天突然发现数据不对，结果日志早就被覆盖了，排查无从下手。

3.3 大屏端页面开发与多屏适配

大屏端页面开发有几个硬性要求：自适应分辨率、防烧屏、低内存占用。

自适应这块，我推荐用rem或者vw/vh做布局，配合CSS的transform: scale()做整体缩放。设计稿按1920x1080做，实际屏幕可能是4K或者拼接屏，用scale缩放最省事。但要注意字体渲染在缩放后可能模糊，关键数字可以用SVG或者canvas绘制。

防烧屏是针对LCD大屏的。如果某个区域长期显示固定内容，几个月后就会留下残影。我的做法是让看板内容每隔几分钟做一次微小的位置偏移，或者用半透明遮罩做缓慢移动。OLED屏幕更要注意，但工厂一般用LCD，问题没那么严重。

多屏适配的关键是"配置化"。不要为每块屏幕写一套代码，而是做一个配置文件，指定每块屏幕显示哪些模块、数据源是什么、刷新频率多少。屏幕通过URL参数或者设备ID来加载对应的配置。

// 屏幕配置示例 const screenConfig = { "screen-assembly-01": { modules: ["output", "quality", "andon"], refreshInterval: 5000, lineId: "L01" }, "screen-injection-02": { modules: ["output", "equipment", "oee"], refreshInterval: 10000, lineId: "L02" } };

3.4 联调与上线：从单屏到多屏同步验证

联调阶段我建议分三步走。第一步单屏调试，确认数据准确、刷新正常、样式没问题。第二步双屏对比，把两块屏放在一起，观察同一时刻显示的数据是否完全一致。第三步全屏压测，所有屏幕同时上线，观察服务端CPU、内存、网络带宽。

多屏同步验证有个简单方法：在数据里加一个递增的序号或者时间戳，所有屏幕显示这个序号。如果任意时刻所有屏幕的序号都相同，说明同步没问题。如果出现某块屏序号落后，那就是该屏幕的网络或者渲染有问题。

上线后要观察至少一周。重点看几个指标：数据延迟（从MES产生记录到看板显示的时间差）、推送成功率、客户端内存增长曲线。数据延迟一般控制在10秒以内车间就能接受，推送成功率要在99.9%以上，客户端内存如果持续增长说明有泄漏，必须排查。

4. 常见问题与排查技巧实录

4.1 数据不同步问题排查

数据不同步是看板项目最高频的问题，表现是不同屏幕显示的数字对不上。排查思路从后往前推：

先看服务端推送是否正常。在服务端日志里查每次广播的消息序号，如果序号连续且所有客户端都收到了，那问题在客户端渲染。如果服务端推送就有问题，查数据采集和缓存环节。

再看客户端。打开浏览器的开发者工具，看WebSocket连接状态和收到的消息。如果某块屏幕的WebSocket频繁断开重连，那就是网络问题。车间里网线走线要避开变频器、大功率电机这些干扰源，实在避不开就用屏蔽网线。

还有一个隐蔽原因是浏览器缓存。看板页面更新后，某些屏幕加载的还是旧版JS，导致渲染逻辑不一致。解决办法是在静态资源URL上加版本号或者时间戳，强制刷新缓存。

4.2 网络与连接稳定性问题

车间网络环境比办公室恶劣得多，粉尘、震动、电磁干扰都会影响网络稳定性。我总结了几条经验：

交换机要选工业级的，普通商用交换机在车间里寿命短。网线用超五类以上屏蔽线，水晶头压接要规范，我见过因为水晶头没压好导致间歇性断网的案例，排查了一整天。

如果看板终端距离交换机超过100米，普通网线就不行了，要用光纤收发器。上海有些老厂房跨度大，这个问题很常见。

无线方案我不推荐用于看板，WiFi在车间里干扰太严重，而且漫游切换时会断连。如果实在要拉不了网线，用电力猫也比WiFi稳，但电力猫受车间用电设备影响也大，只能作为临时方案。

4.3 大屏显示异常与性能优化

大屏显示异常常见的有：花屏、闪烁、分辨率不对、颜色偏差。

花屏和闪烁多半是HDMI线或者显卡问题。HDMI线不要用太便宜的，长距离传输要用带信号放大的。显卡驱动要装官方版，Windows自动更新的驱动有时候会有兼容问题。

分辨率不对是EDID识别问题。有些拼接屏或者工业显示器EDID信息不规范，电脑识别不到正确分辨率。解决办法是用EDID模拟器，或者手动在显卡驱动里添加自定义分辨率。

性能优化方面，看板页面要避免频繁的DOM操作。数据更新时只更新变化的数字节点，不要整个页面重绘。ECharts图表要合理使用setOption的notMerge参数，避免内存泄漏。我一般会加一个定时器，每隔几小时自动刷新一次页面，释放累积的内存。

提示：看板终端建议用瘦客户端或者迷你主机，不要用普通办公电脑。瘦客户端功耗低、无风扇、适合7x24运行，而且系统可以做成只读模式，防止车间人员误操作。

4.4 与MES系统的对接避坑

和MES对接是最容易扯皮的环节。MES厂商往往不愿意开放数据库，接口文档也写得含糊。我的经验是：

提前和MES厂商确认接口的并发限制和调用频率限制。有些MES接口有防刷机制，调用太频繁会被封IP。如果MES不提供接口，只能读数据库，那一定要和MES厂商书面确认读库不会影响主系统性能，并且只读从库，不要读主库。

MES的数据字典要拿到，特别是状态码的含义。比如工单状态"1"代表生产中还是待生产，不同MES定义不一样。我见过因为状态码理解错误，看板上把"已完工"的工单显示成"生产中"，车间主任直接打电话来骂人。

返工返修的数据要特别注意。汽车水冷板这类产品的返工流程复杂，一个产品可能经过多次返工。看板显示产量时，返工品算不算产量？返工后重新过站算不算重复计数？这些业务规则必须在开发前和品质、生产部门确认清楚，写进需求文档。

5. 上线后的运维与持续优化

5.1 日常巡检与监控

看板系统上线不是终点，而是运维的起点。我一般会配一套简单的监控：服务端用Prometheus加Grafana监控CPU、内存、WebSocket连接数；采集程序用心跳机制，超过一定时间没心跳就告警；看板终端用定时截图对比，如果画面长时间不变就说明可能卡死了。

巡检频率不用太高，每天上班前看一眼监控面板就行。但要有告警机制，服务挂了要能主动通知到人。通知方式用企业微信或者钉钉机器人最方便，车间IT人员手机就能收到。

5.2 数据准确性校验

看板数据不准，比没有看板更糟糕。车间一旦发现数据不对，就会彻底不信任这个系统。所以数据校验机制必须要有。

我的做法是每天做一次"对账"：看板统计的当日产量和MES报表的当日产量做比对，差异超过阈值就告警。差异原因可能是采集漏数据、聚合逻辑错误、或者MES本身数据有问题。对账报告自动生成，发给生产主管确认。

另外，看板上要显示数据更新时间。如果数据超过一定时间没更新，数字变灰或者加个警示图标，让车间知道当前数据不是最新的。

5.3 后续功能扩展方向

看板跑稳之后，可以逐步扩展功能。常见的扩展方向有：增加安灯呼叫功能，车间发现问题可以直接在看板上呼叫维修；增加设备点检功能，看板显示点检计划和完成情况；增加能耗监控，把电表、气表数据接进来。

再进一步可以和MES的排产模块联动，看板显示当前工单的预计完成时间，根据实际进度动态调整。这个就需要和MES做更深的集成，开发量比较大，但价值也高。

我个人在实际操作中的体会是：看板项目成功的关键不在于技术多先进，而在于是否真正解决了车间的一线问题。我见过用最简单的HTML页面做的看板，因为数据准、刷新快、界面清爽，车间用得很满意；也见过用最新框架做的花哨看板，因为数据延迟大、经常卡顿，上线三个月就被弃用。技术是为业务服务的，把数据搞准、把稳定性做好，比什么都重要。

最后分享一个小技巧：看板上线初期，每天去车间转一圈，听听工人和班组长的反馈。他们提出的往往是最真实的需求，比如"这个数字太小了看不清"、"这个颜色在灯光下反光"，这些细节改起来不难，但能极大提升使用体验。