- 1. 别上来就选协议
- 2. 三种协议，用一句话说清
- 3. 12 条选择标准，工程硬指标
- 4. 1. 设备数量：轮询的数学天花板
- 5. 2. 通信模型：轮询 vs 事件驱动
- 6. 3. 带宽和延迟：物理层决定下限
- 7. 4. 数据模型复杂度：从寄存器到对象
- 8. 5. 安全性：谁在裸奔
- 9. 6. 互操作性：和谁家的设备说话
- 10. 7. 开发周期和团队技能
- 11. 8. 硬件成本：芯片级的价格差
- 12. 9. 云接入：协议的天生基因
- 13. 10. 历史遗留：改不动就别改
- 14. 11. 设备发现：谁知道总线上有什么
- 15. 12. 固件升级和配置管理
- 16. 决策路径，走一遍
- 17. 混合架构：真实项目的玩法
- 18. 经典组合：Modbus RTU → 网关 → MQTT → 云
- 19. OPC UA 作为聚合层
- 20. 双通道：MQTT 上报 + Modbus TCP 本地控制
- 21. 什么时候不需要混合
- 22. 协议组合速查表
- 23. 没人会替你说的真相
别上来就选协议
每个论坛都在问同一个问题：「我这个项目用 Modbus 还是 MQTT？要不要上 OPC UA？」
回答永远是——先告诉我你的现场有几台设备、走什么物理层、数据往哪去。
协议选型不是选哪个更先进，是选哪个在你这场景下出的问题最少。Modbus 1979 年诞生，MQTT 1999 年，OPC UA 2006 年——三个协议都没死，说明各有各的饭碗。你需要的不是「哪个最好」的结论，是一套工程决策框架，让你三分钟内自己得出结论。
三种协议，用一句话说清
**Modbus RTU/TCP**：主站挨个问从站，一问一答。帧格式固定，地址+功能码+数据+CRC。从站不会主动说话，必须等主站叫它。
打个比方：军训点名。教官叫一个学号，学生报一声「到」。再叫下一个。全班 30 个人，一个一个来，秩序井然。教官累点没关系，但如果有 500 个人？等叫到最后一排已经过去二十分钟了。
**MQTT**：发布/订阅模型。设备自己决定什么时候上报，不需要有人来问。Broker 是邮局，设备往主题里扔消息，谁订阅谁收到。
现场类比：微信群。传感器在群里发了一条「我超标了」，所有订阅了这个群的系统同时看到。不用等谁问。
**OPC UA**：面向对象的工业互操作框架。不只是传输数据，还自带语义模型——告诉你这段数据是「电机电流」，单位是安培，取值范围 0-100，精度 0.1。还有安全通道、认证证书、方法调用。
像外语翻译官：西门子 PLC 说德语，罗克韦尔说英语，三菱说日语，OPC UA 负责翻译成通用语，还附带一本详细的语法说明书。
三种协议不打架。真实项目里它们经常混着用。
12 条选择标准，工程硬指标
1. 设备数量：轮询的数学天花板
Modbus RTU 在 9600 bps 下，读一个保持寄存器（功能码 03），主站发 8 字节，从站回 7 字节（地址+功能码+字节数+2 字节数据+2 字节 CRC），共 15 字节。加上 3.5 字符的帧间隔（约 4ms @ 9600）和从站响应延迟（通常 10-50ms，保守取 20ms）：
每台从站单次轮询时间 = 帧传输时间 + 帧间隔 + 从站响应延迟
帧传输时间 = 15 × 11 bit ÷ 9600 = 17.2ms（11 bit/字符：1 起始位+8 数据位+1 校验位+1 停止位）
单台轮询 ≈ 17.2 + 4 + 4 + 20 = 45.2ms
200 台从站，每台读 10 个寄存器（多寄存器读取的帧更长，一帧大概能塞 125 个寄存器），实际单轮询大约 60-80ms/台。
**200 台 × 70ms = 14 秒。**你在控制室里看着屏幕，HMI 上的数据 14 秒才刷新一次。报警信号在路上走了 14 秒才被你看到。
这还是理论最优值。实际工程里，从站响应超时、重试、线路质量下降都能让这个数字翻倍。
**结论：设备 < 50 台，Modbus RTU 轮询周期在 2-3 秒以内，对大多数监控场景够用。超过 100 台，要么上 Modbus TCP（以太网不吃串口带宽的亏），要么改用 MQTT。**
2. 通信模型：轮询 vs 事件驱动
Modbus 是轮询。你每隔 N 秒问一圈，报警信号可能在两次轮询之间产生，但你必须等到下一圈才看到。
场景：污水处理站，进水 pH 值突然从 7 跌到 4。Modbus 的轮询周期是 5 秒，最坏情况——pH 传感器刚被问完就超标，你要等接近 5 秒才知道。5 秒对于工艺保护来说，太长了。
MQTT 是事件驱动。传感器检测到异常，立刻发布消息。Broker 在同一秒内转发给监控系统。延迟取决于网络延迟+Broker 处理时间，通常在 100ms 以内。
OPC UA 支持订阅模式（MonitoredItem）。客户端注册关心的数据点，设定采样间隔和触发条件。变化>阈值才推送，不是傻轮询全量。
**结论：如果你的报警响应时间要求 < 1 秒，Modbus 轮询做不到，选 MQTT 或 OPC UA 订阅。**
3. 带宽和延迟：物理层决定下限
| 物理层 | 典型速率 | 适合场景 |
|---|---|---|
| RS-485 (Modbus RTU) | 1200-115200 bps | 本地总线，<1200 米 |
| 以太网 (Modbus TCP) | 100 Mbps | 工厂局域网 |
| 4G Cat.1 | 上行 5 Mbps | 远程终端，有基站覆盖 |
| NB-IoT | 上行 ~60 kbps | 低功耗广域，日数据量 < 1KB 的场景 |
| LoRa | 0.3-50 kbps | 超远距离，极低功耗 |
RS-485 的 1200 米极限我见过能达到的——前提是高质量屏蔽双绞线、9600 bps、只有一台设备、没有变频器在旁边。车间现场，变频器一开，通信错误率飙升，你就得降波特率加屏蔽加隔离。
Modbus RTU 在 9600 bps 下，传输密度大概 800 字节/秒（去掉起始位停止位开销）。MQTT 走 4G，几十 KB 不是问题。OPC UA 的二进制编码效率还不错，但连接建立时的证书交换和会话协商要吃掉几百 KB。
**结论：本地总线，带宽不是瓶颈。远程接入，Modbus RTU 不直接走公网——你没见过有人把 RS-485 线从北京拉到石家庄的。必须过网关。**
4. 数据模型复杂度：从寄存器到对象
Modbus 的数据模型只有四种：线圈（位）、离散输入（位）、保持寄存器（16 位字）、输入寄存器（16 位字）。没别的了。没有浮点数、没有字符串、没有时间戳、没有数组结构体——除非你自己在多个寄存器上编码。
一台变频器的数据：运行状态（位）、设定频率（浮点数，占 2 个寄存器）、实际频率（浮点数）、输出电流（浮点数）、母线电压（整数）、运行时间（32 位，2 个寄存器）、报警代码（位掩码）。全用 Modbus 寄存器实现，你需要维护一份 Excel 表格记录哪个寄存器对应什么参数、用什么编码。散落在十台变频器上就是几百个寄存器的映射表。
MQTT 也好不到哪去——JSON 自由格式，但各厂家对「频率」这个字段叫 freqency、freq、Hz、output_freq 的都有。没有标准，你自己定约定。
OPC UA 的信息模型（IM）从协议层解决了这个问题：每个数据点有 Type、Unit、Range、EngineeringUnits。一个 MotorType 对象下面有 Current、Temperature、Speed——自带语义，不是裸寄存器。
**结论：数据点 < 50 个、类型简单（全是整数/开关量），Modbus 寄存器映射完全够用。超过 200 个点、涉及复杂对象模型，OPC UA 帮你省掉一半的文档维护工作量。**
5. 安全性：谁在裸奔
Modbus 的设计年代（1979 年）没人考虑网络安全。RTU 帧上没有认证字段，任何接入 RS-485 总线的设备都能发命令——关泵、改参数、写寄存器。TCP 版本多了一层 TCP 连接，但也没有内置 TLS。
MQTT 可以通过 TLS 加密传输，Username/Password 认证，Broker 端还能做 ACL 控制哪些客户端能发布/订阅哪些主题。
OPC UA 的安全模型是三件套：证书认证（X.509）+ 消息签名 + 消息加密。还支持用户令牌（用户名密码/证书/匿名）。从连接建立到数据传输，全链路加密。
有一次我去某水厂做排查，发现他们的 Modbus TCP 网关公网端口开着，扫进去就能直接写变频器启停寄存器。没开玩笑，这种事在中小企业非常多。
**结论：公网传输、远程运维、涉及关键基础设施的场景——别用裸 Modbus。至少要过 MQTT+TLS 的网关。如果已经有 OPC UA 能力，直接用它的安全通道。**
6. 互操作性：和谁家的设备说话
最理想情况是所有设备都跑同一种协议——你西门子我施耐德他 AB，都用 Profinet 就完了。现实不是这样。
Modbus 的优势恰恰在这里：几乎所有 PLC 都支持 Modbus RTU/TCP，不管是西门子 S7-1200 的 CM1241 模块还是三菱 FX 系列的 RS-485 口。设备厂商也乐意支持——不用付版税，实现简单，几天就能调通。
MQTT 的互操作性靠约定主题结构和 JSON 格式。但各家的约定可能不同。**Sparkplug B 规范**补了这个坑——定义了标准主题命名空间、数据类型编码、设备出生/死亡消息。
OPC UA 的互操作性是协议内置的：配套规范（Companion Specification）覆盖了机器人、注塑机、CNC、风力发电等几十个行业。西门子的 OPC UA Server 和罗克韦尔的 OPC UA Client 能直接对话，不需要写映射层代码。
但话说回来：OPC UA 的配套规范还在发展中，不是所有设备都支持。有些厂商的 OPC UA 实现就是个皮包——结点能浏览，实际数据更新频率跟不上。
**结论：和多种品牌 PLC/DCS 互操作是硬需求→OPC UA。设备全是国产电表/传感器→Modbus RTU 就够。需要云平台对接→MQTT。**
7. 开发周期和团队技能
这是被严重低估的一条。
Modbus 开发：找个串口库，发 8 字节，收 7 字节，调两天，通了。协议栈代码量几百行。你用 Python 的 pymodbus 或者 C# 的 NModbus，上午装包下午就能读写寄存器。三天之内做完一个 Modbus 主站驱动的工程师大有人在。
MQTT 开发：装个 paho-mqtt 库，Broker 地址、端口、主题，三行代码连上。发布/订阅各两行。一天上手。Broker 部署（Mosquitto/EMQX）半小时搞定。
OPC UA 开发：这件事我要说实话——不简单。地址空间建模、证书管理、安全策略配置、订阅/方法调用，学习曲线比前两者陡得多。你用 UAExpert 客户端连上 Server 是一回事，自己写一个完整的 OPC UA Server 是另一回事。工业上通常用 KepServerEx、Siemens OPC UA Server 这些成熟产品，调 SDK 的居多，从头写的不多。一个团队如果没有 OPC UA 经验，预留 2-4 周做技术验证。
**结论：3 天开发→Modbus。1 天开发→MQTT。有专人且项目允许学习成本→OPC UA。**
8. 硬件成本：芯片级的价格差
RS-485 收发器（MAX485/SP3485）批量价不到 1 块钱人民币。加上两个 120Ω 终端电阻、一个 TVS 保护管，BOM 成本 3 块钱以内。STM32F103 单片机的 UART 外设直接驱动，连外部 PHY 都不需要。
MQTT 的最小硬件需求：网络栈（WiFi/Ethernet/4G 模块）+ TCP/IP 协议栈。ESP32 自带 WiFi+BLE，批量价大概 12-15 块，跑 FreeRTOS+LwIP+paho MQTT 毫无压力。如果是 4G 模组（合宙 Air724UG 大概 20 块），也能跑 MQTT AT 指令。
OPC UA 对硬件有要求。一个最小 OPC UA Server（支持安全策略 Basic256Sha256、支持 1000 个变量节点）大概需要 256KB RAM + 512KB Flash。你可以在 STM32H7（Cortex-M7, ~30 块）上跑 open62541 的 embedded 版本，但不是「点个灯」那么简单。工业级 OPC UA 网关通常用 ARM Cortex-A 系列的 Linux 板（比如全志 T113-i，四五十块起）。
| 协议 | MCU 价格区间 | 典型硬件平台 |
|---|---|---|
| Modbus RTU | ¥3-10 | STM32F103 / GD32 |
| MQTT (WiFi) | ¥12-20 | ESP32 |
| MQTT (4G) | ¥25-40 | 合宙 Air724UG + MCU |
| OPC UA (轻量) | ¥30-80 | STM32H7 / i.MX RT |
| OPC UA (完整) | ¥80-200 | 全志/瑞芯微 Linux 板 |
**结论：做一个售价 50 块的 Modbus RTU 温湿度传感器，换 OPC UA 方案硬件成本就兜不住。做一台售价 5000 的工业网关，OPC UA 的那点硬件成本根本不是事。**
9. 云接入：协议的天生基因
Modbus 是为本地总线设计的。你不可能直接把 RS-485 怼到阿里云 IoT 平台上。必须过网关——Modbus RTU → 网关（做协议转换）→ MQTT/HTTP → 云端。
MQTT 天然适合云接入。AWS IoT Core、阿里云 IoT、EMQX Cloud、ThingsBoard——所有主流 IoT 平台的第一公民都是 MQTT。主题路由灵活，遗嘱消息（Last Will）解决设备离线检测，保留消息（Retained）确保新上线的订阅者立刻拿到最新状态。
OPC UA 的 Client/Server 模式不太适合云——广域网延迟高，UA 的安全握手和会话管理吃不消。但 OPC UA 有一个 Pub/Sub 扩展（2018 年发布），支持 UDP 多播和 MQTT Broker 传输，专门解决云接入问题。不过目前实际部署的 OPC UA Pub/Sub 案例还不多，更多是 OPC UA Server → 边缘网关 → MQTT → 云的间接路线。
**结论：你的数据终点是云端→MQTT，别犹豫。本地 SCADA/Historian→OPC UA。既上云又本地监控→MQTT+OPC UA 组合。**
10. 历史遗留：改不动就别改
最常见的场景：一个污水处理厂，200 台 Modbus RTU 电表（威胜/科陆/林洋），已经在 RS-485 总线上跑了五年。你现在要上云做能耗管理平台。
把这 200 台电表全换了？不现实。预算是一回事，关键是它们根本没坏。用 Modbus-MQTT 网关是最合理的方案：电表继续跑 Modbus RTU，网关做轮询采集，数据打包成 JSON 走 MQTT 上云。电表这端是稳稳当当的 Modbus，云端是现代 IoT 架构——两头都不吃亏。
同样道理：某汽车厂的涂装车间有 50 台 AB PLC，全跑 EtherNet/IP。你想加一个 MES 系统，让这些 PLC 的数据能被 MES 读到。方案 A：每台 PLC 配 Modbus TCP 模块。方案 B：加一台 KepServer / Ignition 的 OPC UA 网关，聚合 EtherNet/IP 的数据后暴露 OPC UA 接口。方案 B 不改现场设备一根线。
**结论：已有设备跑什么协议就尊重什么协议。用网关做桥接，不要想着把现有设备全升级——那是钱多烧的。**
11. 设备发现：谁知道总线上有什么
Modbus 没有设备发现机制。你要知道从站地址 1 到 247 上到底挂了哪些设备？唯一的方法：挨个发功能码 03（读保持寄存器）或 08（诊断），等回应。超时不回就认为没设备。这个过程叫「地址扫描」——在 9600 bps 下扫完 247 个地址需要几十秒，而且某些设备对未知寄存器的读取会报异常。
MQTT 本身也没有设备发现。设备上线发一条消息到特定主题，但这靠的是约定的业务逻辑，不是协议层面的机制。Sparkplug B 规范加了设备出生/死亡消息，但需要接收方主动监听。
OPC UA 内置了发现服务（Discovery Server，默认端口 4840）。客户端连接 Discovery Server，问「你下面注册了哪些 Server」，拿到列表和端点 URL，再去连接。局域网内还能用 mDNS（组播 DNS）自动发现 OPC UA Server。
**结论：设备经常换、网络拓扑动态变化→OPC UA 的发现服务省你很多配置时间。设备固定不变、装了就不动→Modbus 手动配一遍也不碍事。**
12. 固件升级和配置管理
Modbus 只定义了数据读写。固件升级？没有标准功能码。有些厂商用功能码 0x41-0xFF 的自定义区实现，但每家都不一样，互相不通。
MQTT 同理——传输固件包可以，但格式和流程你自己定。
OPC UA 有标准的方法调用（Method Call）。你可以定义一个「升级固件」方法，接受固件文件 URL 和版本号参数，返回升级进度和结果。Device Integration 配套规范（DI）还定义了标准的设备管理模型。
**结论：批量设备固件升级是核心需求→OPC UA 的方法调用比你自创一套协议靠谱。偶尔升级、现场人员 USB 线怼上去就行→Modbus 够用。**
决策路径，走一遍
你的项目
│
├── 设备数量 > 100？
│ ├── 是 ──→ 需要事件驱动（报警 < 1s 响应）？
│ │ ├── 是 ──→ 需要多种品牌互操作？
│ │ │ ├── 是 ──→ 【OPC UA】
│ │ │ └── 否 ──→ 【MQTT】
│ │ └── 否 ──→ 【Modbus TCP】（配高性能主站，轮询周期可接受）
│ │
│ └── 否 ──→ 需要上云？
│ ├── 是 ──→ 【MQTT】
│ └── 否 ──→ 公网传输 / 需要安全？
│ ├── 是 ──→ 【OPC UA / MQTT+TLS】
│ └── 否 ──→ 【Modbus RTU】
│ 最简单的方案永远最好不是所有场景都走到底选一种协议。大多数时候你选的是组合。
混合架构：真实项目的玩法
经典组合：Modbus RTU → 网关 → MQTT → 云
底层电表、传感器跑 Modbus RTU，用一台嵌入式网关（比如华为 AR650、映翰通 IG902、或者你自己用树莓派+Node-RED 攒的）做协议转换：
┌──────────┐ RS-485 ┌──────────┐ MQTT/TLS ┌─────────────┐
│ 电表 ×50 │───────────→│ Modbus- │───────────→│ 云 IoT 平台 │
│ Modbus │ Modbus RTU│ MQTT 网关│ │ (Ali/AWS) │
│ RTU │ │ │ │ │
└──────────┘ └──────────┘ └─────────────┘网关做两件事：轮询采集 50 台电表的电压/电流/功率/电能，按一分钟间隔打包成 JSON，走 MQTT 发布到云端。电表不换，云端是现代的。这种架构在分布式光伏监控和能耗管理平台上已经被验证无数次。
OPC UA 作为聚合层
工厂里 50 台 Modbus TCP 从站（分布在五个车间），上层 MES 要统一取数据。中间放一台 OPC UA Server 网关，跑 KepServer 或者自己用 open62541 写的程序：
┌────────────┐
│ MES 系统 │
└─────┬──────┘
│ OPC UA Client
▼
┌──────────────────┐
│ OPC UA Server │ ◄── 聚合网关
│ (KepServerEx等) │
└──┬───┬───┬───┬──┘
│ │ │ │ Modbus TCP
▼ ▼ ▼ ▼
50台 Modbus TCP 从站 (PLC/仪表)好处：MES 只对接一个 OPC UA 接口，不用关心每台设备的 IP 地址和寄存器映射。网关内部做了数据聚合和地址空间建模。
双通道：MQTT 上报 + Modbus TCP 本地控制
某智慧农业大棚：50 个 LoRa 温湿度传感器通过 LoRa 网关→MQTT 上报到云平台做趋势分析。同时大棚里的风机、卷帘电机走 Modbus TCP，本地触摸屏（HMI）直接控制。云平台也可以发 MQTT 命令给网关，网关转 Modbus TCP 指令控制风机启停。
┌──────────┐ LoRa ┌────────┐ MQTT ┌──────────┐
│ 传感器×50 │───────→│ LoRa │───────→│ 云平台 │ ← 数据分析
└──────────┘ │ 网关 │ └────┬─────┘
└───┬────┘ │ MQTT 控制指令
│ Modbus TCP ▼
┌───┴────────────┐
│ 本地 HMI + PLC │ ← 实时控制
│ (风机/卷帘) │
└────────────────┘为什么这么设计？传感器上报数据量小但频率高（每分钟），MQTT 省流量。风机控制要求低延迟（< 500ms 必须响应），Modbus TCP 直连最可靠。云平台的分析结果→控制指令的回路走 MQTT，可以接受几百毫秒的延迟。
什么时候不需要混合
如果你的项目不超 30 台设备、不需要上云、不需要远程运维——一台 PLC 带 Modbus RS-485 总线和一块 HMI 屏幕，三根线（A/B/GND），够了。不要为了「先进性」把架构搞复杂。工程里简洁就是可靠性。
协议组合速查表
| 场景 | 设备数 | 上云 | 实时性 | 多品牌 | 推荐方案 |
|---|---|---|---|---|---|
| 污水处理厂本地监控 | 30 台仪表 | 否 | 秒级够 | 否 | Modbus RTU |
| 分布式光伏电站 | 500 台逆变器 | 是(4G) | 报警秒级 | 是 | Modbus RTU + MQTT 网关 |
| 汽车焊装车间 MES | 200 台设备 | 否 | 是 | 是(西门子为主) | OPC UA |
| 智慧农业大棚 | 50 传感器+10 执行器 | 是(LoRa+4G) | 控制百毫秒 | 否 | MQTT Sensor + Modbus TCP Actuator |
| 楼宇自控 | 100 个 DDC 控制器 | 可选 | 秒级够 | 是(HVAC多品牌) | Modbus TCP / BACnet + OPC UA |
| 远程设备运维 | 分散各地 | 是 | 非实时 | 否 | MQTT + TLS |
| 单机设备（变频器+HMI） | < 10 | 否 | 毫秒级 | 否 | Modbus RTU |
没人会替你说的真相
Modbus 没有安全机制，这是真的。它的帧就是明文，CRC 只管传输出错不管恶意篡改。有人把 Modbus TCP 端口暴露在公网上，跟把工厂大门敞开没什么区别。
Modbus 没有事件驱动。你要事件？自己想办法轮询得快一点。
Modbus 没有标准数据模型。A 厂的电表把电压放 40001 寄存器，B 厂放 40002。你的代码里到处都是 if-else 判断设备型号。
但 Modbus 活了四十多年不是靠功能强，是靠够简单。能在 8 位单片机上跑，能在零下三十度稳定运行，能一个下午调通。MQTT 出现了，OPC UA 出现了，它没死，因为还有大量场景不需要高级功能——30 台设备、一个厂房、本地 HMI，Modbus RTU 一条线穿到底，什么叫 over-engineering？硬上 OPC UA 就叫 over-engineering。
反过来，如果你面对的是 500 台设备分布式部署在 50 公里范围内、需要云平台分析、要求报警推送——抱着 Modbus 不放就是在给自己找麻烦。这时候 MQTT 加 Modbus 网关是最务实的选择。
如果你在一个多品牌 PLC 混用的工厂，需要 MES 系统对上层暴露统一接口——OPC UA 是标准答案。
哪个协议都不是完美的，你选的是在你这场景下最不坏的那个。这行的智慧在于：知道什么时候够用就好，知道什么时候必须升级。
发表回复