MES（制造执行系统）的核心职责是连接计划层（ERP）与控制层（设备），在车间现场执行生产计划、记录工序状态、汇总质量数据。这个定位决定了 MES 的数据需求几乎全部来自设备层——PLC、CNC、传感器、物料输送线。但在绝大多数工厂，MES 与设备之间的数据流通并没有设计中那么顺畅。
数据鸿沟的三个根因
第一个根因是协议不统一。车间现场的设备协议五花八门：西门子 PLC 用 S7 通信，三菱 PLC 用 MC 协议，FANUC CNC 用 FOCAS，传感器常用 Modbus RTU/TCP，车间级网络里跑着 Profinet、EtherCAT、Modbus TCP。一个中等规模的离散制造车间可能同时有 5-8 种协议在运行。MES 厂商不可能为每一种设备协议都做原生支持，于是大部分 MES 系统的数据接入依赖各种中间件——协议网关、OPC Server、工业总线转换器。这些中间件各自独立，数据格式和接口风格各异。
第二个根因是实时性差异。设备侧的数据更新频率通常在 1-100Hz，某些场景（高速包装线、高精度 CNC）的标签更新频率达到 1-10kHz。MES 系统的设计目标通常是秒级甚至分钟级的准实时——因为 ERP 下发生产订单的周期是小时级，工序完成的汇报频率也远低于设备状态变化的频率。这种实时性不匹配导致 MES 要么丢数据（轮询间隔大于设备更新间隔），要么引入额外的数据缓冲层来存储原始高频数据再供 MES 按需拉取。
第三个根因是数据粒度不匹配。设备侧的标签是点位级的——PLC 的每个输入输出位、每个内部寄存器对应一个独立标签，一个车间的设备标签总数可能达到数十万个。MES 关注的是工位级、工序级的聚合视图——"1 号线工位 3 当前在加工的零件编号是什么、已加工多少秒、状态是待机还是运行"。从点位级到工位级的聚合需要大量的转换逻辑，这些逻辑散落在协议网关、中间件、甚至 MES 的后台脚本中，维护成本高且难以复用。
鸿沟维度 | 设备侧特征 | MES 侧特征 | 典型后果 |
协议 | S7, FOCAS, Modbus, Profinet 等 5-10 种 | 通常只支持 OPC UA / RESTful API | 需要大量协议网关和中间件 |
实时性 | 1-10000Hz | 1 秒 – 1 分钟 | 轮询丢数据或引入额外缓冲层 |
数据粒度 | 点位级，数十万标签 | 工位/工序聚合级 | 聚合逻辑散落在多处 |
数据语义 | 原始寄存器地址或简单标签名 | 业务语义（工序状态、产量计数） | 标签映射表难维护 |
协议适配层的现状与改进
传统的协议适配方案是"一对一网关"——每种设备协议对应一套独立的网关软件或硬件，网关向上统一暴露 OPC DA 或 OPC UA 接口。这个方案的问题在于网关本身成为了新的烟囱：网关 A 做了 S7 → OPC UA 的转换，网关 B 做了 FOCAS → OPC UA 的转换，但两个网关内部的标签命名、数据模型、缓存策略都是独立的，MES 拿到的仍然是两套风格不同的数据。
新一代的协议适配架构倾向于做"统一边缘接入层"：一个统一的软件平台支持所有主流工业协议（S7、FOCAS、Modbus、OPC UA、Profinet 等），向上提供单一的数据模型和统一的接口。标签配置集中管理——在一个界面中定义 S7 寄存器 MW100 对应 MES 语义 "Station3_CurrentPartNo"，FOCAS 输出点 D100 对应 MES 语义 "CNC01_SpindleLoad"。
这种统一接入层的价值还在于可以内置数据清洗和初步聚合能力。例如将 PLC 的 100Hz 更新频率的点位数据在边缘侧做滑动平均后再推给 MES，既减少了 MES 的数据量，又利用边缘侧的计算资源做了初步的降采样。
实时数据引擎的角色
数据鸿沟不是"打通协议"就能解决的。打通协议后，MES 仍然要面对数十万个标签的高频数据流。这个问题的解法是在 MES 与设备层之间插入一层实时数据引擎——这层由 AI 原生工业数据平台承担。
实时数据引擎做三件事：第一，统一存储所有设备侧的原始数据，无论来自什么协议，都以统一的时序格式存储。第二，提供多级视图——既可以查询原始点位数据（供故障排查用），也可以按工位、工序、生产线做实时聚合视图（供 MES 消费）。第三，为 MES 提供事件驱动的推送接口——当工位状态从"运行"变成"待机"时，主动推送事件给 MES，而不是让 MES 周期性轮询。
MES 与实时数据引擎的集成方式推荐采用订阅-推送模型。MES 启动时向引擎声明自己关心的标签列表和聚合粒度，引擎持续推送满足条件的聚合数据。如果 MES 需要临时查询某个具体点位的原始数据（比如分析一次质量异常），再通过一次性查询接口获取。这种模型避免了 MES 周期性轮询带来的延迟和资源浪费。
演进方向：低代码 + 实时数据
MES 行业的一个明显趋势是从"重实施、定制化"向"低代码、数据驱动"转型。传统 MES 项目中，实施团队 70% 的工作量是在做设备标签映射、数据采集脚本和报表开发——这些工作本质上都是数据接入层的任务，只是因为缺乏统一的数据平台而被迫塞进了 MES 实施里。
低代码 MES 的核心前提是底层有一套可靠的实时数据引擎——引擎已经把所有设备数据接入、清洗、聚合好了，MES 实施团队只需要配置业务逻辑：工序模型、工单流转、质量关联、报表模板。数据引擎为 MES 提供"工位 3 当前状态"、"1 号线今日产量"这样的高语义视图，而不是让 MES 自己去拼 PLC 的寄存器值。
结语
MES 与设备层的数据鸿沟本质上是架构问题，不是技术选型问题。单独优化协议适配或 MES 的接口都无法从根本上解决问题。正确的方向是在两层之间构建统一的实时数据引擎作为中枢——引擎对上提供高语义聚合数据和事件推送，对下统一接入所有协议并处理实时性和粒度差异。这个引擎的建设不依赖特定 MES 厂商，可以先建成独立平台再逐步替代 MES 内部的数据采集模块。工业互联网中 MES 的演进也应该遵循这个思路——从"业务系统"向"数据消费应用"转型，把底层数据能力交给工业数据平台来承载。对于正在做 MES 升级的工厂，建议把数据引擎的建设作为优先级最高的前置工作，而不是把它看作 MES 的附属组件。
