複数のシリアルサーバーは、TCP Clientモードで中央サーバーの同じ待受ポートに接続できます。重要なのは、デバイスごとに個別の公開ポートを開くことではなく、中央プログラムが複数の接続を同時に管理し、各接続がどのデバイスに対応するかを識別して、プロトコルに従って正しくデータを送受信できるかどうかです。接続の成功、デバイス識別の正しさ、シリアル通信サービスの正常動作は、それぞれ個別に検証すべき3つの条件です。
1．まず、混同しやすい2つのケースを区別する
本記事で扱うのは、「現場の複数のシリアルサーバーが1つの中央プログラムに接続する」ケースです。各シリアルサーバーは、自身に接続されたシリアル機器のデータを中央側へ送り、中央側は対応する接続を通じてリクエストを送信します。例えば、独立した3つの配電盤にそれぞれ1台のシリアルサーバーがある場合、中央側は、ある測定値がどの配電盤から来たのかを把握し、正しい場所へ制御コマンドを返す必要があります。
もう1つは、「複数のコンピューターが同じシリアルサーバーにアクセスする」ケースです。これは、同じシリアル機器を複数のマスターから同時に操作できるかという問題であり、リクエストの競合や、応答がどのリクエストに対応するかの不明確化を招く可能性があります。複数のTCP接続に対応していても、安全なマルチマスター制御に自動的に対応するわけではありません。両者は、デバイスの接続方向、セッション数、スケジューリング上の課題が異なり、単に「自動ポーリングで十分」と言うだけでは対処できません。
2．1つのポートで複数のデバイスを接続できる理由
TCPポートは中央プログラムのサービスの入口と考えることができますが、1台のデバイスしか使用できない物理的な差込口ではありません。プログラムは指定したアドレスとポートで接続を待ち受けます。接続を受け入れると、オペレーティングシステムはそのセッション専用の独立した接続済みソケットを提供します。ソケットは、プログラムがネットワークデータを読み書きするためのインターフェースです。元の待受用の入口は、引き続き他のデバイスからの接続を待ちます。
ネットワークでは、1つのTCP接続は、両端のIPアドレスとポートの組み合わせで区別されます。すべてのデバイスが中央側の同じポートにアクセスしても、送信元アドレスや送信元ポートは異なる場合があります。中央側は、接続ごとに受信バッファー、状態、処理タスクを個別に保持し、異なる接続から受信したバイトを、そのまま同じ解析キューに混在させてはいけません。
中央側がポート6000で待ち受け、デバイスA、B、Cがそれぞれ能動的に接続するとします。これは独立した3つのセッションであり、3台のデバイスが同じセッションを交代で使用するわけではありません。6000は例にすぎず、推奨される固定値ではありません。実際の接続数は、中央ソフトウェア、デバイスのファームウェア、システムリソース、ネットワークポリシーによって制限されます。「1つのポート」ということから、接続可能なデバイス数が無制限だと判断することはできません。
3．接続が確立してもデバイス識別が必要な理由
接続によって、中央側は「この一連のバイトがどのセッションから届いたか」を把握できますが、「どの配電盤なのか」まで必ず分かるわけではありません。公衆ネットワーク経由のアクセスでは、ルーターがネットワークアドレスとポートを書き換えるNATを通過する場合があり、複数のデバイスが同じ出口IPで現れることがあります。切断後に再接続すると送信元ポートも変わる可能性があるため、一時的な送信元ポートを恒久的なデバイス番号として使用することはできません。
識別情報の対応付けには、検証済みの固定ネットワーク設定、またはアプリケーションプロトコルで定義された登録メッセージ、局番、認証情報を使用できます。どれを選ぶかは、端末、シリアルサーバー、中央ソフトウェアが実際に何をサポートしているかによって決まります。透過型シリアルサーバーは通常、バイトを転送するだけであり、データに一意の識別情報を自動的に挿入すると想定してはいけません。登録パケット機能が必要な場合は、実際の機種とファームウェアの資料を確認する必要があります。
シリアルスレーブのアドレスも、システム全体で一意とは限りません。例えば、独立した3つの配電盤内のメーターがすべて局番1に設定されていても、それぞれが3つの別々の接続に属していれば、中央側は「確認済みの配電盤番号と局番」の組み合わせで区別できます。しかし、バイトが混在し、局番1だけを見ていると、デバイスを誤認しやすくなります。局番はプロトコル内のアドレスであり、シリアルサーバー全体のグローバルに一意な識別情報とは異なります。
接続確立後は、まず識別情報を検証してからサービス操作を許可します。同じ識別情報で繰り返し接続される場合は、新しい接続を拒否するのか、古い接続を置き換えるのか、冗長化設計に従って処理するのかを明確にする必要があります。2つの接続が、同じデバイスレコードを気付かれないまま奪い合う状態にしてはいけません。また、自己申告された識別情報は信頼できる認証と同義ではなく、本番ネットワークでは認可とアクセス制御も組み合わせる必要があります。
4．透過伝送にプロトコルに基づくフレーミングが必要な理由
シリアルサーバーは、まずシリアルバイトを受信してバッファーに一時保存し、その後Ethernet経由で送信します。逆方向では、ネットワークからのバイトをシリアル出力へ渡します。ボーレート、データビット、パリティビット、ストップビット、電気的インターフェースは、現場の端末に合わせる必要があります。TCPは順序を保ったバイト伝送を担うものであり、メーターのレジスター、デバイス番号、制御コマンドを自動的に理解するわけではありません。
TCPはバイトストリームであり、中央側の1回の読み取りで、メッセージの半分だけを取得することも、2つのメッセージを取得することもあります。アプリケーションは、プロトコルの長さ、区切り文字、チェックサム、状態に関する規則に従ってデータを蓄積・解析し、完全なメッセージになってから処理する必要があります。図中のABCとDEFは、理解を助けるためのバイトの例にすぎず、実際のModbusフレームではありません。すべてのプロトコルで、ネットワークの1回の読み取りをメッセージの境界として扱うことはできません。
リクエストと応答も接続ごとに管理する必要があります。中央側が接続Aにリクエストを送った場合、接続Bで受信したデータをAの応答として扱ってはいけません。同じRS485バス上の複数のスレーブを読み取る場合は、プロトコルとデバイスの処理時間に従ってリクエストをスケジューリングし、応答またはタイムアウトを確認してから次の操作を行う必要があります。パケット化の待ち時間、ネットワーク遅延、シリアル伝送時間はいずれもタイムアウトに影響します。すべての待ち時間をゼロにするのではなく、パラメーターを項目ごとにテストしてください。
5．設定時はデータ経路に沿って区間ごとに確認する
まず中央プログラムの待受アドレスとサービスポートを設定し、複数の接続を同時に受け入れ、接続ごとに独立してデータを解析できることを確認します。次に、現場の各シリアルサーバーをTCP Clientに設定し、中央側のアドレスと宛先ポートを入力します。管理用Webページのポートをサービスポートと取り違えないでください。また、現場側と中央側の両方を接続待ちに設定しないでください。
次に、ルーティングとアクセスポリシーを確認します。中央側が内部ネットワークにある場合、公衆ネットワーク上のデバイスは中央側のプライベートアドレスだけではアクセスできません。管理されたVPN、プライベートネットワーク、または承認済みのマッピング方式が必要です。ポートの開放はネットワーク経路の一部にすぎず、デバイス識別、プロトコル変換、アプリケーションの認可まで自動的に完了するものではありません。ファイアウォールでは必要な送信元とサービスだけを許可し、サービスポートと一緒に管理インターフェースを安易に公開しないでください。
最後に、シリアル配線とパラメーターを確認し、デバイス1台で最小構成のシステムを構築して、リクエストと応答の内容を検証してからデバイスを追加します。以前の記事では、仮想シリアルポートとシリアル通信支援ツールですべての複数デバイス接続に対応できるとしていましたが、これはどの場合にも当てはまるわけではありません。仮想COMドライバー、中央プログラム、デバイスの動作モードは相互に互換性がある必要があります。独自開発のTCPプログラムでも、接続管理とプロトコル解析を実装する必要があります。
6．切断・再接続時および受入時にテストすべき事項
ネットワークが切断された後、古いセッションがサービス上の識別情報をいつまでも占有してはいけません。再接続時には識別情報を再検証し、未完了のリクエストをどう処理するかをプロトコルに従って決める必要があります。信頼性のあるTCP伝送であっても、切断の前後を通じてサービスコマンドが厳密に1回だけ実行されるとは限りません。起動・停止やリセットなどの操作は、タイムアウトしたという理由だけで無条件に繰り返し送信してはいけません。状態照会、トランザクション番号、またはデバイスがサポートする仕組みを使用して、重複実行を防ぐ必要があります。
受入試験では、各デバイスから区別できるデータを返させ、中央側の表示が実機と一致することを1台ずつ確認できます。その後、同時に接続し、データが混線したり応答が誤認されたりしないかをテストします。次に、そのうち1台を切断し、他のデバイスが動作を継続できるか、再接続したデバイスが正しいレコードに戻るかを確認します。接続数、シリアル送受信回数、タイムアウト、バッファーの状態も記録し、連続運転とピーク負荷をテストする必要があります。
7．機器選定時は実際の動作モードを確認する
FeichangのFCT-1500シリーズの公式サイトの詳細情報には、TCP Server/Client、仮想シリアルポートドライバー、各種RS232/422/485構成が記載されており、分散したシリアル機器のネットワーク化に利用できます。TCP Clientを選ぶことで、現場のデバイスから中央側へ能動的に接続できます。ただし、中央側での識別情報の対応付けとリクエストのスケジューリングは、引き続きシステム全体で対応すべき事項です。公式サイトに記載されたチャネルごとのマルチセッション機能は、中央ソフトウェアの処理容量の検証に代わるものではありません。具体的なインターフェース、モード、ファームウェアは、注文した機種に応じて確認する必要があります。
透過型のTCP接続と、Modbus RTUからTCPへの変換も、個別に確認する必要があります。プロトコル変換が必要な場合は、実際にサポートされているモードを選択して有効にし、透過伝送されるシリアルバイトを、そのままModbus TCPメッセージとして扱わないでください。一般的なトラブルシューティングについては、2295を参照してください。本記事では、複数デバイスの集約という独立した課題に焦点を当て、デバイスが見つからない、COMポートを開けないといった一般的な内容の重複掲載は避けています。
参考資料：IETF RFC 9293 TCP仕様;Linuxのaccept接続インターフェースのドキュメント;Feichang FCT-1500シリーズの詳細;シリアルサーバーのトラブルシューティング。原理図は一般的な仕組みを説明する模式図であり、実際の製品、実測結果、または保証された接続容量を表すものではありません。
中国語の技術記事から翻訳。原文の初公開日：2020-08-17。原文の最終改訂日時：2026-10-13T20:24:48+08:00。 中国語の原文を読む
