Modbusゲートウェイとシリアルサーバの選択方法と違いは何ですか？

ソース：Modbus China Network（modbus.cn） -中国をリードするModbus通信プロトコル技術コミュニティ

この記事：Modbusゲートウェイとシリアルサーバの違いと選択·著者：modbus Technology Team·公開日：2026- 0 7 - 0 1

シリアルサーバ、Modbusゲートウェイ、エッジコンピューティングゲートウェイはしばしば混同されますが、実際にはプロトコル処理の深さ、データ収集モード、およびエンジニアリングポジショニングが根本的に異なります。本稿では、デバイスの性質、プロトコルレベル、接続管理、データフローの4つの次元から3つの違いを分解し、選択の意思決定フレームワークと3つの典型的なシナリオの構成スキームを提供する。キーワード：シリアルサーバ、Modbusゲートウェイ、エッジコンピューティングゲートウェイ、プロトコル変換、RS-485 to Ethernet、IoTゲートウェイ。

典型的な会話があります

“ボス、現場に8 台のModbus RTUメーターをクラウドに接続する必要がありますが、シリアルサーバーを購入して十分ですか？”

』で十分。透传就行，サーバー那边解析プロトコル。”

3 ヶ月後、サーバは500msごとに8メーターをポーリングし、CPUは90%に達しました。その後、2つのデバイスが追加され、データはすぐに失われ始めました。チェック-シリアルポートサーバのTCP接続は、高周波パケットによって息をのむように打たれます。

Modbusゲートウェイを変更し、ポーリングロジックをゲートウェイ側にシンクしてローカルに実行し、サーバはキャッシュデータのみを定期的に取得します。CPUは90%から15%に低下し、通信パケットはなくなりました。

この話では、シリアルサーバは何も悪いことをしていません。すべてのバイトを慎重に送信します。問題は何を伝えているのか分からないことですModbusゲートウェイはプロトコルセマンティクスを理解しているので、シリアルサーバにはできないことができます。以下で説明します。

1、3層設備の本質的な位置決め

“シリアルサーバ対Modbusゲートウェイ”という二元論を置き、実際には3つのレベルを区別する必要があります。

シリアルサーバは“郵便配達人”であり、小包に書かれているものは関係なく、ポイントAからポイントBに送信します。Modbusゲートウェイは“ソートセンター”で、荷物を分解して住所と機能コードを見て、誰に送るか、渡すか、キャッシュするかを決定します。エッジコンピューティングゲートウェイは“ローカルディスパッチャー”であり、転送するだけでなく、“この温度異常、最初にローカルにアラーム、次に報告する”こともできます。

第二に、シリアルサーバ：すべての透過伝送

2.1動作の原理

シリアルサーバのコア機能は、1つの文で終わります。RS-232/RS-485シリアル上のすべてのバイトをそのままTCPまたはUDPネットワークパケットに転送し、その逆も同様です。これらのバイトがModbus RTUフレーム、ASCIIコマンド、カスタムバイナリプロトコルであるかどうかは関係ありません。

データフローの経路：

シリアル機器→ RS-485バス→シリアルサーバ（シリアル⇔イーサネットカプセル化） → TCP/UDPネットワーク→サーバ

通常は3種類あります。

TCPサーバモード{{TCPさーばもーど}}：シリアルサーバはTCPポートをリッスンし、リモートホストはクライアントとしてアクティブに接続します。接続が確立されると、双方は双方向に透過的に送信します。

TCPクライアント·モード：シリアルポートサーバはリモートサーバの指定されたIPとポートにアクティブに接続します。4 G DTUとパブリックIPを持たないほとんどのフィールドデバイスは、このモデルを取ります。サーバー側には固定パブリックIPとオープンポートが必要です。

UDPモードUDPモード：シリアルポートサーバは、シリアルポートデータをUDPデータグラムとしてカプセル化し、指定されたリモートIPとポートに送信し、リモートからUDPデータグラムを受信します。UDPには接続管理のオーバーヘッドはありませんが、パケット損失の場合の再送信メカニズムはありません。同じLAN 内での非クリティカルなデータ転送に適しています。

2.2物理的仕様

シリアルサーバのハードウェアの違いは、主にシリアル数と物理インタフェースの種類にあります。

• シングルシリアルポートタイプ：1ウェイRS-485または1ウェイRS-232、単一のデバイスネットワークに適しています。
• マルチシリアルポートタイプ2、4、8、さらには16 RS-232/RS-485/RS-422ハイブリッドアクセス、各シリアルポートは独立して動作し、互いに影響を与えません。
• WiFiタイプ。：シリアルポートからWiFiへ、AP（デバイス自作ホットスポット）、STA（既存のWiFiに接続）、AP+STA 混合モードをサポートします。
• 広い圧力/作業規則DC 9-48V広い電圧、-35 ° C ~ 75°C動作温度、IP30 以上の保護レベルをサポートしています。

選択時の重要な指標：透過性の遅延。安価なシリアルサーバは内部にソフトウェアバッファの層を使用しており、エンドツーエンドのレイテンシは100-200msに達する可能性がある。Modbusマスターの応答タイムアウトの場合、200msの追加レイテンシは、少なくとも200msのポーリングウィンドウを失うことを意味します。工業用グレードのシリアルサーバーのエンドツーエンドのレイテンシは、10-50msの範囲でなければなりません。

2.3シリアルサーバの境界

サーバーができないこと：

• Modbus RTUフレームがどこで始まり、どこで終わるかわからない（3.5文字間隔を判断しない）。
• スレーブアドレスを認識せず、アドレスごとに異なるTCPクライアントにデータを配信できない
• CRC/LRCチェックを検証しない-間違ったフレームも転送されます。
• Modbusクエリをアクティブに開始できません
• ポーリングはできません。サーバはすべてのスレーブの読み書きタイミングを管理する必要があります。

Modbusゲートウェイ：プロトコル認識のハブ

3.1動作の原理

Modbusゲートウェイは、シリアルサーバに基づいてプロトコルエンジンの層を追加します。Modbus RTU/ASCI I/TCPメッセージの構造（アドレスコード、ファンクションコード、レジスタアドレス、データエリア、CRC/LRC）を認識し、インテリジェントな意思決定を行います。

典型的な機能モデル：

モード1：透過的変換（スレーブ/スレーブモード）

これはゲートウェイの最も基本的なモードであり、シリアルサーバと同様に動作しますが、もう1つのステップがあります。Modbus RTU/ASCIIフレームはCRC/LRCチェックとMBAPヘッダを取り除き、Modbus TCPフレームに変換してサーバに送信します。サーバ側では、ゲートウェイはModbus TCPサーバのように振る舞います。次に、サーバはModbus TCP要求を送信し、ゲートウェイはMBAPヘッダを削除し、CRCを計算して追加し、RTU/ASCIIフレームに変換してシリアルスレーブに送信します。

SCADA/ホストコンピュータ（TCPクライアント）
    Modbus TCP要求
    ▼ ▼ ▼
Modbusゲートウェイ（TCPサーバ→ RTUマスター転送）
    Modbus RTUリクエストとCRC
    ▼ ▼ ▼
RS-485バス→駅01、02、03...。

モード2：アクティブポーリング+キャッシュ（ホストモード/ Masterモード）

これは、Modbusゲートウェイがシリアルサーバと区別するコア機能です。ゲートウェイはModbus RTUマスターとして機能し、内蔵のポーリングテーブルに従ってシリアルポート上のスレーブ機器を定期的にクエリし、返されたデータをローカルキャッシュに格納します。ネットワーク側のサーバは、ポーリングを自分で管理する必要はなく、ゲートウェイのキャッシュに直接最新のデータを読み込むだけです。

利点：

• 複数のホスト/クラウドプラットフォームは、RS-485バスをプリエンプトすることなく、同じバッチのレジスタを同時に読み取ることができます。
• ポーリング頻度は制御可能で、ゲートウェイは3.5文字のフレーム間隔、タイムアウト再試行、CRCチェックを管理する。
• ネットワーク側の再試行はシリアル側の通信を妨げない-サーバがタイムアウトして再試行すると、ゲートウェイはキャッシュから直接データを返します。

モード3：プロアクティブなエスカレーション（Publishモード）

ゲートウェイは、あらかじめ設定されたルール（タイミング、データ変更、しきい値トリガー）に従って、レジスタデータを積極的にサーバにプッシュします。このモードでは、サーバーはポーリングを必要としません。これは、ゲートウェイがMQTTクライアントとして機能し、ブローカーの指定されたトピックにデータをアクティブにPUBLISHするMQTTアクセスシナリオで特に便利です。

3.2キャッシュストアメカニズム

Modbusゲートウェイのキャッシュは、メモリ内のレジスタマップテーブルを維持することである。設定時に、管理者は一連の“収集ポイント”を定義します。

収集ポイント1：スレーブアドレス01、機能コード03、開始アドレス0000、長さ4、サイクル1秒
収集ポイント2：スレーブアドレス0 2、機能コード0 4、開始アドレス0000、長さ2、周期5秒
...

ゲートウェイはこれらの収集ポイントをそれぞれの周期でポーリングし、データを内部キャッシュにフラッシュします。複数のTCPクライアントが同時に読み取る場合、ゲートウェイはシリアルポート通信をトリガせずにキャッシュデータを直接返します。取得サイクルが短いほど、データはリアルタイムになりますが、RS-485バス負荷は高くなります。リアルタイム性とバス容量のバランスが必要です。

3.3プロトコル変換能力

典型的なModbusゲートウェイがサポートするプロトコル変換パス：

Modbus RTU → Modbus TCP
Modbus ASCII → Modbus TCP
ModバスRTU   Modbus RTU（クロスネットワークルーティング）
Modbus TCP   ←→ MQTT（一部の高度なゲートウェイ）

注：あるModbusモードから別のModbusモードへの移行のみが“標準Modbusゲートウェイ”の範囲内にあります。ゲートウェイがModbus ⇔ MQTT / HTTP / OPC UA / Profinetのような非 Modbusプロトコルを変換できるようになると、実際には“プロトコルコンバータ”または“エッジコンピューティングゲートウェイ”の領域に入ります。

エッジコンピューティングゲートウェイ：IoTのための完全なプラットフォーム

4.1合意を超えて

エッジコンピューティングゲートウェイは、シリアルサーバとModbusゲートウェイの“完全な進化”です。プロトコル変換を完了するだけでなく、ローカルデータ処理と意思決定機能も提供します。コア能力は以下の通り。

• 複数の同時アクセスRS-485バス上にModbus RTU機器とDL/T645メーターの両方があり、ゲートウェイは両方のプロトコルを同時に解析し、MQTT/HTTPアップロードに統一的に変換します。
• ローカルルールエンジンIF 温度80°C THENローカルリレー切断+プラットフォームアラーム、クラウドの意思決定に依存しない
• データの前処理平均フィルタリング、変化率計算、単位変換（例：元の値×0.1 =実際の温度）、ゲートウェイ側で行う。
• ネットワークの再開。4 G/WiFiネットワークが切断された場合、データはローカルフラッシュ/SDカードにキャッシュされます。ネットワーク復元後に自動的に転送されます。
• エッジストレージローカルSQLite / TSDB、7-30日間の履歴データクエリをサポート

4.2 Modbusゲートウェイとの違い

多くの人は、“自分のゲートウェイはエッジコンピューティングゲートウェイでもMQTTアップロードをサポートしている”と考えています。実際、MQTTトランスポートのサポートはエッジコンピューティングではありません。本質はトランスポートですが、プロトコルカプセル化が変更されます。

真のエッジコンピューティングゲートウェイが必要です。データ·モデルの変換：Modbusレジスタの列（01 03 04 00 10 00 20 00 30構造化されたJSONデータの解析（{"temperature": 16.0, "humidity": 32.0, "pressure": 48.0}クラウドプラットフォームに移行します。このプロセスには、レジスタアドレスから物理量へのマッピング、単位変換、データ型変換、データ妥当性チェックが含まれ、単に“ModbusフレームをMQTTメッセージに詰め込む”だけではありません。

五、操作モードの工程

エンジニアリング導入の観点からは、3つのデバイスはネットワーク内で異なるトポロジーの役割を果たします。

選択の選択：どのタイミングを使用するか

6.1 Serial Serverのシーン

• バス上にはModbusデバイスが1-2 台しかなく、ポーリングロジックはシンプルで、サーバー側には成熟したModbusドライバがあります。
• Modbusプロトコル（カスタムバイナリプロトコル、メーカーのプライベートプロトコル）ではなく、プロトコル解析は必要ありません。
• 純粋なローカルエリアネットワーク内で使用し、ネットワーク遅延が安定し、サーバー処理能力が十分です。
• 予算は厳しく、数百ドルで済む。

6.2 Modbus Gatewayの使用状況

• 4台以上のModbus RTUデバイスが1つのIPアクセスが必要
• 複数のホストPC/エンジニアリングPCが同じバッチのデバイスに同時にアクセスする必要がある
• サーバー側のポーリング圧力を低減し、Modbusクエリをフィールド側に沈める必要がある
• リモートアクセス（4 G/クロスネットワークセグメント）、高いネットワークレイテンシ、タイムアウト再試行はパブリックネットワークを横断しないでください。
• プロアクティブなエスカレーションモード（スケジュールプッシュまたは変更トリガープッシュ）が必要

主な判断基準サーバーがRS-485スレーブを管理するためにタイムポーリングプログラムを展開する必要があり、ゲートウェイが実行できる場合は、Modbusゲートウェイを使用してください。

6.3エッジコンピューティングゲートウェイのシナリオ

• 複数のプロトコル（Modbus + DL/T645 + M-Bus +カスタムプロトコル）へのフィールドアクセス、標準IoTプロトコルへの統一的な変換が必要
• ローカルでリアルタイムの意思決定が必要（温度が高すぎてデバイスを即座に切断し、サーバの500msポーリングサイクルを待つことができない）
• オンサイトネットワークが不安定（4 G信号不良、WiFi周波数切断）、ネットワークキャッシュとデータ継続の必要性
• データは前処理（ノイズ除去、補正、フォーマット変換）が必要です。
• エッジ側のアラームプッシュとローカルヒューマンコンピュータインタラクション（HMIスクリーン/インジケータリンク）が必要です。

一言でまとめる。：

• ただ、シリアルサーバーに転送。
• Modbusデバイスの管理→ Modbusゲートウェイ
• ローカルスマートノードの構築→エッジコンピューティングゲートウェイ

七、典型的な工学案の例

オプション1：小規模農業温室（4センサ+ 1 PLC）

設置場所：温度センサ（RS-485 Modbus RTU）4 台+PLC 1 台
通信：LAN WiFi、50 m先の当直室にサーバー
機器：シリアルサーバー（USR-W610などのWiFiモデル）
アーキテクチャ：センサー → RS-485バス→シリアルサーバー → WiFi → LAN →サーバー（Modbus TCPマスタードライバを実行）
理由：デバイスが少なく、LAN遅延が少なく、予算が少ない

オプション2：ポンプステーションの遠隔監視（8つのインバータ+メーター）

フィールド：8 台のインバータ（RS-485 Modbus RTU）+ 3 台の電力計
通信：4 G、クラウド上のサーバー
デバイス：Modbusゲートウェイ（USR-G 780などの4 Gモデル）
アーキテクチャ：インバータ+メーター → RS-485バス→ Modbusゲートウェイ（ホストモード、1sポーリングキャッシュ）
       → 4 G →クラウドサーバー（MQTT Broker、サブスクライブゲートウェイキャッシュデータ）
Polling Table：
  収集点1ステーション01、03ヤード、アドレス0x1000、長さ8、サイクル1s周波数コンバータ動作パラメータ
  収集点2ステーション02、03ヤード、アドレス0x2000、長さ4、サイクル1sメーター電圧電流
  収集点3：ステーション01、03コード、アドレス0x1100、長さ4、周期10s周波数コンバータ警告記録
理由：複数のデバイス、高いリモート4 Gレイテンシ、異なるポーリングサイクルを必要とする複数のデータ収集ポイント、クラウドはキャッシュを購読するだけです。

シナリオ3：工場のエネルギー消費モニタリング（50台以上のメーター +ローカルディスプレイ）

現場：50台以上の三相電気メーター（Modbus RTU）+ 4ウェイ水道メーター（M-Bus）
通信：社内イントラネット、データはローカルSCADAとクラウドに同時にプッシュする必要があります
デバイス：エッジコンピューティングゲートウェイ（例：Huawei AR650シリーズ）
構造：より
  RS-48 5バス1（Modbus RTUポーリング）
  水道メーター → M-Bus to RS-485モジュール→ RS-485バス2 →エッジコンピューティングゲートウェイ
  ローカルSCADA（Modbus TCPスレーブ）
  →クラウドプラットフォーム（MQTT JSON、電力消費量、需要量などの前処理データ）
  ローカルSQLite（30日の履歴）
ルールエンジン：
  IFループ電力定格値× 1.2、5分間→ローカル音と光アラーム+ MQTTアラームプッシュ
理由：マルチプロトコル、大規模なデータ処理、ローカル履歴ストレージ、リンケージアラーム

インターネット上の多くの資料では、シリアルサーバとModbusゲートウェイを同位または混同しています。本質的に、選択のコアは、デバイスの名前を見ることではなく、それを見ることです。プロトコル処理深度の位置プロトコル処理がデバイス側で行われるか、サーバ側で行われるか。処理を現場に近づけば近づけるほど、サーバーが容易になり、システムのスケーラビリティが向上します。しかし、デバイス数が少なく、ネットワーク条件が良好な単純なシナリオでは、シリアルポートサーバのシンプルさが利点です。プロトコル解析のための追加の遅延がなく、キャッシュ一貫性の管理負担もありません。高価ではなく、より良い症状です。

再び話す問題がある。