html シリアルサーバーのTCPモード:待ち受け側の役割とメッセージのフレーミング | FCTELE
                                   +8618758069661 [email protected]
製品検索 検索ガイド: スペース = AND(かつ)、 | = OR(または)、 ! = NOT(除外)

ご質問はありますか? 今すぐお電話ください!

+8618758069661

またはメッセージをお送りください

オンラインお問い合わせ

シリアルサーバー TCP サーバーの使用方法:接続、バイトストリーム、シリアルパラメーター

閲覧数: 102 +3FCTELEによるオリジナル記事著者:FCTELE技術チーム
概要

シリアルサーバーのTCP Serverモードでは、実際に何が変わるのでしょうか?

設定されたネットワークサービスがクライアントからの接続を待ち受けるようになります。すべてのシリアルコマンドがHTTPリクエストやModbus TCPメッセージになるわけではありません。接続後は、バイトデータを双方向に送受信できます。シリアルの電気的条件と文字形式の設定を合わせ、TCPストリームからアプリケーションフレームを組み立て、実行状況が不明なコマンドやバッファ内のデータを再接続時にソフトウェアがどう扱うかを定義してください。

3つの仕組みと検証の適用範囲信号の流れを追い、実際のサービスを検証する

01セッションを確立する

Establish the sessionThe client connects to the configured listening address and port.CallerListenerConnectConfigure payload direction separately

クライアントが、設定された待ち受けアドレスとポートに接続します。

02アプリケーションメッセージを再構成する

Reassemble application messagesRead calls divide an ordered stream into variable chunks.ABCDEFABCDEFSame ordered bytesRead boundaries are not command boundaries

読み取り呼び出しでは、順序のあるストリームが可変長の断片に分割されます。

03再接続時の動作を定義する

Define reconnect behaviorSession return can precede valid application state.FaultLinkServiceDefine each measured event and intervalValid data

セッションが復旧しても、アプリケーションの状態がまだ正常でない場合があります。

スワイプして3つの図を比較 →

概念を説明するための図であり、実測波形、設置配線図、特定製品の内部構成を示すものではありません。
  • セッションを確立する

    どちらの方向のペイロードを追跡する場合も、まず接続を開始する側を確認してください。

  • アプリケーションメッセージを再構成する

    アプリケーションフレームの規則を満たすまで、データをバッファに蓄積してください。

  • 再接続時の動作を定義する

    再試行するかどうかを判断する前に、コマンドの実行状況を確認してください。

選定・検証チェックリスト確認項目と関連ガイドを展開する
対象サービスと実際の運用条件に関する確認事項
確認項目確認する内容検証方法
セッションを確立するクライアントが、設定された待ち受けアドレスとポートに接続します。どちらの方向のペイロードを追跡する場合も、まず接続を開始する側を確認してください。
アプリケーションメッセージを再構成する読み取り呼び出しでは、順序のあるストリームが可変長の断片に分割されます。アプリケーションフレームの規則を満たすまで、データをバッファに蓄積してください。
再接続時の動作を定義するセッションが復旧しても、アプリケーションの状態がまだ正常でない場合があります。再試行するかどうかを判断する前に、コマンドの実行状況を確認してください。

TCPサーバーモードでは、シリアルサーバーがネットワークポートで待ち受け、コンピューターやプログラムから能動的に接続されるのを待ちます。接続が確立すると、双方がシリアルのバイトデータを送信します。計測器のプロトコルを自動的に理解するモードではなく、シリアル機器をそのままWebサーバーに変えるものでもありません。以下では、まず機器内でのデータの流れを説明し、次に一貫した設定例とトラブルシューティングの順序を示します。

サーバーとクライアントは、どちらが接続を開始するかを表す

サーバーは指定されたアドレスとポートで待ち受け、クライアントは接続要求を開始します。接続確立後は通常、双方向にデータを送信できるため、「サーバー」は受信専用、「クライアント」は送信専用という意味ではありません。ネットワークポートとは、プログラムが通信の入口として選ぶ番号であり、機器の背面にあるネットワークケーブルを差し込む物理的な差込口ではありません。コンピューターは、到達可能なサーバーのIPと待ち受けポートを把握する必要があり、シリアルサーバー側では接続を受け入れる必要があります。接続がない場合に、シリアル機器から送られたデータをバッファに保存するか破棄するかは、機種と設定によって異なり、必ず保存されるとは限りません。まず役割を理解してから動作モードを設定すれば、両方の機器が待ち続けたり、両方が誤った接続先に接続を開始したりする事態を防げます。

1バイトは実際にどの段階を通るのか?

コンピューターが計測器に問い合わせる場合を例にします。ソフトウェアはプロトコルの要求をTCPに渡します。ネットワークインターフェースが受信すると、サーバーはネットワークデータからバイト列を取り出し、UARTシリアルコントローラーに渡します。UARTは、ボーレート、データビット、パリティビット、ストップビットに従ってバイト列を連続した電気信号に変換し、対応するRS232またはRS485回路が計測器に送信します。計測器からの応答は、逆方向に戻ります。ボーレートはシリアルシンボルの伝送速度を表すもので、ネットワーク速度がどれほど高くても、それだけで低速の計測器を高速化することはできません。透過伝送機器は通常、アドレス、ファンクションコード、測定値を解釈せず、その処理はアプリケーションが行います。RS485インターフェースを備えていることと、Modbusプロトコル変換機能を内蔵していることは同じではありません。この2つの機能は個別に確認する必要があります。

最初にコンピューターがTCP接続を開始します。接続が確立すると、ネットワークインターフェース、UART、シリアル回路を通じて双方向にデータを伝送できます。
最初にコンピューターがTCP接続を開始します。接続が確立すると、ネットワークインターフェース、UART、シリアル回路を通じて双方向にデータを伝送できます。

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。 中国語の原文を読む

実務上のよくある質問

TCP Serverモードでは、シリアル機器は受信しかできないのでしょうか?

いいえ。接続の開始とペイロードの方向は別のものです。セッションが確立すると、対応する透過データ経路で要求と応答を双方向に伝送できます。

シリアルデータのパッキング間隔を変更すれば、TCPの各読み取りで完全な応答を1件ずつ受信できますか?

いいえ。パッキングが影響するのは送信タイミングであり、恒久的なTCPメッセージ境界ではありません。受信側では引き続き、プロトコルの長さ、区切り文字、その他の文書化されたフレーミング規則が必要であり、分割された読み取りや複数メッセージが結合された読み取りに対応しなければなりません。

再接続する制御プログラムは、ソケットが正常に開けたこと以外に何を確認する必要がありますか?

以前のコマンドが実行されたか、バッファ内にバイトデータが残っているか、アプリケーションがどのように再同期するかを確認する必要があります。新しい接続が確立しても、非冪等なコマンドを安全に繰り返せるようになるわけではありません。

出典と適用範囲

これらの補足は一般的な仕組みを説明するものです。対応機能、接続の詳細、受入判定基準は、実際の機器、ソフトウェア、運用条件に合わせて検証する必要があります。図は測定結果や認証の証拠ではありません。

この記事を共有する