做工业自动化的，迟早会遇到一个需求：把PLC里的数据读到工控机上，或者反过来从工控机写数据到PLC。

这个需求看着简单，但方案选错了，后面维护起来特别痛苦。通信不稳定、数据延迟高、不同品牌PLC要写不同驱动、现场加一台设备就要改一次程序。这些问题在项目初期都看不出来，等系统跑起来才发现全是坑。

今天就把目前主流的三种PLC与工控机数据交互方案掰开揉碎了对比一下，看完你大概就知道自己的项目该选哪种了。

## 方案一：OPC UA

OPC UA现在几乎是工业通信的"标准答案"了。西门子、罗克韦尔、三菱、施耐德，主流PLC品牌基本都支持。

**工作原理：** PLC端跑一个OPC UA Server，暴露数据点。工控机端跑一个OPC UA Client，订阅需要的数据点。Server在数据变化时主动推送给Client，不需要Client轮询。

**优势：**

跨品牌兼容是最大的卖点。不管你底下用的是西门子S7-1500还是罗克韦尔CompactLogix，OPC UA对外暴露的接口是统一的。工控机端的程序不需要针对不同品牌写不同驱动。

安全机制完善。OPC UA支持用户认证、加密传输、签名校验。工业网络安全这块，OPC UA是目前做得最好的协议。

数据模型丰富。OPC UA不光传数据，还传数据的语义信息。一个温度值，OPC UA告诉你它叫"反应釜温度"，单位是摄氏度，量程是多少。客户端不用硬编码这些信息。

**劣势：**

实现复杂。PLC端配OPC UA Server不简单，要定义节点、配置地址映射、设置安全策略。工控机端也要找靠谱的OPC UA客户端库，开源的有些坑不少。

资源占用大。OPC UA协议栈比较重，对PLC的CPU和内存有要求。低端PLC跑不动OPC UA Server，或者只能跑简化版。

延迟方面，OPC UA在正常情况下延迟可以控制在几十毫秒。但如果数据量大，订阅的点位多，服务端的处理能力会成瓶颈。我测过西门子S7-1500，2000个点的情况下，数据更新延迟大概50到100毫秒。

**适用场景：** 多品牌PLC混用、对安全性要求高、需要标准化数据模型的中大型项目。

## 方案二：Modbus TCP

Modbus是最老牌的工业通信协议了，虽然年头长，但到现在还是用得最多的协议之一。

**工作原理：** 工控机作为Master，PLC作为Slave。Master发请求读取或写入数据，Slave回应。本质上是一个请求-应答模式。

**优势：**

简单。Modbus协议本身极其简单，几十行代码就能实现一个基本的通信功能。网上各种语言的Modbus库满天飞，随便找一个就能用。

几乎所有设备都支持。PLC、变频器、仪表、网关，不支持Modbus的工业设备几乎找不到。而且Modbus TCP走以太网，不需要额外的通信模块。

资源占用小。Modbus协议帧开销很小，对PLC性能几乎没要求。最便宜的小PLC也能跑。

**劣势：**

轮询模式是最大的痛点。Modbus是Master主动请求，Slave被动回应。你想知道某个寄存器变了没有，只能不停地去读它。1秒读一次？那变化到读取之间最坏就有1秒延迟。想快点？10毫秒读一次？那你每秒要发100个请求，PLC的连接数和处理能力扛不住。

不支持事件通知。Slave端数据变了不会主动告诉你，你只能盲轮询。

安全基本没有。Modbus协议本身不带任何认证和加密。在工业内网里用用还行，一旦暴露到外网就是裸奔。

跨品牌也不完全兼容。虽然协议标准是统一的，但不同品牌PLC的寄存器地址映射不同。西门子的VW100和施耐德的MW100，地址一样但含义可能完全不同。换PLC就得改映射表。

**适用场景：** 单一品牌PLC、数据量不大、对延迟要求不高、快速开发验证的小型项目。

## 方案三：MQTT

MQTT本来是物联网协议，但这两年在工业领域用得越来越多。

**工作原理：** PLC端或者边缘网关作为MQTT Publisher，把数据发布到MQTT Broker。工控机作为Subscriber订阅感兴趣的主题。Broker负责消息路由。

**优势：**

发布订阅模式天然支持事件驱动。数据变了才发，不轮询，网络和CPU开销都小。这一点比Modbus强太多了。

跨网络能力强。MQTT天然为不稳定的网络设计，有QoS（服务质量）级别保证。断线重连、消息缓存这些机制都内置了。如果工控机部署在云端，PLC在工厂里，中间通过互联网连接，MQTT是三个方案里最稳的。

扩展性好。加一台设备就加一个Publisher，工控机订阅新主题就行。不用像Modbus那样改轮询列表，也不用像OPC UA那样重新配置Server节点。

**劣势：**

需要额外的Broker。你要么自己搭一个Mosquitto或者EMQX，要么用云服务。增加了一个组件就意味着多一个故障点和维护成本。

工业语义弱。MQTT只管传输，不管数据是什么。你发一个JSON过来，里面{"temp": 35.2}，接收端不知道这个temp是哪个设备的什么温度。语义层要自己在应用层解决。

PLC原生支持差。大部分PLC不直接支持MQTT，需要中间加一个协议转换网关。这个网关把PLC的Modbus或OPC UA数据转成MQTT发出去。多一层转换就多一层延迟和故障可能。

延迟方面，在本地局域网内，MQTT的延迟跟OPC UA差不多，几十毫秒级别。但经过Broker转发，如果Broker性能不行或者网络条件差，延迟会明显增大。

**适用场景：** 分布式部署、跨网络数据采集、设备数量多且会动态增减的物联网项目。

## 三种方案横向对比

| 对比维度 | OPC UA | Modbus TCP | MQTT |
|---------|--------|-----------|------|
| 通信模式 | 订阅/推送 | 轮询/请求应答 | 发布/订阅 |
| 跨品牌兼容 | 好 | 一般 | 好 |
| 安全性 | 强 | 无 | 中等 |
| 实现复杂度 | 高 | 低 | 中 |
| 事件驱动 | 是 | 否 | 是 |
| PLC原生支持 | 中高端支持 | 几乎全支持 | 需网关 |
| 资源占用 | 大 | 小 | 中 |
| 典型延迟 | 50-100ms | 10-100ms(取决于轮询间隔) | 50-200ms |

## 怎么选

说几句实在的。

如果你的项目就一台PLC、一台工控机、同在一个机柜里、不需要安全认证、数据点不超过几百个，直接用Modbus TCP。别想太多，最简单的方案就是最好的方案。

如果你的现场有多个品牌的PLC，或者对数据安全性有要求，或者后期可能接入MES/SCADA系统，选OPC UA。前期配置工作量大一点，但后面扩展和维护省心很多。

如果你的工控机不在现场，部署在云端或者异地，需要通过互联网采集数据，选MQTT。它对不稳定网络的适应性是另外两个比不了的。

混合方案也很常见。现场用OPC UA或Modbus采集PLC数据，通过MQTT传到云端。这种边缘+云的两层架构在工业物联网项目里越来越主流。

方案选型这东西，没有最好只有最合适。先把需求摸清楚：几台设备、什么品牌、网络环境怎样、延迟要求多少、后期会不会扩展。这些问题想明白了，选哪个方案其实不难。