面向IIoT的PLC选型：MQTTOPC UA原生支持的权重评估

一位自动化工程师站在PLC选型的十字路口，面前摆着的不再仅仅是I/O点数、CPU速度、内存大小这些传统指标。工业物联网的浪潮下，两个陌生的字母组合——MQTT和OPC UA——正悄然成为选型表单上的“必答题”。工厂需要将设备数据送入云端分析，集团总部要求跨车间数据互通，运维团队希望远程监控产线状态——这些需求的实现，都依赖于PLC的通信协议能力。

但MQTT和OPC UA究竟是什么关系?PLC原生支持哪个更重要?选型时应该如何权衡?本文将从两种协议的架构本质出发，结合性能实测数据和典型应用场景，为PLC选型中的通信协议评估提供可量化的决策框架。

一、架构本质：两种协议的基因差异

1.1 OPC UA：工业自动化的“标准语言”

OPC UA诞生于工业自动化领域对“互操作性”的渴求。传统工业现场充斥着西门子、罗克韦尔、三菱等不同品牌的PLC，它们各自使用私有协议，彼此无法直接通信。OPC UA通过统一的信息建模解决了这一难题：它不仅仅传输数值，还传输数值的语义——比如不仅仅发送“90.5”，还说明这是“电机温度，单位摄氏度，来自3号车间2号电机”。

从架构上看，OPC UA采用客户端/服务器模式。服务器运行在PLC或网关设备上，暴露标准化的数据接口;客户端(如SCADA、MES系统)主动连接服务器并订阅需要的数据。这种模式天然具备请求-响应的确定性，同时OPC UA内置了安全机制——数据加密、身份认证、访问审计一应俱全，使其成为制药、汽车等对合规性要求严苛行业的首选。

1.2 MQTT：物联网的“轻量信使”

MQTT则出生背景完全不同。它由IBM在1999年设计，初衷是为石油管道传感器提供一种“极其省电省流量”的通信方式。MQTT采用发布/订阅模式，所有设备连接到一个中央代理(Broker)，发布者将数据按“主题”(topic)发送给Broker，订阅者从Broker获取自己感兴趣主题的数据。

这种“解耦”架构赋予了MQTT独特的优势：发布者和订阅者无需知道对方的存在，新设备加入网络只需连接到Broker，系统可轻松扩展至数万台设备。MQTT的数据包极其紧凑，协议开销仅2字节，非常适合带宽受限或网络不稳定的场景。

二、性能对决：实测数据揭示的取舍

2.1 包大小：MQTT的绝对优势

在工业数据采集场景中，协议数据包的大小直接影响网络负载和传输效率。一项使用Wireshark抓包的实测研究显示：发送10字节有效载荷时，OPC UA数据包大小为177字节，而MQTT仅为61字节——相差近3倍。

这一差异源于两者的设计哲学不同。MQTT在传输层做了极致精简，只携带最必要的信息;OPC UA则在包头中嵌入了丰富的数据类型描述和安全上下文，确保接收方能准确理解数据的含义。对于4G/5G物联网卡等按流量计费的场景，这种差异可能意味着每月数千元的成本差距。

2.2 传输速度：OPC UA微弱领先

同一项测试中，OPC UA的平均传输速度为4718.5 kbps，略高于MQTT的4125.6 kbps。需要强调的是，两者差距不足15%，且在实际应用中网络延迟通常远大于协议处理延迟，这一差异并非决定性因素。真正重要的区别在于：OPC UA支持同步确认写入操作——当控制系统向PLC发出“关闭阀门”指令时，可以确认指令是否成功执行;而MQTT的发布/订阅模式本质上是“发后不管”，写操作的成功确认需要额外机制。对于安全联锁等关键控制场景，这种差异是致命的。

2.3 资源开销：MQTT更轻量

MQTT协议栈通常在几十KB内存即可运行，适合资源受限的边缘设备;OPC UA协议栈体量在几MB到几十MB不等，对PLC的内存和处理能力要求更高。这意味着，低端PLC可能只支持MQTT而不支持OPC UA，选型时需确认目标型号的具体规格。

三、应用场景：谁是“主场选手”?

3.1 OPC UA的主场：车间内设备互通与SCADA集成

当需求聚焦于“车间内部多品牌设备互联”时，OPC UA是事实标准。西门子、罗克韦尔、倍福等主流PLC厂商均已原生支持OPC UA服务器功能，工程师只需在PLC配置中启用相应功能块，即可让SCADA系统通过标准化接口读取数据，无需编写协议转换代码。

SAE技术论文《The Digital Backbone of Manufacturing》中提出的协议选型框架，将OPC UA列为“互操作性”维度的最高分协议，特别适合需要将PLC、机器人、HMI、SCADA、MES全线打通的智能制造场景。

3.2 MQTT的主场：设备上云与远程监控

当需求是“将数据送上云端”时，MQTT占据绝对优势。MQTT基于TCP/IP运行，天然适配云平台的HTTP/WebSocket接口;其发布/订阅模型与云消息队列服务(如阿里云IoT Hub、AWS IoT Core)完美契合;极低的心跳包开销(仅2字节)使其在4G/NB-IoT等窄带网络中表现优异。

以风电场为例，每台风机通过4G网络回传振动、温度、发电量数据，使用MQTT协议可将通信成本降低60%以上。通过MQTT的遗愿消息(Last Will)功能，云端可在风机断网时立即感知，实现智能运维。

四、PLC选型权重评估：量化决策框架

4.1 需求权重矩阵

建议工程师从以下维度评估项目对通信协议的需求权重：

**互操作性需求(权重0-30分)**：需连接3种以上品牌设备或对接第三方MES，赋30分;设备均为同品牌，赋0分。

**语义完整性需求(权重0-20分)**：需数据带含义(如制药合规、设备状态语义)，赋20分;仅需原始数值，赋0分。

**云对接需求(权重0-25分)**：需将数据推送至公有云或MQTT Broker，赋25分;数据仅在本地使用，赋0分。

**带宽/流量敏感度(权重0-10分)**：使用4G/NB-IoT按流量计费，赋10分;工厂有线网络，赋0分。

**确定性写入需求(权重0-15分)**：需远程控制设备(启停、参数修改)，赋15分;仅需数据采集，赋0分。

4.2 评分与选型建议

若**互操作性+语义完整性+确定性写入**三项得分之和超过50分(总分65分)，OPC UA原生支持应作为PLC选型的“否决项”，不支持OPC UA Server的PLC直接淘汰。

若**云对接+带宽敏感度**两项得分之和超过25分(总分35分)，MQTT原生支持应赋予高权重。若PLC不支持MQTT，需评估网关方案的额外成本和故障点。

理想情况下，PLC应同时原生支持OPC UA(用于车间内SCADA集成)和MQTT(用于云端推送)，两者结合可实现“车间数据不落地、上云只需配地址”的最高效率。

五、结语

MQTT与OPC UA并非“谁取代谁”的零和游戏，而是“各司其职、协同互补”的搭档——OPC UA深耕车间，MQTT连通云端。

PLC选型时应遵循“先定性、后定量”的评估逻辑。首先判断应用场景的核心需求落在哪个“主场”——是在车间内实现多品牌设备互通，还是将数据高效送上云端?在此基础上，量化各项需求的权重，对照PLC规格书逐项匹配。不支持OPC UA的PLC，慎用于复杂产线集成;不支持MQTT的PLC，慎用于远程运维场景。最理想的选择，是支持“双协议栈”的PLC——让OEM工程师的“纠结”，在选型阶段就画上句号。