TCPサーバーモードでは、シリアルサーバーがネットワークポートで待ち受け、コンピューターやプログラムから能動的に接続されるのを待ちます。接続が確立すると、双方がシリアルのバイトデータを送信します。計測器のプロトコルを自動的に理解するモードではなく、シリアル機器をそのままWebサーバーに変えるものでもありません。以下では、まず機器内でのデータの流れを説明し、次に一貫した設定例とトラブルシューティングの順序を示します。
サーバーとクライアントは、どちらが接続を開始するかを表す
サーバーは指定されたアドレスとポートで待ち受け、クライアントは接続要求を開始します。接続確立後は通常、双方向にデータを送信できるため、「サーバー」は受信専用、「クライアント」は送信専用という意味ではありません。ネットワークポートとは、プログラムが通信の入口として選ぶ番号であり、機器の背面にあるネットワークケーブルを差し込む物理的な差込口ではありません。コンピューターは、到達可能なサーバーのIPと待ち受けポートを把握する必要があり、シリアルサーバー側では接続を受け入れる必要があります。接続がない場合に、シリアル機器から送られたデータをバッファに保存するか破棄するかは、機種と設定によって異なり、必ず保存されるとは限りません。まず役割を理解してから動作モードを設定すれば、両方の機器が待ち続けたり、両方が誤った接続先に接続を開始したりする事態を防げます。
1バイトは実際にどの段階を通るのか?
コンピューターが計測器に問い合わせる場合を例にします。ソフトウェアはプロトコルの要求をTCPに渡します。ネットワークインターフェースが受信すると、サーバーはネットワークデータからバイト列を取り出し、UARTシリアルコントローラーに渡します。UARTは、ボーレート、データビット、パリティビット、ストップビットに従ってバイト列を連続した電気信号に変換し、対応するRS232またはRS485回路が計測器に送信します。計測器からの応答は、逆方向に戻ります。ボーレートはシリアルシンボルの伝送速度を表すもので、ネットワーク速度がどれほど高くても、それだけで低速の計測器を高速化することはできません。透過伝送機器は通常、アドレス、ファンクションコード、測定値を解釈せず、その処理はアプリケーションが行います。RS485インターフェースを備えていることと、Modbusプロトコル変換機能を内蔵していることは同じではありません。この2つの機能は個別に確認する必要があります。

1回の受信が1件のメッセージの受信とは限らないのはなぜか?
TCPは順序のあるバイトストリームを提供しますが、アプリケーションの各送信単位の境界は保持しません。プログラムが6バイトを送信した場合、受信側のプログラムは最初に2バイト、次に4バイトを読み取ることも、別の組み合わせに分割して読み取ることもあります。同じ接続で正常に配送される限り、バイトの順序は正しく保たれるはずです。これは封筒が1通ずつ届くのではなく、水が連続して流れるようなものです。ただし、水流のたとえでは再送や輻輳の仕組みまでは説明できません。アプリケーションは、自身のプロトコルの長さ、区切り文字、検査規則に従ってバッファリングとフレーミングを行う必要があり、1回の読み取りを1件の要求や応答として扱うことはできません。機器のシリアルパッキング時間はデータの送信タイミングに影響しますが、TCPに恒久的なメッセージ境界を追加することはできません。
まずネットワークを設定し、ポートの例を統一する
サーバーのアドレスを192.168.0.148、コンピューターを192.168.0.166とし、相互通信が可能な同一のサンプルサブネット内にあるものとします。待ち受けポートは4096に統一します。例示したアドレスとポートは現場の設計に合わせて置き換える必要があり、既存機器のアドレスをそのまま使用してはいけません。マスクとゲートウェイを設定する際は、サブネットをまたぐアクセスが必要か確認してください。同一サブネット内でも、VLANやファイアウォールによって機器間が分離されている場合があります。サーバー側で4096を設定したら、クライアントも4096に接続する必要があります。ある手順では4096、別の手順では40080と指定してはいけません。設定を保存し、再起動後も保持されているか確認してください。具体的なメニュー名はファームウェアによって異なります。本記事では、すべての機種が同じWebインターフェースを備えているとは想定していません。

シリアルパラメーターと電気配線は同じように重要
この例では、9600ボー、データ8ビット、パリティなし、ストップ1ビットを使用できますが、計測器が別の組み合わせを要求する場合は、計測器のマニュアルに従う必要があります。バイト形式が一致しないと、文字化け、検査エラー、無応答が発生します。RS232は一般に送信、受信、基準グランドを使用し、RS485は差動線を使用します。両者は単なるアダプターだけで直接混用することはできません。RS485の端子名称はメーカーによって異なる場合があるため、AとBという文字だけで推測せず、定義を確認してください。電源、絶縁、接地の要件も確認し、フィールドバスを扱う場合は保守作業が可能な条件下で作業してください。ソフトウェアに「接続成功」と表示されても、TCPチャネルが確立したことしか証明できず、シリアルの電圧、パラメーター、計測器のプロトコルが正しいことは証明できません。
安全で結果を説明できるループバックテストを行う
まず独立したテスト環境で、正常動作が確認済みのシリアル機器またはシリアルデバッグ端末を使用し、サーバーに接続してパラメーターを一致させます。クライアントから既知のバイト列を送信し、シリアル側で内容と順序を確認します。次に、シリアル側から別のバイト列を送り返し、クライアントで応答を確認します。16進数表示を使用する場合は、「0」や「1」という文字列ではなく、バイト値が送信されていることを確認してください。実際の計測器に接続する前に、そのマニュアルに記載された読み取り専用の問い合わせで検証し、アクチュエーターに不明なコマンドを送らないようにしてください。RS232のループバックとRS485のテストでは方法が異なります。バス端子をむやみに短絡させないでください。ループバックテストではネットワーク側とシリアル側を切り分けられますが、実際のプロトコルおよび負荷条件での受け入れ試験の代わりにはなりません。
旧来のソフトウェアのCOMポートをTCPサーバーに接続するには?
元の2301の文章では、仮想COMを利用して旧来のプログラムがシリアルインターフェースを引き続き使用できるようにする方法が提案されていました。この考え方は有用ですが、すべてのソフトウェアに対する100%互換性を意味するものではありません。仮想COMは、コンピューターのドライバーによってローカルポートとして作成され、シリアルサーバーのIPとサービスの待ち受けポートにマッピングされます。プログラムがCOMを開くと、ドライバーが対応するネットワーク接続を処理します。ソケットを直接使用できるプログラムは、プロトコルに従ってサーバーに接続できるため、仮想COMの層を追加する必要はありません。いずれの方法でも、ポートの占有、パラメーター、制御線、切断からの復旧、応答時間を確認する必要があります。COM番号が表示されたというだけで成功と判断してはいけません。
別の方法として、計測器を1台のコンピューターの実シリアルポートに接続したまま、そのコンピューターでシリアル共有サービスを実行し、ほかのコンピューターからアクセスできるようにする方法があります。これは物理的なシリアルポートを遠隔地に移すものではありません。共有ホストの電源を入れたままにし、サービスが稼働し、権限が正しく設定されている必要があります。専用のシリアルサーバーは、そのコンピューターへの依存を減らせますが、こちらにも電源、ファームウェア、ネットワークに関する条件があります。ネットワークによって設置可能な範囲は広がりますが、シリアルケーブルの長さが無制限になるわけでも、すべての制御タイミングが完全に維持されるわけでもありません。複数のクライアントで共有できるか、また調停がどのように行われるかは、機種とアプリケーションに応じて確認する必要があります。
複数クライアント、タイムアウト、再接続には明確な規則が必要
機種によっては複数のTCPクライアントを接続できますが、シリアル応答がブロードキャストされるか、書き込みに制限があるか、調停がどのように行われるかをすべて確認する必要があります。複数のコンピューターが同じRS485計測器を同時に制御すると、要求が混在したり、応答が誤ったセッションに届いたりする場合があります。接続数を制御能力とみなすのではなく、1つのホストアプリケーションでアクセスを調整するのが望ましい方法です。ネットワーク切断後は通常、クライアントが切断を検出し、再接続して、アプリケーションの状態を復元する必要があります。以前に発行した制御コマンドが実行されたかどうかは、接続の復旧だけでは判断できません。タイムアウトと再試行を設計する際は、特に非冪等なコマンドの重複実行を避けてください。冪等とは、繰り返し実行しても結果に追加の変化が生じない性質を指します。
動作しない場合は、どの層を確認すべきか?
クライアントが接続できない場合は、まずアドレス、ポート、待ち受けモード、アクセスポリシー、別の接続による占有の有無を確認します。接続には成功しているのにシリアルデータがない場合は、配線、形式、計測器のアドレス、プロトコルの要求を確認します。データは見えるものの解析できない場合は、バイト値、パケットのバッファリング、チェックサムを確認してください。すぐにボーレートを変更して、偶然の改善を期待してはいけません。稼働中の設備の待ち受けポートを公衆ネットワークに直接公開しないでください。システム設計に従い、アクセス制御と安全な通信路を使用してください。TCP自体が暗号化を意味するわけではありません。受け入れ試験では、双方向伝送、切断後の再接続、長時間運転、実際の業務での動作を確認します。接続、バイト転送、プロトコルの理解を分けることで、初心者も各段階で実際に何を検証しているのかを明確に把握できます。
原理の確認資料:公式資料 1;公式資料 2。本記事で説明する一般的な仕組みと例は、該当機種のマニュアルに代わるものではありません。
中国語の技術記事からの翻訳です。原文の初回公開日:2022-11-29。原文の最終改訂日時:2026-10-13T19:15:07+08:00。 中国語の原文を読む


