这几年我走访过几十个仓库，几乎家家墙上都挂着一块仓库数据大屏。上线那天锣鼓喧天，三个月后，大屏还亮着，但已经没人抬头看它了。根据我接触过的项目粗略估算，能做到"每天有人看、每周有人用数据做决策"的大屏，不到三成。剩下的，要么沦为参观时的背景板，要么显示的数字根本没人信。这篇文章想回答一个问题：WMS、设备 PLC、摄像头这三路数据，到底怎么接，才能让大屏从摆设变成工具。
大屏沦为摆设的三种死法
第一种死法，死于"没人看"。大屏上跑的是 IT 部门觉得重要的数据，不是现场管理者每天早上要回答的问题。库内积压、今日波次进度、异常停线时长——这些才是班长每天睁眼就要的东西。大屏展示的是"系统里有的数据"，而不是"现场需要的数据"，错位从第一天就注定了。
第二种死法，死于"数字是错的"。大屏显示在库 5200 托盘，WMS 里查出来 4800，现场一盘点 4950。三个数三个样，几次之后，管理者就学会了：开会只看 WMS，大屏就当壁纸。数字一旦失去信任，就再也回不来了。
第三种死法，死于"接不上"。WMS 的数据接进来了，设备 PLC 的数据还在设备商手里，摄像头的画面只在保安室能看。三路数据三张皮，大屏只能展示 WMS 那一路——那还不如直接打开 WMS 看。
2024 年华南一家 3PL 的仓库，大屏项目花了小半年，验收时一切正常。两个月后，运营经理发现大屏上的在库数和 WMS 差了 300 多托盘。查下来，根子很典型：接口每 15 分钟从 WMS 同步一次，而理货员的手工调账走的是另一条线，不经过接口。大屏展示的是"15 分钟前的、没算调账的"库存。这个项目最后没有返工，只是从此没人看大屏——它死于第二种死法，慢性死亡。
三路数据源，各有各的接法
仓库数据大屏真正的数据源头有三路，每一路的接入路径、延迟量级和坑都完全不同：
| 数据源 | 接入路径 | 延迟量级 | 典型坑 |
|---|---|---|---|
| WMS（业务数据） | REST API，或数据库只读视图/物化视图 | 分钟级 | 接口字段口径与页面显示不一致；大查询拖慢生产库 |
| 设备 PLC（设备状态） | OPC UA 网关，或老设备的 Modbus 转 OPC UA | 毫秒到秒级 | 点表文档缺失，点位含义靠老师傅口述；协议不开放 |
| 摄像头（视频与事件） | 视频流 RTSP 直投画面；AI 分析结果走事件流（MQTT/HTTP 回调） | 画面实时，分析结果秒级 | 算力不够导致误报刷屏；隐私合规没做就全量存录像 |
WMS 这一路相对最成熟，但有个细节容易被忽略：不要直连生产库做大查询。大屏的聚合查询动不动就是全表扫描，直连生产库，旺季时能把 WMS 的响应拖慢一个数量级。正确做法是单独开只读从库或物化视图，大屏只读副本。这是血的教训换来的常识。
PLC 这一路是真正的硬骨头。根据多位系统集成商的反馈，一个中等规模自动化仓的 PLC 点表，完整文档能一次拿齐的不到一半。很多老设备的点位含义只存在老师傅的脑子里，老师傅一退休，点表就成了天书。OPC UA 是现在的标准解法，老设备则要加一层 Modbus 转 OPC UA 的网关——硬件成本不高，但调试时间经常超出预期两三倍，项目排期时要留足余量。
摄像头这一路要分两层看：画面层和分析层。画面层用 RTSP 直接投，技术上最简单；分析层（人数统计、越界告警、空托盘识别）需要 AI 推理，误报率是最大的坑。没有经过现场调优的算法，旺季灯光一变、纸箱堆法一变，误报能把大屏的告警区刷成红色瀑布——几次之后，现场就把告警声音关了。
为什么大屏的数字和 WMS 总对不上：延迟与口径
大屏数字和 WMS 对不上的根子，十有八九出在两个地方：延迟链和口径差。
先看延迟链。一条典型的数据旅程是这样的：PLC 毫秒级产生设备状态 → 边缘网关秒级汇总 → WMS 分钟级更新业务单据 → 大屏 15 分钟轮询一次接口。链条越长，末端看到的"现在"离真正的现在越远。15 分钟的轮询间隔在设计时没人觉得有问题，直到旺季每小时进出几百托盘，大屏上的数字和现场永远差着一截。
再看口径差，这是更隐蔽的杀手。"在库数"这个词，WMS 里可能指"账面库存"，大屏的 SQL 可能算的是"有库位占用的托盘数"，财务要的又是"已收货未出库的货值"。同一个词，三种算法。2023 年华东一家汽车零部件仓库，大屏的 OEE（设备综合效率）和设备科手工算的 OEE 差了将近 10 个百分点，两边开会吵了一个月，最后发现大屏把计划停机也算进了分母。口径不对齐，数据越多，吵架越多。
解法没有捷径：大屏上线前，必须出一份《指标口径说明书》，每个指标写清定义、数据源、计算公式、更新频率，业务方、IT、设备三方签字。这是 paperwork，但缺了它，大屏的每一个数字都是悬空的。
IT 和 OT 接不到一起的三个根子
归因到最后，WMS、PLC、摄像头三路数据接不到一起，根子不在技术，而在组织。
第一，语言不通。IT 讲的是 REST、JSON、API 文档；OT 讲的是点位、寄存器、扫描周期。两边开会，经常出现 IT 问"这个接口的鉴权方式是什么"，OT 答"这个点是 4～20mA 的"——鸡同鸭讲。能同时听懂两边语言的人，在大多数企业里不超过一两个，而大屏项目恰恰需要这样的人做翻译。
第二，责任不清。设备数据归设备科，WMS 归信息部，摄像头归行政或安保。大屏项目一立项，三方都觉得"数据我可以给，但口径和质量你别找我"。数据质量的无人区，是大屏项目烂尾的重灾区。
第三，考核不挂钩。大屏做得再好，不解决任何一个部门的 KPI 痛点，它就是"别人的项目"。反过来，如果大屏上的"异常停线时长"直接进了设备科的月度考核，点表文档一周就能补齐——利益才是最大的集成动力。
从看板到预警，再到自动调度：仓库数据大屏的演进
如果把仓库数据大屏按成熟度分级，大致是三个阶段：
| 阶段 | 形态 | 核心价值 | 前提条件 |
|---|---|---|---|
| 第一阶段：看板 | 展示历史和实时状态 | 信息透明，减少"跑现场问数" | 三路数据接通、口径对齐 |
| 第二阶段：预警 | 阈值告警、异常推送 | 把问题暴露在发生时，而不是第二天 | 延迟降到分钟级以内；误报率可控 |
| 第三阶段：自动调度 | 系统直接下发任务 | 减少人工干预，7×24 小时响应 | 数据可信到敢让机器做决策 |
根据目前的行业节奏，大部分仓库还处在第一阶段向第二阶段爬坡的过程中；第三阶段在高度自动化的新仓里已经出现苗头，但全面铺开还需要几年——前提是前两个阶段的地基打牢。一个连口径都没对齐的大屏，直接跳到自动调度，调度的只会是错误。
说到底，大屏真正的考题从来不是"三路数据接不接得进来"，而是"接进来之后，有没有人愿意为数据的正确性负责"。技术方案可以抄，组织解法抄不了。当一块大屏开始有人每天早上看、每周拿它做决策、每月为它的数字吵架——那时候，它才算真正活过来。而这，恰恰是任何技术文档都写不出来的部分。
作者：陈博士｜供应链行业研究员
