冯工聊数采NodeSCADA · 工控老兵手记 · PLC对接MES 数采上报方式 HTTP MQTT OPC UA

---

上一篇说了数采和对接是两件事，这篇来聊"对接"这段路具体怎么走。

工厂里PLC数据要上报给MES，常见的方式就那么几种：数据库对接、HTTP推送、MQTT、OPC UA。每种都有人在用，每种也都有坑。选错了方式，项目后期改起来相当痛苦。

我按实际项目里遇到的情况，挨个说一下。

---

数据库对接：最常见，也最容易埋雷

这是我见过最多的方案，尤其是老项目。

做法很简单：数采这边把数据写进一张表，MES那边定时来查。两边约定好表结构，看起来干净利落。

适合的场景确实有——两个系统都在同一个内网，数据量不大，更新频率不高，而且两边的开发团队沟通顺畅，表结构变化能及时同步。早年我做过几个这样的项目，跑得也挺稳。

但坑在哪呢？

两个系统共用一张表，等于没有接口边界。采集这边哪天加个字段、改个类型，MES那边可能直接报错，而且不一定马上发现，等发现的时候数据已经缺了一段。更麻烦的是，这种问题很难定位，两边互相甩锅是常态。

还有性能问题。MES查询频率一高，数据库连接数上来，采集写入就开始抖。我碰过一个项目，现场二十几台设备同时采，MES那边每秒查一次，数据库直接撑不住，最后只能限频，实时性全没了。

总结一个字：脆

---

HTTP推送：对接MES最顺手的方式

HTTP是目前MES对接用得最多的方式，没有之一。

原因很简单——几乎所有MES都有HTTP接口，ERP也有，自建系统也有。用HTTP推数据，双方不需要约定共享数据库，各自维护自己的系统，接口文档定好就行，改起来也方便。

适合的场景：MES提供了标准的HTTP接收接口（一般都是REST API，接收JSON），采集这边定时或者按变化推过去。这是当前新项目里最主流的做法。

第一是格式对齐。MES要的字段名、数据结构，和采集这边原始数据往往对不上。比如MES要的是：

{
  "stationCode": "CNC-01",
  "reportTime": "2025-05-20T08:30:00+08:00",
  "yield": 128,
  "defectRate": 0.02
}

但采集软件给出来的是另一套字段名和结构。这时候谁来做转换？如果采集软件支持自定义推送格式，问题不大；如果不支持，就得加一层中间服务专门做字段映射，工作量不小。

第二是推送失败怎么办。网络抖一下，MES那边重启了，推过去的数据丢了，要不要补推？补推的时候顺序乱了怎么办？这些细节很多采集方案压根没考虑，到了现场才发现。

第三是推送频率和MES的承受能力要匹配。我见过有人把推送间隔配成1秒，几百个点位，MES直接被打垮。推送频率要根据对方接口的处理能力来定，事先得沟通清楚。

---

MQTT：数据量大、多系统共享的首选

MQTT是物联网领域的标准协议，轻量、异步、支持一对多订阅。

适合的场景：数据量大、更新频率高；或者同一份数据需要同时给多个系统用——MES要、云平台要、看板也要，MQTT发一次，订阅方各自去取，不需要采集这边给每个系统单独推一遍。

另一个适合场景是网络不稳定的环境。MQTT有QoS机制，网络断了重连之后可以补发，比HTTP裸推可靠一些。

需要一台MQTT Broker。mosquitto或者EMQ都行，但这意味着多维护一个服务，工厂IT不一定愿意接。我碰过几个甲方，一听说要多装一个消息中间件，直接拒绝，最后还是改回HTTP。

MES不一定支持MQTT订阅。很多传统MES是HTTP接口思维，没有MQTT客户端，让他们去订阅Topic，二次开发成本不低。所以MQTT更适合对接IoT平台、云端系统，或者技术栈比较新的MES。

数据格式同样要约定。MQTT只管传，内容是什么格式，还是得自己定。JSON是最常见的，但字段怎么组织，Topic怎么设计，都要事先规划好，不然后期扩展一堆烂摊子。

---

RabbitMQ：企业级消息队列，适合复杂集成场景

RabbitMQ和MQTT的定位不一样。MQTT是物联网协议，轻量优先；RabbitMQ是企业级消息队列，功能更重，支持路由、优先级队列、死信队列这些机制。

适合的场景：工厂已经有RabbitMQ基础设施，或者IT部门本来就在用它做系统集成。采集数据进队列，多个下游系统各自消费，消息不会丢，顺序有保障。

对于工控背景的人来说，RabbitMQ的学习成本和运维成本都比MQTT高。如果工厂IT没有用过，引入它的阻力会比较大。纯粹为了数采上报去引入RabbitMQ，通常不值当，除非上层系统本来就在用。

---

OPC UA：工业场景里最"正统"的方式

OPC UA是工业自动化领域的标准通信协议，西门子、ABB、施耐德这些厂家的高端设备原生支持，很多MES和SCADA也原生支持OPC UA客户端。

适合的场景：上层系统本身有OPC UA客户端，能直接来读数据——这种情况下，采集软件起一个OPC UA Server，把所有采集点位自动暴露出去，MES连上来按需读取，不需要约定推送格式，也不需要额外开发。对于MES这边来说最省事。

采集软件未必支持。大多数软件采集数据的能力不差，但能起一个OPC UA Server、把点位自动映射进去，这个功能有的软件根本没有，有的实现得残缺不全。

网络安全配置比较繁琐。OPC UA支持证书认证和加密传输，配起来比HTTP复杂，IT部门第一次搞容易卡壳。不需要安全认证的内网场景可以先用匿名模式，但正式交付时甲方安全部门有时候会要求开安全认证，得提前做好准备。

OPC UA更适合"拉"而不是"推"。MES来读数据是它的强项，如果你需要的是实时主动推送，OPC UA就不是最顺手的选择了。

---

选哪种，说白了看这几个条件

说了这么多，怎么选其实不复杂，现场问清楚这几件事基本就定了：

MES那边支持哪种接入方式？这是第一优先级，对方支持什么你就走什么，不要为了技术先进性去逼甲方改系统。

数据要给几个系统用？只给MES用，HTTP够了；要同时给多个系统用，考虑MQTT。

工厂IT的技术栈和接受程度？MQTT Broker、RabbitMQ这些中间件，IT不熟悉的话运维风险得算进去。

采集软件本身支持什么？这个经常被忽略。选完方案，发现采集软件那头不支持，又得重头来过。

最后这条我体会最深。协议选得再好，采集软件出口这块能力不够，一样白搭。最近在用的一款软件在这块做得还不错，下一篇具体说说HTTP推送怎么配、格式怎么定，到时候带着实际配置来聊。

---

冯工聊数采NodeSCADA · 持续更新工控数采实战经验