シリアル–TCP 透過転送とプロトコル変換：デバイスに必要なのはどちらか？
ホストソフトウェアがデバイスの既存シリアルプロトコルを引き続き使用する場合は、シリアル–TCP 透過型ゲートウェイを選びます。ホストが Modbus RTU ではなく Modbus TCP など、別のアプリケーションプロトコルを必要とする場合は、プロトコル変換を選びます。前者はバイトを転送し、後者はメッセージを解釈して再構築します。
この判断は、ハードウェア選定より先に行います。「RS485–Ethernet」という表現はインターフェースを示すものであり、両端のソフトウェアの互換性を保証するものではありません。適切な設計には、フレーミング、バスの制御権、再試行、セキュリティの検討も必要です。
透過型シリアルゲートウェイが実際に行うこと
生データを扱う透過モードでは、ゲートウェイはシリアルのペイロードバイトを TCP 接続経由で転送し、受信した TCP ペイロードバイトをシリアルポートに書き込みます。デバイスコマンド、チェックサム、応答の解析、コマンドの意味の解釈は、引き続きアプリケーションが担当します。選択するモードを確認してください。仮想 COM モードやシリアル制御モードでは、独自のネゴシエーションが加わり、対応するホストソフトウェアが必要になる場合があります。
これは、独自のバイナリプロトコルや、対応する仮想 COM ドライバーを利用できる既存シリアルアプリケーションにとって、有用な出発点です。アプリケーションがモデム制御信号、BREAK、厳密なタイミング、ローカルのシリアルドライバーの動作に依存していないか確認してください。通常のデータバイトを転送するゲートウェイでは、これらの機能を再現できない場合があります。
例えば、計測器が仕様書に記載された長さプレフィックス付きコマンドを使用している場合、ホストはコマンドに対する応答がすべてそろうまで TCP バイトを蓄積できます。レジスタのマッピングは不要ですが、ホストには依然としてその計測器のプロトコルを解析するパーサーが必要です。
TCP 転送はシリアルメッセージの境界を保持しない
TCP は、信頼性があり順序を保持するバイトストリームを提供します。受信側は、1 回の読み取りでアプリケーションメッセージの一部だけを取得することも、複数のメッセージをまとめて取得することもあります。TCP セグメントやソケットの読み取り単位は、アプリケーションのレコード単位ではありません。これは RFC 9293 の転送モデルに基づくものです。
説明用の例：デバイスがそれぞれ 8 バイトのメッセージ A と B を送信するとします。受信アプリケーションは、最初に A の先頭 5 バイトを読み取り、次に A の残り 3 バイトと B の全 8 バイトを読み取る場合があります。この読み取り境界はあくまで一例であり、ネットワーク動作の予測ではありません。パーサーは不完全なデータをバッファーに保持し、プロトコルの長さ、区切り文字、その他のフレーミング規則に従って完全なメッセージを取り出す必要があります。
シリアル通信のタイミングは別途検討が必要です。Modbus RTU は無通信時間でフレームを区切り、文字間のタイミングにも要件があります。シリアルライン仕様の 2.5.1.1 節では、高いボーレートでのタイマー推奨値も含め、これらを定義しています。UART のスタートビット、パリティビット、ストップビットも、通常の TCP ペイロードバイトではありません。
ネットワーク上でデータが到着する間隔が、シリアルの無通信時間を再現すると考えてはいけません。ゲートウェイには適切なバッファリングとシリアル送信規則が必要です。パケット化タイムアウトの設定だけでは、シリアル出力で RTU フレームが完全な形で維持されることの証明にはなりません。分割された入力、遅延したバイト、間を置かずに続くリクエストをテストしてください。
トンネル経由の Modbus RTU は Modbus TCP とは異なる
Modbus TCP リクエストは、7 バイトの MBAP ヘッダーとプロトコルデータユニット（PDU）を使用します。Modbus RTU は、シリアルアドレス、PDU、CRC を使用します。透過トンネルでは、CRC を含むすべての RTU バイトを TCP 内で転送できますが、標準の Modbus TCP クライアントは MBAP 形式を前提とします。
変換ゲートウェイは MBAP を解析し、Unit Identifier を設定済みのシリアル宛先に対応付け、RTU リクエストを構築し、応答の CRC を検証して、返答を元の TCP トランザクションに関連付けます。MBAP の長さフィールドはメッセージ解析に使われ、トランザクション識別子はリクエストと応答の対応付けに使われます。Modbus TCP/IP 実装ガイドの 3.1.2–3.1.3 節を参照してください。
説明のために作成した具体例：シリアルデバイス 7 から、通信上のアドレス 0 を起点に 2 個の保持レジスタを読み取ります。ファンクション 03 と 0 起点の通信上のアドレス指定は、Modbus アプリケーションプロトコル仕様の 4.4 節と 6.3 節に従っています。これらのバイトはエンコードを説明するためのものであり、Obeita 製品のテスト結果や実在するデバイスのレジスタマップではありません。
- リクエスト PDU：
03 00 00 00 02。 - Modbus TCP リクエスト：
00 2A 00 00 00 06 07 03 00 00 00 02。トランザクション ID は002Aです。長さ0006は、Unit Identifier と 5 バイトの PDU を合計した値です。 - 対応する RTU リクエスト：
07 03 00 00 00 02 C4 6D。算出された CRC は下位バイトから先に送信されます。
この例では PDU は変化しません。転送フレーム形式の変換だけで、独自コマンドセットの変換、スケーリングの推定、複数レジスタにまたがるデータの並び順の解決が自動的に行われるわけではありません。これらの要件には、明示的なマッピングが必要です。
シリアルバスの制御権と再試行ポリシーを決める
Modbus のシリアルラインモデルでは、通信を開始するマスターは 1 台で、同時に扱うトランザクションは 1 件です。Ethernet クライアントを追加しても、シリアル通信の同時処理能力は増えません。複数のホストからアクセスする必要がある場合は、文書化されたスケジューラー、キューの上限、タイムアウト処理、応答の振り分けを求めてください。設計された調停の仕組みがないまま、能動的にポーリングする別のマスターを同じバスに接続しないでください。
キュー内のリクエストが期限切れになった場合、クライアントが切断した場合、シリアル応答が遅れて到着した場合に何が起きるかを確認してください。複数のソケットを受け入れる透過サーバーには、制御権に関する明確な規則が必要です。接続を受け入れられるだけでは、安全なマルチクライアント動作は保証されません。
障害シナリオ：デバイスが書き込みを実行したものの、その返答がクライアントに届く前に失われたとします。アプリケーションが再試行すると、同じ書き込みが再び実行される可能性があります。接続内での TCP 再送は、アプリケーションリクエストをもう一度発行することとは異なります。Modbus のトランザクション識別子だけでは、重複要求を永続的に抑止できる保証にはなりません。
コマンドを、その作用に応じて分類してください。設定値の代入を繰り返すことは許容できても、サイクルを開始するコマンドの繰り返しは許容できない場合があります。重大な結果を伴う書き込みでは、無条件に再試行するのではなく、デバイスが対応するシーケンス確認、状態の照合、またはオペレーターによる復旧手順を定義してください。
導入時のセキュリティ境界を定義する
通常の TCP も従来の Modbus TCP も、それ自体では暗号化と認証を備えたアプリケーションアクセスを提供しません。選定したゲートウェイとクライアントが実際に対応する機能を確認してください。Modbus Security は TLS と証明書ベースの認証を規定しています。両方のエンドポイントでの対応が必要であり、証明書の配備と更新も計画しなければなりません。
導入時のチェックリストには、ゲートウェイに到達できるシステムを許可済みのものに限定すること、制御ネットワークを分離すること、管理アクセスを保護すること、公開インターネットへの直接露出を避けることを含めてください。承認された VPN やセキュリティゲートウェイでネットワーク経路を保護できる場合でも、残るローカルセグメントとデバイスの認可は引き続き検討が必要です。暗号化だけでは、認証済みクライアントのうち誰に書き込みを許可するかは決まりません。
選定と受入試験の実践的なチェックリスト
- 両端のプロトコルを特定する。デバイスが出力する内容とホストが受け入れる内容を記録します。生のシリアルバイト、RTU-over-TCP、Modbus TCP、その他の仕様が文書化された形式などです。
- 電気的な前提条件を確認する。RS232 と RS485 の別、2 線式または 4 線式の配線、ピン配列、ボーレート、パリティ、ストップビット、接地、絶縁、終端、バイアスを、設置要件と照合します。
- フレーミングの担当を明確にする。メッセージの組み立てとシリアルタイミングへの適合を担当するコンポーネントを定めます。最大フレームサイズと、不正な形式の入力に対する動作も含めます。
- アクセスと復旧を規定する。バスの制御権、同時接続クライアントの動作、コマンド権限、タイムアウト、キュー上限、再接続処理、安全な書き込み再試行を定義します。
- 難しいケースを検証する。ベンチ環境を使い、TCP の部分読み取りと複数メッセージの一括読み取り、デバイス不在、応答の遅延、再接続、キューの飽和、アクセス拒否をテストします。合格基準はテスト前に定めます。
プロトコルの互換性がすでにあり、フレーミングを確実に処理できる場合は、透過転送を選びます。ホストが別のメッセージ形式や明示的なデータモデルを必要とする場合は、変換を選びます。どちらか一方に仕様書がない場合は、ゲートウェイのアーキテクチャを確定する前に根拠となる情報を集めてください。
Obeita との検討に向けてゲートウェイ要件を準備する
Obeita と具体的な技術検討を進めるために、機密情報を除去したデバイスのマニュアル、代表的なリクエストと応答のフレーム、シリアル設定、ホストのプロトコル、デバイス数、タイミング要件、障害時に期待する動作を準備してください。認証情報、顧客識別子、機密のプロセスデータは取り除いてください。これらの情報により、必要な転送、変換、検証作業を評価できます。
関連する統合作業については、Obeita の既存デバイス接続サービスと、納入済みのシリアル–Ethernet およびセルラー DTU 適応プロジェクト（英語）をご覧ください。デバイスとホストのプロトコルについてのご相談は、Obeita にお問い合わせください。
