シリアルサーバーのネットワークモードを選択する際は、まずどちらが接続を開始するか、次にアプリケーションが順序付きバイトストリームと独立したデータグラムのどちらを必要とするかを確認し、その後でパケット化の待ち時間と長さを調整します。TCP Server、TCP Client、UDP、プロトコル変換は、同じ判断階層にあるものではありません。メニュー項目が並んでいるからといって、違いが速度だけというわけではありません。
1．モード選択はソフトウェアの役割から始める
シリアルサーバーはネットワークとシリアルポートの間でバイトを転送し、アプリケーションデータの解釈はホストアプリケーションが担います。コンピュータープログラムが現場機器へ能動的に接続する場合、現場側は通常TCP Serverに設定します。中央のプログラムが現場機器からの接続を待つ場合、現場側は通常TCP Clientに設定します。両側が待機していると、ネットワークが到達可能であっても、接続が自動的に確立されることはありません。
接続上の役割はデータの方向を制限しません。TCP接続が確立された後は、通常、両端でバイトを送受信できます。したがって、サーバー側は受信専用でも、クライアント側は送信専用でもありません。例示されたポートは両端で整合させる必要があります。管理用Webページのポートと計測器アプリケーションのポートは用途が異なるため、Webページが開くだけでアプリケーションが正常だと判断することはできません。
2．TCPのサーバーとクライアントの違いは？
サーバーは指定されたアドレスとポートで待ち受け、クライアントは能動的に接続を要求します。クライアントが接続を開始し、サーバーが受け入れて初めて、アプリケーションはその接続を通じてデータを伝送できます。クライアントの設定では、宛先アドレスと宛先ポートも入力する必要があります。サーバーの設定では、待ち受け範囲、アプリケーション用ポート、許可する接続元を確認します。
機器が接続を開始するタイミング、長時間接続を維持するかどうか、切断後どのくらいで再試行するかは、ファームウェアと設定によって決まる動作です。電源投入時に接続する機器もあれば、シリアルデータによる接続開始に対応する機器もあります。1つのメニューの動作をすべての機種に当てはめることはできません。モード名は基本的な役割を表すものであり、登録パケット、暗号化、切断時のバッファリングが必ず備わっていることを証明するものではありません。
3．UDPを単に高速なTCPと捉えられない理由
UDPはデータグラムを送信し、TCPのような接続を確立せず、それ自体では順序どおりの到着、信頼性のある配信、重複防止を保証しません。データグラムの境界は保持しますが、シリアルサーバーがパケット化条件に従ってデータグラムを形成する場合があるため、その境界がシリアルプロトコルのメッセージ境界と一致するとは限りません。
アプリケーションでUDPを使用する場合は、パケット損失、順序の入れ替わり、重複、受信バッファ不足を考慮し、用途に応じてシーケンス番号、確認応答、その他の復旧規則を定義する必要があります。読み取り専用の周期的サンプリングと制御コマンドではリスクが異なります。UDPにハンドシェイクがないという理由だけで、起動・停止コマンドの実行状態の確認を省略することはできません。
メニューのUDP ServerとUDP Clientは、待ち受け、宛先アドレス、応答方式を表すために使われることが多く、TCPの接続上の役割に完全に対応するものではありません。固定の宛先へ返信する機器も、送信元に応じて返信する機器もあります。複数の送信元から受信できるか、応答をどのように振り分けるかは、いずれもマニュアルで確認してください。ブロードキャストアドレスとポートには業界共通のデフォルト値はなく、旧記事に記載された数値を他の製品にそのまま使用すべきではありません。
4．シリアルデータのパケット化で待ち時間が生じる理由
シリアルのバイトは順次到着するため、機器はどの時点でそれらをネットワークへ渡して送信するかを判断する必要があります。一般的な条件には、蓄積バイト数、時間間隔、区切り文字があります。長さの条件に達すると送信が開始される場合もあれば、指定された時間間隔まで待って送信が開始される場合もあります。条件の組み合わせ方や値がゼロの場合の意味は、メーカーによって異なります。
短い応答が数バイトしかないのに、パケット化の長さが非常に大きく設定されていると、機器は時間間隔の条件を満たすまで待ち続ける可能性があります。ホストコンピューターのタイムアウトが短すぎると、まだバッファ内にある応答を失敗と判断してしまいます。逆に、パケット化の頻度が高すぎると、小さなデータブロックが多数発生し、処理のオーバーヘッドが増加します。応答長、シリアル通信速度、アプリケーションの周期に基づいてテストしてください。
TCPが正常に配信される場合、順序付きバイトストリームが提供され、プログラムの1回の読み取りで半分のフレームや複数のフレームを取得することがあります。パケット化パラメーターの調整は、アプリケーションのフレーミングの代わりにはなりません。アプリケーションは引き続き、長さ、区切り文字、チェックサム、プロトコルの状態に基づいてメッセージ全体を判定してから内容を解釈する必要があります。各読み取りをそのまま1つの応答として扱うと、散発的なエラーが生じやすくなります。
5．キープアライブ、アイドルタイムアウト、アプリケーションタイムアウトは区別する
キープアライブは接続がまだ有効である可能性を検出するために使用し、アイドルタイムアウトは設定に従い長時間通信のないセッションを終了するために使用します。アプリケーションタイムアウトは、アプリケーションが機器の応答を待つ期限です。この3つはそれぞれ異なる問題に対処するものであり、キープアライブの時間だけから計測器の応答にかかるべき時間を推測することはできません。
キープアライブパケットとプローブ回数はシステムと機器の実装によって決まるため、「3回応答がなければ切断」を統一規格としてそのまま適用すべきではありません。また、接続が復旧したからといって、直前の制御コマンドが実行されなかったことにはなりません。タイムアウト後に再試行する前に、そのコマンドを安全に繰り返せるかを検討し、必要に応じて先に状態を照会するか、プロトコルが対応するトランザクション機構を使用してください。
6．複数接続とModbus変換は同じ機能ではない
複数のTCPセッションを許可することは、ネットワークアクセス能力を示すだけです。複数のマスターが同じRS485バスへ同時に書き込むと、要求が競合し、応答の対応付けを誤る可能性があります。機器が調停、キューイング、読み取り専用アクセス、明示的なゲートウェイモードを備えているか確認し、システム全体で調整する必要があります。
Modbus RTUからTCPへの変換では、2種類のメッセージ構造とトランザクションの対応関係を正しく処理する必要があり、RTUのバイトを単にTCPへ送るだけでは完了しません。TCPモードに「Modbus」という選択肢が表示されることも、すべての機器が対応する証拠にはなりません。具体的な機種の根拠を欠く旧記事の最大セッション数、接続の横取り規則、メニューの範囲は、ここでは一般仕様として引き継いでいません。
7．現場設定と受入検証を順序立てて完了する
まずホストコンピューターの役割、端末インターフェース、シリアル通信形式を記録し、次にネットワークアドレス、ポート、アクセス範囲を計画します。隔離されたテスト環境で、動作が確認されている端末を1台使用してアプリケーションの双方向通信を一通り行い、接続状態、シリアル通信のカウント値、生の応答を観察します。その後、一度に1項目だけ変更しながらパケット化パラメーターを調整し、元に戻せる設定を保存します。
現場に再接続した後は、連続ポーリング、同時負荷、切断からの復旧をテストし、タイムアウト、応答内容、重複コマンドを確認します。TCPは暗号化と同義ではありません。リモートアクセスには計画的に設けた安全な通信経路とアクセス制御を使用し、管理用Webページや制御ポートをインターネットに直接公開しないでください。UDPでも同様に、送信元の制限と認可を省略することはできません。
8．個別製品の確認方法
Feichang TechnologyのFCT-1500シリーズの詳細には、TCP Server/Client、UDP、仮想シリアルポート、Modbus関連のモードが記載されており、ホストソフトウェアと端末プロトコルに応じて選択・設定できます。選定時は、まず実際に注文するインターフェース、ファームウェアが対応する動作モード、変換機能を確認し、次に接続数、パケット化、再接続のパラメーターを確認してください。シリーズの紹介を、すべての構成に対する完全なマニュアルとして扱わないでください。
一般的な動作モードだけを判断する場合は1197を参照し、TCPサーバーの一貫した設定例については2271を参照してください。本記事ではUDPとパケット化の仕組みを独立して解説し、「UDPに切り替える」「時間をゼロに設定する」が万能な解決策ではない理由を理解できるようにしています。
参考資料： TCP仕様書 ; UDP仕様 ; 飛暢科技 FCT-1500シリーズの詳細 。図は一般的な仕組みを示すものであり、実測値や特定機種のメニューを表すものではありません。
旧クライアント設定記事とUDP設定記事を項目ごとに確認する方法
機器がTCP Clientとして動作する場合は、まず中央のプログラムで待ち受けを開始し、到達可能な中央側のアドレスとアプリケーションの待ち受けポートを入力してから、文字形式、チャネル、双方向の送受信を確認します。管理用Webページのアドレスをアプリケーションの接続先の代わりにすることはできません。設定を保存し、電源の再投入後と切断後の動作をテストしてください。短時間接続や複数の宛先に対応している場合は、該当機種の情報で確認し、Clientという名称から上限を推測しないでください。
UDPのテストでは、ローカルのバインドアドレスとポート、宛先アドレスとポートを別々に記録します。固定の宛先へ送信する方式と、送信元に応じて応答する方式は異なります。UDP ServerまたはClientメニューが具体的にどちらの動作を使用するかは、マニュアルによります。両端の同じパラメーター欄に矛盾するポートを入力しないでください。また、TCPのハンドシェイクを使ってUDPがオンラインであると判断しないでください。まず識別可能な少量のテストデータで双方向の経路を確認し、その後、アプリケーションが損失、重複、順序の入れ替わりにどのように対処するかを検証してください。
本記事は、対応する旧記事の有効な内容を引き継いでいます。原理図は一般的な原理の説明図であり、一般的な仕組みと個別機種の機能は分けて検証します。
中国語の技術記事から翻訳。原文初公開：2022-12-09。原文最終改訂：2026-10-13T11:01:30+08:00。 中国語の原文を読む
