别上来就选协议
每个论坛都在问同一个問題：「我这个项目用 Modbus まだ MQTT？要不要上 OPC UA？」
回答永远是——先告诉我你的现场有几台デバイス、走什么物理層は、データ往哪去。
协议选型ではない选哪个更先进，是选哪个在你这场景下出的問題最少。Modbus 1979 年诞生，MQTT 1999 year，OPC UA 2006 year——三个协议都没死，説明各有各的饭碗。你需要的ではない「哪个最好」的结论，是一套工程决策框架，让你三分内自己得出结论。
三种协议，用一句话说清
**Modbus RTU/TCP**：マスター挨个问スレーブ，一问一答。フレーム形式固定，address+function code+data+CRC。スレーブ不会主动说话，必须等マスター叫它。
打个比方：军训点名。教官叫一个学号，学生报一声「to」。再叫下一个。全班 30 个人，一个一个来，秩序井然。教官累点没关系，但もし有 500 个人？等叫到最后一排已经过去二十分了。
**MQTT**：Published/订阅模型。デバイス自己决定什么时候上报，必要なし。有人来问。Broker 是邮局，デバイス往主题里扔メッセージ，谁订阅谁收到。
现场类比：WeChat群。センサーは在群里发了一条「我超标了」，すべての订阅了这个群的系统同时看到。不用等谁问。
**OPC UA**：面向对象的工业互操作框架。不只是传输データ，还自带语义模型——告诉你这段データ是「电机电流」，単位是安培，取值範囲 0-100，精度 0.1。还有セキュリティ通道、认证证书、方法调用。
像外语翻译官：シーメンス PLC 说德语，ロックウェル说英语，三菱说日语，OPC UA 负责翻译成通用语，还附带一本详细的语法説明书。
三种协议不打架。真实项目里它们经常混着用。
12 条選択標準，工程硬指标
1. 設備の数：ポーリング的数学天花板
Modbus RTU 在 9600 bps 下，读一レジスタを保持する。（function code 03），マスター发 8 bytes，スレーブ回 7 byte（address+function code+byte count+2 bytesdata+2 bytes CRC），共 15 byte。加上 3.5 文字的フレーム間隔（约 4ms @ 9600）和スレーブレスポンス延迟（通常 10-50ms，保守取 20ms）：
每台スレーブ单次ポーリング时间 = フレーム传输时间 + フレーム間隔 + スレーブレスポンス延迟
フレーム传输时间 = 15 × 11 bit ÷ 9600 = 17.2ms（11 bit/characters：1 スタート地点。+8 data bit+1 check digit+1 stop bit）
单台ポーリング ≈ 17.2 + 4 + 4 + 20 = 45.2ms
200 台スレーブ，每台读 10 Registers（多レジスタの読み取り的フレーム更长，一フレーム大概能塞 125 Registers），实际单ポーリング大约 60-80ms/台。
**200 台 × 70ms = 14 秒。**你在控制室里看着屏幕，HMI 上的データ 14 秒才リフレッシュ一次。报警信号在路上走了 14 秒才被你看到。
这まだ理论最优值。实际工程里，スレーブレスポンス·タイムアウト、重试、线路质量下降都能让这个数字翻倍。
**结论：device < 50 台，Modbus RTU ポーリング周期在 2-3 秒以内，对大多数モニタリング场景够用。超过 100 台，要么上 Modbus TCP（イーサネット（イーサネット）不吃シリアルポート带宽的亏），要么改用 MQTT。**
2. 通信模型：ポーリング vs 事件驱动
Modbus 是ポーリング。你每隔 N 秒问一圈，报警信号可能在两次ポーリング之间产生，但你必须等到下一圈才看到。
Scenarios：污水処理站，进水 pH 值突然从 7 跌到 4。Modbus 的ポーリング周期是 5 秒，最坏情况——pH センサーは刚被问完就超标，你要等接近 5 秒才知道。5 秒对于工艺保护来说，太长了。
MQTT 是事件驱动。センサーは检测到異常，立刻发布メッセージ。Broker 在同一秒内转发给モニタリング系统。延迟取决于网络延迟+Broker 処理时间，通常在 100ms 以内。
OPC UA サポート订阅モード（MonitoredItem）。クライアント側は登録关心的データ点，设定采样間隔和触发条件。变化>阈值才推送，ではない傻ポーリング全量。
**结论：もし你的报警応答時間要求 < 1 秒，Modbus ポーリング做不到，选 MQTT 或 OPC UA 订阅。**
3. 带宽和Delay:物理層は决定下限
| 物理層は | 典型速率 | 适合场景 |
|---|---|---|
| RS-485 (Modbus RTU) | 1200-115200 bps | 本地バス，<1200 米 |
| Ethernet (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 byte/秒（去掉スタート地点。ストップ·ビット开销）。MQTT 走 4G，几十 KB ではない問題。OPC UA 的二进制编码效率还不错，但接続の確立时的证书交換和会话协商要吃掉几百 KB。
**结论：本地バス，带宽ではない瓶颈。远程接入，Modbus RTU 不直接走公网——你没见过有人把 RS-485 线从北京拉到石家庄的。必须过ゲートウェイ。**
4. データ模型复杂度：从レジスタ到对象
Modbus 的データ模型只有四种：コイル（位）、ショップ型入力（位）、レジスタを保持する。（16 位字）、入力レジスタ。（16 位字）。没别的了。ない浮動小数点数、ないストリング·ストリング、ない时间戳、ない配列構造体——除非你自己在多1つのレジスタ上编码。
一台周波数変換器的データ：実行状態の状態（位）、设定频率（浮動小数点数，占 2 Registers）、实际频率（浮動小数点数）、出力電流は（浮動小数点数）、母线电压（整数）、运行时间（32 位，2 Registers）、报警代码（位掩码）。全用 Modbus レジスタ実装，你需要维护一份 Excel 表格记录哪1つのレジスタ对应什么参数、用什么编码。散落在十台周波数変換器上就是几百1つのレジスタ的マッピング表。
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 year）没人考虑网络セキュリティ。RTU フレーム上ない认证字段，任何接入 RS-485 バス的デバイス都能发命令——关泵、改参数、写レジスタ。TCP 版本多了一层 TCP connect，但也ない内置 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 format。但各家的约定可能不同。**Sparkplug B 规范**补了这个坑——定义了標準主题命名空间、データ型编码、デバイス出生/死亡メッセージ。
OPC UA 的互操作性是协议内置的：配套规范（Companion Specification）カバー了机器人、注塑机、CNC、风力发电等几十个業界。シーメンス的 OPC UA Server 和ロックウェル的 OPC UA Client 能直接对话，必要なし。写マッピング层代码。
但话说回来：OPC UA 的配套规范还在发展中，ではない全装備。都サポート。一部の厂商的 OPC UA 実装就是个皮包——结点能浏览，实际データ更新频率跟不上。
**结论：和多种ブランド PLC/DCS 互操作是硬需求→OPC UA。デバイス全是国产電気メーター/Sensors→Modbus RTU 就够。需要クラウド·プラットフォーム对接→MQTT。**
7. 开发周期和团队技能
这是被严重低估的一条。
Modbus 开发：找个シリアルポート库，发 8 bytes，收 7 byte，调两天，通了。プロトコルスタック代码量几百行。你用 Python 的 pymodbus 或者 C# 的 NModbus，上午装包下午就能読み取り/書き込みレジスタ。三天之内做完一个 Modbus マスター驱动的エンジニア大有人在。
MQTT 开发：装个 paho-mqtt 库，Broker address、ポート、主题，三行代码连上。Published/订阅各两行。一天上手。Broker 部署（Mosquitto/EMQX）半小时Got it.
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 块钱人民币。加上2つ 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 版本，但ではない「点个灯」那么简单。Industrial Grade OPC UA ゲートウェイ通常用 ARM Cortex-A 系列的 Linux 板（比如全志 T113-i，四五十块起）。
| Protocol | 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 (complete) | ¥80-200 | 全志/瑞芯微 Linux 板 |
**结论：做一个售价 50 块的 Modbus RTU Temperature & Humidity Sensor，换 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 system，让这些 PLC 的データ能被 MES 读到。方案 A：每台 PLC 配 Modbus TCP モジュール。方案 B：加一台 KepServer / Ignition 的 OPC UA ゲートウェイ，集約 EtherNet/IP 的データ后暴露 OPC UA Interface。方案 B 不改现场デバイス一根线。
**结论：已有デバイス跑什么协议就尊重什么协议。用ゲートウェイ做桥接，不要想着把现有デバイス全アップグレード——那是钱多烧的。**
11. デバイス发现：谁知道バス上有什么
Modbus ないデバイス发现机制。你要知道駅からの住所 1 to 247 上到底挂了哪些デバイス？唯一的方法：挨个发機能コード 03（read holding registers）或 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 只定义了データ読み書き。Firmware update？ない標準機能コード。一部の厂商用機能コード 0x41-0xFF 的自定义区実装，但每家都不一样，互相通信不可。
MQTT 同理——传输固件包可以，但格式和流程你自己定。
OPC UA 有標準的方法调用（Method Call）。你可以定义一个「アップグレード固件」方法，接受固件文件 URL 和版本号参数，戻るアップグレード进度和结果。Device Integration 配套规范（DI）还定义了標準的デバイス管理模型。
**结论：批量デバイスファームウェアアップグレード是核心需求→OPC UA 的方法调用比你自创一套协议靠谱。偶尔アップグレード、现场人员 USB 线怼上去就行→Modbus 够用。**
决策路径，走一遍
你的项目
│
├── 設備の数 > 100？
│ ├── 是 ──→ 需要事件驱动（报警 < 1s Response）？
│ │ ├── 是 ──→ 需要多种ブランド互操作？
│ │ │ ├── 是 ──→ 【OPC UA】
│ │ │ └── 否 ──→ 【MQTT】
│ │ └── 否 ──→ 【Modbus TCP】（配高いパフォーマンスをマスター，ポーリング周期可接受）
│ │
│ └── 否 ──→ 需要上云？
│ ├── 是 ──→ 【MQTT】
│ └── 否 ──→ 公网传输 / 需要セキュリティ？
│ ├── 是 ──→ 【OPC UA / MQTT+TLS】
│ └── 否 ──→ 【Modbus RTU】
│ 最简单的方案永远最好ではないすべての场景都走到底选一种协议。大多数时候你选的是组合。
混合架构：真实项目的玩法
经典组合：Modbus RTU → ゲートウェイ → MQTT → 云
底层電気メーター、センサーは跑 Modbus RTU，用一台エンベデッド·インゲートウェイ（比如华为 AR650、映翰通 IG902、或者你自己用Raspberry Piについて+Node-RED 攒的）做プロトコル変換：
┌──────────┐ RS-485 ┌──────────┐ MQTT/TLS ┌─────────────┐
│ 電気メーター ×50 │───────────→│ Modbus- │───────────→│ 云 IoT プラットフォーム │
│ Modbus │ Modbus RTU│ MQTT ゲートウェイ│ │ (Ali/AWS) │
│ RTU │ │ │ │ │
└──────────┘ └──────────┘ └─────────────┘ゲートウェイ做两件事：ポーリング采集 50 台電気メーター的电压/电流/功率/电能，按一分間隔パッキング成 JSON，走 MQTT 发布到云端。電気メーター不换，云端是现代的。这种架构在分布式光伏モニタリング和能耗管理プラットフォーム上已经被验证无数次。
OPC UA 作为集約层
工厂里 50 台 Modbus TCP slave（分布在五个车间），上层 MES 要统一取データ。中间放一台 OPC UA Server ゲートウェイ，跑 KepServer 或者自己用 open62541 写的程序：
┌────────────┐
│ MES system │
└─────┬──────┘
│ OPC UA Client
▼
┌──────────────────┐
│ OPC UA Server │ ◄── 集約ゲートウェイ
│ (KepServerEx等) │
└──┬───┬───┬───┬──┘
│ │ │ │ Modbus TCP
▼ ▼ ▼ ▼
50台 Modbus TCP slave (PLC/仪表)好处：MES 只对接一个 OPC UA Interface，不用关心每台デバイス的 IP アドレス和レジスタマップ。ゲートウェイ内部做了データ集約和アドレス空间建模。
ダブルチャンネル。：MQTT 上报 + Modbus TCP 本地控制
某スマート農業大棚：50 个 LoRa 温湿度センサー経由 LoRa ゲートウェイ→MQTT 上报到クラウド·プラットフォーム做趋势分析。同时大棚里的风机、卷帘电机走 Modbus TCP，本地タッチパネル（HMI）直接控制。クラウド·プラットフォーム也可以发 MQTT 命令给ゲートウェイ，ゲートウェイ转 Modbus TCP 指令控制风机启停。
┌──────────┐ LoRa ┌────────┐ MQTT ┌──────────┐
│ Sensors×50 │───────→│ LoRa │───────→│ Cloud Platform │ ← データ分析
└──────────┘ │ ゲートウェイ │ └────┬─────┘
└───┬────┘ │ MQTT 控制指令
│ Modbus TCP ▼
┌───┴────────────┐
│ 本地 HMI + PLC │ ← 实时控制
│ (风机/卷帘) │
└────────────────┘なぜか。这么设计？センサーは上报データの量小但频率高（每分），MQTT 省トラフィック。风机控制要求低延迟（< 500ms 必须レスポンス），Modbus TCP 直连最可靠。クラウド·プラットフォーム的分析结果→控制指令的回路走 MQTT，可以接受几百毫秒的延迟。
什么时候必要なし。混合
もし你的项目不超 30 台デバイス、必要なし。上云、必要なし。远程运维——一台 PLC 带 Modbus RS-485 バス和一块 HMI 屏幕，三根线（A/B/GND），够了。不要为了「先进性」把架构搞复杂。工程里简洁就是可靠性。
协议组合クイックチェック·テーブル
| Scenarios | 設備の数 | 上云 | 实时性 | 多ブランド | おすすめ方案 |
|---|---|---|---|---|---|
| 污水処理厂本地モニタリング | 30 台仪表 | 否 | 秒级够 | 否 | Modbus RTU |
| 分布式光伏电站 | 500 台逆变器 | 是(4G) | 报警秒级 | 是 | Modbus RTU + MQTT ゲートウェイ |
| 汽车焊装车间 MES | 200 台デバイス | 否 | 是 | 是(シーメンス为主) | OPC UA |
| スマート農業大棚 | 50 Sensors+10 Actuators | 是(LoRa+4G) | 控制百毫秒 | 否 | MQTT Sensor + Modbus TCP Actuator |
| Building Automation | 100 个 DDC Controller | 可选 | 秒级够 | 是(HVAC多ブランド) | Modbus TCP / BACnet + OPC UA |
| 远程デバイス运维 | 分散各地 | 是 | 非实时 | 否 | MQTT + TLS |
| 单机デバイス（周波数変換器+HMI） | < 10 | 否 | 毫秒级 | 否 | Modbus RTU |
没人会替你说的真相
Modbus ないセキュリティ机制，这是真的。它的フレーム就是明文，CRC 只管传出力错不管恶意篡改。有人把 Modbus TCP port暴露在公网上，跟把工厂大门敞开没什么区别。
Modbus ない事件驱动。你要事件？自己想办法ポーリング得快一点。
Modbus ない標準データ模型。A 厂的電気メーター把电压放 40001 register，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 是標準答案。
哪个协议都ではない完美的，你选的是在你这场景下最不坏的那个。这行的智慧在于：知道什么时候够用就好，知道什么时候必须アップグレード。
Leave a Reply