産業用通信プロトコルの選択：Modbus vs MQTT vs OPC UA

取引を選ぶな

どのフォーラムでも同じ質問があります。“このプロジェクトでModbusとMQTTを使用していますか？OPC UAを使いたいですか？

答えは常にです。まず、サイトにあるデバイスの数、物理層、データの行き先を教えてください。

プロトコル選択は、どちらがより高度かではなく、シナリオで最も問題が少ないかを選択することです。Modbusは1979 yearに、MQTTは1999 yearに、OPC UAは2006 yearに登場しました。必要なのは、“どちらが最善か”という結論ではなく、3分以内に自分で結論を出すことができるエンジニアリング上の意思決定フレームワークです。

一言で3つの合意。

**Modbus RTU/TCP**：各局は各局に質問し、各質問と回答します。フレームフォーマットは固定、アドレス+関数コード+データ+CRC。駅からはイニシアチブを取らず、駅から呼ばれるまで待たなければならない。

例えば、軍事訓練の名前。先生が学校番号を呼ぶと、生徒は“到着”と言います。次のものを呼ぶ。30人のクラス、1人1人、秩序ある。スタッフは大丈夫ですが、500人いたらどうでしょうか。最後の列に着くまで20分が過ぎた。

**MQTT：パブリッシュ/サブスクライブモデル。デバイスはいつ報告するかを決定し、誰にも尋ねる必要はありません。ブローカーは郵便局であり、購読者が受信するトピックにメッセージを投げる装置です。

略称は“マイクログループ”。センサーはグループ内に“I'm overbeed”メッセージを送信し、グループに加入しているすべてのシステムが同時に表示します。誰かが尋ねるのを待つ。

OPC UA：オブジェクト指向の産業用相互運用性フレームワーク。データを送信するだけでなく、セマンティックモデルも付属しています。このデータが“モータ電流”であり、単位はアンペア、値の範囲は0-100、精度は0.1です。セキュリティチャネル、認証証明書、メソッド呼び出しもあります。

外国語翻訳者のように：Siemens PLCはドイツ語を話し、Rockwellは英語を話し、三菱は日本語を話し、OPC UAは共通語への翻訳を担当し、詳細な文法マニュアルも付属しています。

戦わない3つの協定。実際のプロジェクトではよく使われます。

12の選定基準、エンジニアリングのハード指標

1.デバイス数ポーリングの数学的天井

Modbus RTUは、9600 bpsで保持レジスタ（機能コード03）を読み取り、8バイトを送信し、7バイト（アドレス+機能コード+バイト数+2バイトのデータ+2バイトのCRC）を送信し、合計15バイトをステーションから返します。3.5文字のフレーム間隔（約4ms @ 96 00）とスレーブ応答遅延（通常 10-50ms、控えめに20ms）を追加すると：

スレーブごとの単一ポーリング時間=フレーム転送時間+フレーム間隔+スレーブ応答遅延

フレーム転送= 15 × 11 bit ÷ 9600 = 17.2 ms（11 bit/文字：1ビット+8データビット+1チェックビット+1ストップビット）

シングルポーリング≈ 17.2 + 4 + 4 + 20 = 45.2ms

200 台のスレーブステーション、それぞれ10個のレジスタを読み取り（マルチレジスタ読み取りフレームは長く、1フレームは約125個のレジスタをプラグすることができます）、実際のシングルポーリングは約60-80ms/ステーションです。

**200 台 × 70ms = 14 秒。**制御室で画面を見ていると、HMIのデータは14 秒ごとに更新されます。警報信号は14 秒前に道路上にあります。

これは理論上の最適値です。実際のプロジェクトでは、スレーブ応答タイムアウト、再試行、回線品質の低下がこの数を2倍にすることができます。

** 結論：Modbus RTUポーリングサイクルは2-3 秒以内で、ほとんどの監視シナリオで十分です。Modbus TCP（イーサネットはシリアルポート帯域幅を消費しません）またはMQTTを使用している100以上。

2.コミュニケーションモデル：ポーリング対イベント駆動型

Modbusはポーリングです。N 秒ごとにラウンドを尋ねると、ポーリングの間にアラーム信号が発生する可能性がありますが、次のラウンドまで待たなければなりません。

シナリオ：下水処理場で、水のpHが突然7から4に低下しました。Modbusのポーリングサイクルは5 秒ですが、最悪の場合、pHセンサが尋ねられた直後にオーバーシュートし、5 秒近く待たなければなりません。5 秒はプロセス保護には長すぎます。

MQTTはイベントドリブンです。センサーは異常を検出し、すぐにメッセージを送信します。ブローカーは、同じ秒で監視システムに転送されます。レイテンシは、ネットワークレイテンシ+Broker処理時間に依存し、通常は100ms 以内です。

OPC UAはサブスクリプションモデル（MonitoredItem）をサポートしている。クライアントは、関心のあるデータポイントを登録し、サンプリング間隔とトリガ条件を設定する。しきい値を変更するだけで、愚かなポーリング全体ではない。

** 結論：アラーム応答時間が1 秒でModbusポーリングができない場合は、MQTTまたはOPC UAサブスクリプションを選択してください。

3.帯域幅とレイテンシ物理層が下限を決定

RS-485の1，200メートルの限界は、高品質のシールドツイストペア、9，600 bps、1つのデバイスとドライブなしで、私が達成できるものを見てきました。ワークショップの現場では、周波数コンバータが開くと、Communicationエラー率が急上昇し、ボーレートとシールドと絶縁を下げる必要があります。

Modbus RTUは9600 bpsで約800バイト/秒の伝送密度を持つ（開始ビットストップオーバーヘッドを除く）。MQTTは4 Gで、数十KBは問題ありません。OPC UAのバイナリエンコーディング効率は悪くありませんが、接続確立時の証明書交換とセッションネゴシエーションには数百キロバイトが必要です。

** 結論：ローカルバス、帯域幅はボトルネックではない。リモートアクセス、Modbus RTUはパブリックネットワークに直接行きません。北京から石家荘までRS-485ケーブルを引っ張った人を見たことがありません。ゲートウェイを通過しなければならない。

4.データモデルの複雑性：レジスタからオブジェクトへ

Modbusのデータモデルは、コイル（ビット）、ディスクリート入力（ビット）、保持レジスタ（16ビットワード）、入力レジスタ（16ビットワード）の4種類しかない。他に何もない浮動小数点数、文字列、タイムスタンプ、配列構造体はありません。複数のレジスタで自分でエンコードしない限りです。

インバータのデータ：動作状態（ビット）、設定周波数（浮動小数点、2つのレジスタを占める）、実際の周波数（浮動小数点）、出力電流（浮動小数点）、バスバー電圧（整数）、動作時間（32ビット、2つのレジスタ）、アラームコード（ビットマスク）すべてModbusレジスタで実装するには、どのレジスタがどのパラメータに対応し、どのコードを使用するかを記録するExcelシートを維持する必要があります。10台のインバータには数百個のレジスタのマッピングテーブルが散らばっています。

MQTTはあまり良くありません。JSONは自由形式ですが、freqency、freq、Hz、output_freqと呼ばれるFrequencyフィールドがあります。基準はなく、自分で決めなさい。

OPC UAの情報モデル（IM）は、プロトコル層からこの問題を解決します。各データポイントには、Type、Unit、Range、EngineeringUnitがあります。MotorTypeオブジェクトの下にはCurrent、Temperature、Speedがあります。これはベアレジスタではなく、固有のセマンティクスです。

** 結論：50のデータポイント、単純な型（すべて整数/スイッチ）、Modbusレジスタマップで十分です。複雑なオブジェクトモデルを含む200以上のポイントにより、OPC UAはドキュメント管理の労力を半分に削減します。

5.セキュリティ：誰が裸で走る？

Modbusの設計時代（1979 year）、誰もサイバーセキュリティを考えませんでした。RTUフレームには認証フィールドがなく、RS-485バスにアクセスする任意のデバイスは、ポンプのオフ、パラメータの変更、レジスタへの書き込みなどのコマンドを発行できます。TCPバージョンはTCPコネクションの追加レイヤを提供しますが、TLSは組み込まれていません。

MQTTはTLS暗号化、ユーザー名/パスワード認証、ブローカー側でACLを介して送信でき、どのクライアントがどのトピックを公開/購読できるかを制御できます。

OPC UAのセキュリティモデルは、証明書認証（X.50 9）+メッセージ署名+メッセージ暗号化の3つのピースセットです。ユーザートークン（ユーザー名パスワード/証明書/匿名性）もサポートされています。接続確立からデータ転送まで、フルリンク暗号化。

ある水道工場に行って確認したところ、Modbus TCPゲートウェイパブリックポートが開いていて、インバータのスタートストップレジスタに直接書き込むことができました。冗談ではありません中小企業ではたくさんあります

** 結論：パブリックトランスポート、リモート保守、重要インフラストラクチャを含むシナリオ-ベアModbusを使用しないでください。少なくともMQTT+TLSゲートウェイを通過します。OPC UA機能が既にある場合は、セキュアチャネルを直接使用してください。

6.相互運用性：誰のデバイスと話すか

理想的には、すべてのデバイスが同じプロトコルを実行することです。Siemens、Schneider、ABはProfinetを使用しています。現実はそうではない

Modbusの利点はまさにここにあります。Siemens S 7 -1200のCM1241モジュールや三菱 FXシリーズのRS-485ポートなど、ほぼすべてのPLCがModbus RTU/TCPをサポートしています。機器メーカーも喜んでサポートしています-ロイヤルティなし、実装は簡単で、数日で調整できます。

MQTTの相互運用性は、トピック構造とJSON形式の合意に依存します。しかし、家族の合意は異なるかもしれません。Sparkplug B仕様 ** は、標準のトピック名前空間、データ型エンコーディング、デバイスの誕生/死亡メッセージを定義し、この穴を埋めます。

OPC UAの相互運用性はプロトコルに組み込まれているコンパニオン仕様Companion Specificationは、ロボット、射出成形機、CNC、風力発電など、数十の業界をカバーしている。SiemensのOPC UA ServerとRockwellのOPC UA Clientは、マッピング層コードを記述することなく直接通信できます。

しかし、OPC UAのコンパニオン仕様はまだ開発中であり、すべてのデバイスでサポートされていません。一部のベンダーのOPC UA実装は、ノードがブラウズできるが、実際のデータ更新頻度が追いつかないようなバッグです。

** 結論：複数のブランドPLC/DCSとの相互運用性はハード要件→OPC UAです。機器はすべて国産のメーター/センサー →Modbus RTUで十分です。クラウドプラットフォームのドッキング→MQTTが必要です。**

7.開発サイクルとチームスキル

これは非常に過小評価です。

Modbus開発：シリアルライブラリを見つけ、8バイトを送信し、7バイトを受信し、2日間調整し、合格します。プロトコルスタックのコードvalueは数百行である. PythonのpymodbusやC#のNModbusを使えば、午前中にパッケージをセットアップして午後にレジスタを読み書きできます。Modbusマスタードライバを3日でCompleteさせたエンジニアはたくさんいます。

MQTT開発：Paho-mqttライブラリ、ブローカーアドレス、ポート、トピック、3行のコードをインストールします。発行/購読各2行1日手で。Brokerデプロイメント（Mosquitto/EMQX）は30分で完了しました。

OPC UA開発：正直に言うと簡単ではありません。アドレス空間モデリング、証明書管理、セキュリティポリシーの設定、サブスクリプション/メソッド呼び出しなど、学習曲線は最初の2つよりもはるかに急です。UAExpertクライアントを使用してサーバーに接続することと、完全なOPC UAサーバーを自分で書くことは別のことです。業界では、KepServerExやSiemens OPC UA Serverなどの成熟した製品が一般的で、SDKはほとんど調整され、ゼロからの書き込みはほとんどありません。OPC UAの経験がないチームは、技術検証のために2-4週間を予約します。

** 結論：開発の3日間→Modbus。MQTTの1日開発。専門家とプロジェクトは学習コスト→OPC UAを可能にします。

8.ハードウェアコスト：チップレベルの価格差

RS-485トランシーバ（MAX485/SP 3485）のロット価格は1元未満です。2つの120Ω終端抵抗、TVS保護管を追加すると、BOMコストは3元以内です。STM 32 F 103はUARTペリフェラルを直接駆動し、外部 PHYを必要としません。

MQTTの最小ハードウェア要件：ネットワークスタック（WiFi/イーサネット/4 Gモジュール）+ TCP/IPプロトコルスタック。ESP32にはWiFi+BLEが付属しており、ボリューム価格は約12-15ブロックで、Free RTOS +LwIP+Paho MQTTをストレスなく実行します。4 Gモジュール（Air724UGで約20個）であれば、MQTT ATコマンドも実行できます。

OPC UAにはハードウェアが必要。最小のOPC UAサーバ（Security Policy Basic256Sha256をサポートし、1，000個の変数ノードをサポート）は、約256KBのRAMと512KBのFlashを必要とします。STM 32 H 7（Cortex-M 7、~30ブロック）上でopen 625 41の埋め込みバージョンを実行することができますが、“ライトを点ける”だけではありません。インダストリアルグレードのOPC UAゲートウェイは、通常、ARM Cortex-AシリーズLinuxボード（例えば、Tunchi T 113-i、40 ~ 40ブロック）を使用します。

** 結論：50個のModbus RTU温度湿度センサを作るには、OPC UAソリューションのハードウェアコストを置き換えることはできません。5，000ドルの産業用ゲートウェイを作るには、OPC UAのハードウェアコストは全く問題ありません。

9.クラウドアクセス：プロトコルの自然な遺伝子

Modbusはローカルバス用に設計された。RS-485をAlibaba Cloud IoTプラットフォームに直接接続することはできません。ゲートウェイを通過する必要があります-Modbus RTU →ゲートウェイ（プロトコル変換）→ MQTT/HTTP →クラウド

MQTTはクラウドアクセスに最適です。AWS IoT Core、Alibaba Cloud IoT、EMQX Cloud、ThingsBoardなど、すべての主要なIoTプラットフォームの最初の市民はMQTTです。件名のルーティングは柔軟で、遺言メッセージ（Last Will）はデバイスのオフライン検出を解決し、メッセージを保留する（Retained）は新たにオンラインになった加入者がすぐに最新のステータスを取得することを保証する。

OPC UAのクライアント/サーバモデルはクラウドには適していません。WANのレイテンシが高く、UAのセキュアなハンドシェイクとセッション管理が困難です。しかし、OPC UAにはPub/Sub拡張機能（2018 yearリリース）があり、UDPマルチキャストとMQTT Brokerトランスポートをサポートし、クラウドアクセスの問題に特に対処します。しかし、OPC UA Pub/Subの実際の展開はあまりなく、OPC UA Server →エッジゲートウェイ→ MQTT →クラウドの間接的なルートが多い。

** 結論：データのエンドポイントはクラウド→MQTTです。ローカルSCADA/Historian→OPC UAクラウドとオンプレミスの両方の監視→MQTT+OPC UAの組み合わせ **

10.歴史の遺産：変わらない

最も一般的なシナリオ：200 台のModbus RTUメーター（Weiseng/Kolu/Lin Yang）が5年間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までのデバイスを知っていますか？唯一の方法は、関数コード0 3（読み取りおよび保持レジスタ）または0 8（診断）をそれぞれ送信して応答することです。タイムアウトしないとデバイスなしとみなされます。このプロセスは“アドレススキャン”と呼ばれ、9600 bpsで247個のアドレスをスキャンするのに数十秒かかり、Unknownのレジスタを読み取るデバイスによっては異常が報告されます。

MQTT自体にはデバイス検出がない。デバイスは特定のトピックにメッセージを送信しますが、これはプロトコルレベルのメカニズムではなく、合意されたビジネスロジックに依存します。Sparkplug B仕様はデバイスの出生/死亡メッセージを追加しますが、受信者が積極的にリスニングする必要があります。

OPC UAにはディスカバリサービス（Discovery Server、デフォルトポート48 40）が組み込まれています。クライアントはDiscovery Serverに接続し、“どのサーバーを登録していますか？”と尋ね、リストとエンドポイントURLを取得して接続します。ローカルエリアネットワーク内では、mDNS（マルチキャストDNS）を使用してOPC UA Serverを自動検出することもできます。

** 結論：頻繁なデバイス交換、ネットワークトポロジの動的変化→OPC UAディスカバリサービスは、設定時間を大幅に節約します。機器は固定、取り付けた場合は動かない→Modbus手動で一度でも問題ありません。**

12.ファームウェアのアップグレードと構成管理

Modbusはデータの読み書きのみを定義します。ファームウェアのアップグレード？標準機能コードなし。一部のメーカーは関数コード0 x 41- 0 x FFのカスタム領域を実装していますが、それぞれが異なり、相互に理解できません。

MQTTも同じです。ファームウェアパッケージを転送できますが、フォーマットとフローはあなた次第です。

OPC UAには標準的なメソッドコールMethod Callがある。ファームウェアファイルURLとバージョン番号パラメータを受け取り、アップグレードの進捗状況と結果を返す“ファームウェアのアップグレード”メソッドを定義できます。Device Integration Component Specification（DI）は、標準デバイス管理モデルも定義しています。

** 結論：バルクデバイスファームウェアアップグレードはコア要件です→OPC UAメソッド呼び出しは、独自のプロトコルセットよりも信頼性が高いです。時折アップグレードし、現場の人がUSBケーブルを使用すれば、Modbusで十分です。*

意思決定、もう一度。

あなたのプロジェクト。
│ │ │
機器の数は100ですか？
│ │ │   - はい-イベント駆動型（アラーム1s応答）が必要ですか？
│ │ │   │ │ │         - はい-複数のブランドが相互運用可能ですか？
│ │ │   │ │ │         │ │ │         ああ、そうだ、OPC UA。
│ │ │   │ │ │         │ │ │         ┃ ─ ─【MQTT】
│ │ │   │ │ │         Wate-No--→ 【Modbus TCP】（高性能マスタ、ポーリングサイクル許容）
│ │ │   │ │ │
│ │ │   いいえ、雲が必要ですか？
│ │ │              ああ、そうだ、ああ、ああ、ああ、ああ、
│ │ │              W-NO--→公衆通信/セキュリティが必要ですか？
│ │ │                        OPC UA / MQTT+TLS（OPC UA）
│ │ │                        3-いいえ-→（Modbus RTU）
│ │ │                                  最も簡単なプログラムは常に最高です。

すべてのシナリオが最終的に合意を選ぶわけではない。ほとんどの場合、組み合わせを選びます。

ハイブリッドアーキテクチャ：実際のプロジェクトの遊び方

Modbus RTU →ゲートウェイ→ MQTT →クラウド

基盤となるメーターとセンサーはModbus RTUを実行し、組み込みゲートウェイ（Huawei AR650、Yinghong IG902、またはRaspberry Pi +Node-REDなど）を使用してプロトコルを変換します。

��-----RS-48 5    ― ― ― ― ― ― ― MQTT/TLS ― ― ― ― ―
│電気メーター ×50 │ ― ― ― ― ― ― ― →│ Modbus ― ― ― ― ― ― ― ― →│クラウドIoTプラットフォーム│
│ Modbus   Modbus RTU MQTTゲートウェイ            │/AWS   │ │ │
│ RTU      │ │ │            │ │ │          │ │ │            │ │ │             │ │ │
その― ― ― ― ― ― ― ― ― ― ― ― ―            その― ― ― ― ― ― ― ― ― ― ― ― ―            3-------------------

ゲートウェイは2つのことを行います。50 台のメーターの電圧/電流/電力/電力をポーリングし、1分間隔でJSONにパッケージ化し、MQTTを実行してクラウドに公開します。電気は変わらず、クラウドはモダンです。このアーキテクチャは、分散型太陽光監視およびエネルギー管理プラットフォームで何度も実証されています。

集約層としてのOPC UA

工場内には50 台のModbus TCPスレーブ（5つのワークショップに分散）があり、上位MESはデータを収集します。OPC UA Serverゲートウェイを中央に置き、KepServerを実行するか、open 625 4 1で独自のプログラムを作成します。

������������
│ │ │   MESシステム│
その― ― ― ― ― ― ― ― ― ― ―
      OPC UAクライアントのレビュー
      ▼ ▼ ▼
������������
OPC UAサーバー   ● ● ● ●ゲートウェイ
KepServerExなど│
― ― ― ―
   │ │ │   │ │ │   │ │ │   Modbus TCP
   ▼ ▼ ▼   ▼ ▼ ▼   ▼ ▼ ▼   ▼ ▼ ▼
  Modbus TCPスレーブ（PLC/メーター）50台

利点：MESは1つのOPC UAインターフェイスのみを接続し、各デバイスのIPアドレスやレジスタマッピングを気にしません。ゲートウェイ内部でデータ集約とアドレス空間モデリングを行います。

デュアルチャネル：MQTTエスカレーション+ Modbus TCPローカル制御

スマート農業温室：トレンド分析のためにLoRaゲートウェイ→MQTT経由で50個のLoRa温度湿度センサーをクラウドプラットフォームに報告します。同時に、温室内のファン、ローラーシャッターモータはModbus TCPを取り、ローカルタッチスクリーン（HMI）を直接制御します。クラウドプラットフォームはゲートウェイにMQTTコマンドを送信し、ゲートウェイはModbus TCPコマンドでブロワの起動とStopを制御することもできます。

― ― ― ― ― ― ― ― ― ― LoRa ― ― ― ― ― ― ― ― ― ―
│センサー × 50 │ ― ― ― ― ― ― → │ LoRa   │---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------    │ ←データParse
その― ― ― ― ― ― ― ― ― ― ― ― ―        │ゲートウェイ   │ │ │        ↓ ― ― ― ― ― ― ― ― ― ― ― ― ―
                    その― ― ― ―             MQTTコントロールコマンド
                        Modbus TCP      ▼ ▼ ▼
                    ��������������
                    ローカルHMI + PLCリアルタイム制御
                    │ │/    │ │ │
                    3-------------------

なぜデザインなのか？センサーはデータvalueが小さいが頻度が高い（毎分）ため、MQTTはトラフィックを節約します。ブロワ制御には低遅延（500ms応答）が必要で、Modbus TCP直接接続が最も信頼性が高い。クラウドプラットフォームの分析結果→制御命令のループはMQTTを通過し、数百ミリ秒の遅延を受け入れることができます。

混合する必要がないとき。

プロジェクトが30 台以上のデバイスを持たず、クラウドに接続する必要がなく、リモートOperationする必要がない場合は、Modbus RS-485バスとHMIスクリーンを備えた1台のPLC、3本のライン（A/B/GND）で十分です。“高度”のために構造を複雑にしないでください。エンジニアリングのシンプルさは信頼性。

プロトコル組み合わせクイックチェックシート

誰もあなたのために真実を話さない。

Modbusにはセキュリティメカニズムがありません。そのフレームは平文であり、CRCは悪意のある改ざんに関係なく送信エラーのみを送信します。Modbus TCPポートをパブリックネットワークに公開することは、工場のドアを開くことと変わりません。

Modbusにはイベント駆動がない。イベントが必要ですか？自分でもっと速く投票する方法を見つけてください。

Modbusには標準データモデルはない。A工場のメーターは40001レジスタに電圧を、B工場は40002レジスタに電圧を置きます。コードはデバイスモデルを決定するif-elseでいっぱいです。

しかしModbusは40年以上生きてきました強力ではなくシンプルでした8ビットマイクロコントローラ上で実行することができ、マイナス30度で安定して動作することができ、午後に調整することができます。MQTTが登場し、OPC UAが登場しましたが、高度な機能を必要としないシナリオがたくさんあるため、死んでいません。30台のデバイス、1つのプラント、ローカルHMI、Modbus RTU、1つのワイヤスルー、オーバーエンジニアリングとは何ですか？OPC UAはオーバーエンジニアリングと呼ばれます。

逆に、50 km以内に分散して展開された500 台のデバイスに直面し、クラウドプラットフォーム分析が必要で、アラームプッシュが必要な場合、Modbusを保持することは自分自身に問題をもたらします。MQTTとModbusゲートウェイは、現時点で最も実用的なオプションです。

マルチブランドPLCが混在する工場では、MESシステムが上位層にユニファイドインターフェイスを公開する必要がある場合、OPC UAが標準的な答えです。

どのプロトコルも完璧ではなく、あなたのシナリオで最悪のものを選びます。この分野の知恵は、適切なときとアップグレードする必要があるときを知ることです。