シリアルデバイスサーバーの障害は、まず、管理ツールでデバイスを検出できるか、ネットワーク接続を確立できるか、シリアルデータを正しく双方向に送受信できるか、という3つの層に分けて調べます。TCP接続の成功は、ネットワークセッションが確立されたことを意味するだけで、シリアル配線、パラメーター、アプリケーションプロトコルがすべて正しいことを意味しません。再起動や全パラメーターの変更を繰り返すよりも、データ経路に沿って層ごとにテストする方が効果的です。
1．まず、どの区間を担当するのかを理解する
一般的な透過型シリアルデバイスサーバーは、シリアルポートで受信したバイトを一時的に保存し、ネットワーク経由で相手側のプログラムに送信します。ネットワークから受信したバイトは、シリアルポートから送出します。Modbus RTUをModbus TCPへ自動的に変換するわけではありません。プロトコル変換が必要な場合は、機種と動作モードが対応しているかを確認する必要があります。「シリアルからネットワークへの変換」を、あらゆるプロトコル間の自動的な相互接続と捉えてはいけません。
作業を始める前に、デバイスの型番、ファームウェア、シリアルの電気方式、端子の定義、ネットワークアドレス、TCPポート、動作モードを記録します。「ホストコンピューター -> ネットワーク -> シリアルデバイスサーバー -> シリアル機器」の順序を図にし、どちらが要求を送信し、どちらが応答を返すかを明記します。産業現場では、最初にすべての機器を切り離さないでください。許可されたテスト環境で、端末1台、短いケーブル、既知の要求を使い、最小構成を組んでください。
2．管理ソフトウェアでデバイスが見つからない
まず、電源、ネットワークポートのリンク状態、コンピューターが実際に使用しているネットワークアダプターを確認します。検出ツールはLANブロードキャストや所定のUDPメッセージを使用することがあり、これらのメッセージがルーターを越えて転送されるとは限りません。コンピューターがインターネットにアクセスできることと、デバイスを検出できることは別です。VLANをまたぐ構成、無線端末間の隔離、複数のネットワークアダプター、VPN環境も、検出経路に影響する場合があります。
工場出荷時のアドレスまたは保存済みのアドレスを確認し、ほかのデバイスと競合していないか調べます。メーカーの指示に従い、同一の管理されたサブネット内でテストしてください。コンピューターのアドレスを安易に変更したり、アドレス不明のデバイスを本番ネットワークに接続したりしないでください。管理者は、スイッチのMACアドレス学習状況、アドレスのリース情報、アクセスポリシーを確認し、要求がデバイス側まで届いているかを判断できます。
ファイアウォールがツールを遮断している可能性はありますが、「すべてのファイアウォールを無効にする」という古い助言をそのまま実行すべきではありません。管理ツールの入手元、必要なポート、プロセスを確認し、必要なルールだけを許可して、送信元の範囲を制限します。あるブランドの検出用ポートを、ほかのブランドにも一般化することはできません。通信を許可した後はルールを記録し、管理インターフェースをインターネットへ直接公開しないでください。
3．デバイスは見つかるが、TCP接続を確立できない
TCP ServerとTCP Clientの役割を明確にします。Serverは接続を待ち受けるため、相手側がそのアドレスと待ち受けポートに接続する必要があります。Clientは、指定された相手に能動的に接続します。双方が待ち受けていたり、双方が誤ったアドレスに接続しようとしていたりすると、「デバイスはオンラインだがセッションがない」という状態になります。また、管理用Webポートとサービス用TCPポートは、通常、用途が異なります。
まずIP、マスク、ゲートウェイ、サービスポートを確認し、次に許可された環境で対象ポートへ到達できるかをテストします。Pingの成功はTCPポートが開いている証明にはならず、Pingの失敗も必ずしもデバイスがオフラインである証明にはなりません。ポリシーによってICMPがフィルタリングされている可能性があるためです。サブネットをまたぐ場合や公衆ネットワークで使用する場合は、ルーティング、NAT、ファイアウォールも確認する必要があります。できる限り管理されたネットワークまたはVPNを使用し、不要なシリアルサービスポートを直接開放しないでください。
接続がすでに使用されていないか、接続数が上限に達していないか、アイドルタイムアウトが発生していないか、サーバーが許可されていない送信元を拒否していないかを確認します。複数接続、再接続、キープアライブの仕組みはデバイスごとに異なり、「ポーリングすれば自動的に完了する」という説明でマニュアルの確認を代替することはできません。緑色のアイコンを見るだけよりも、接続状態と切断ログを保存する方が有意義です。
4．TCPは接続済みだが、シリアルポートから応答がない
RS232、RS422、RS485が端末と一致しているか、また、本機の表示に従って端子が接続されているかを確認します。A/Bの名称はメーカーによって異なる場合があるため、まず電気的な定義を確認してからテストし、色から極性を推測しないでください。RS485は、バストポロジー、終端抵抗、基準グランドと併せて設計する必要があり、複数の短い分岐線を安易に拡張してスター型ネットワークにしてはいけません。
双方のボーレート、データビット、パリティ、ストップビット、フロー制御を一致させる必要があります。速度が同じだけでは不十分で、パリティエラーによって受信側がデータを拒否することもあります。RS232機器がハードウェアフロー制御を必要とする場合、制御線がないと送信が停止する可能性があります。確認せずにフロー制御を無効にしたり、端子を短絡したりしないでください。
正しいことが確認されている要求を使ってシリアル送信カウントを確認し、次に応答カウントを確認します。バイトが送信されたのに何も返らない場合は、配線、端末の電源、局番、要求形式を重点的に調べます。応答を受信しているのにホストコンピューターがエラーを報告する場合は、プロトコル解析、タイムアウト、シリアルパラメーターを重点的に調べます。ループバックテストは、マニュアルで明示的に許可されたインターフェースと配線方法でのみ実施してください。RS485にRS232のループバック方法をそのまま適用することはできません。
5．遅延、パケットの分割・結合がポーリングに影響する理由
シリアル伝送には実際の時間がかかり、デバイスの処理、ネットワーク伝送、シリアルデバイスサーバーのパケット化にも時間がかかります。パケット化の条件には、バイト数、時間間隔、区切り文字などがあります。より多くのバイトが揃うまで待つと小さなパケットを減らせますが、応答が返るまでの時間も長くなります。ホストコンピューターの待ち時間が短すぎると、まだ伝送中の正しい応答をタイムアウトと判断する場合があります。
古い記事では、送信間隔とバイト数をすべてゼロに設定することを万能な解決策としていますが、すべての機種に当てはまるわけではありません。まずパラメーターの意味を読み、短いリンクで応答時間を測定してから、プロトコルの区切りと負荷に応じて項目ごとに調整します。透過型のTCPは順序の保たれたバイトストリームを提供し、1回の読み取りに半分のフレームや複数のフレームが含まれる場合があります。ホストコンピューターはアプリケーションプロトコルに従って蓄積、分割、検証を行い、TCPの1回の読み取りが1つの完全な応答になることを前提にしてはいけません。
6．仮想シリアルポート、ファイルデータの欠落、複数クライアント
仮想シリアルポートドライバーを使うと、アプリケーションはネットワーク機器へローカルCOMポートと同じようにアクセスできますが、機種、ドライバーのバージョン、モード、権限が適合している必要があります。専用のプロトコルモードを持つ機器もあれば、透過的なバイトを直接転送する機器もあるため、「Socketを使用する場合は特定のオプションを無効にしなければならない」と一律には言えません。マニュアルに従ってドライバーとデバイスの設定を確認し、複数のプログラムが同時にCOMポートを占有しないようにしてください。
ネットワークからバッファーへデータが入る速度が、シリアルポートからの出力速度を上回る場合があります。適切なフロー制御、バッファリング、アプリケーションによる確認なしに書き込みを続けると、データが失われる可能性があります。「模擬ボーレート」オプションの調整は、すべてのファイル転送に通用する万能な解決策ではありません。まず、アプリケーションがフロー制御、データの区切り、再送に対応しているかを明確にし、全長と内容の検証をテストしてください。
複数のコンピューターが1台のシリアル機器へ同時にアクセスする場合、要求の競合や、応答がどの要求元に属するかという問題も生じます。複数のTCP接続に対応していることは、複数のマスターがRS485スレーブを同時に安全に制御できることを意味しません。要求は、アプリケーション間の調整、プロキシ、または明示的に対応しているモードによって管理する必要があり、異なるクライアントからの書き込みが無秩序に混在することを許してはいけません。
7．再テストと製品機能の確認
修復後は、起動、連続ポーリング、ネットワーク切断、復旧をテストし、応答の正確性、再接続時間、バッファリングの動作を観察します。1回成功しただけでは、高負荷時の安定性を意味しません。最終的なパラメーターと切り戻し用の設定を記録したうえで、現場のノードを段階的に再接続し、一度に多くの条件を変更しないようにします。
FeichangのFCT-1500シリーズの詳細情報には、RS232/422/485、仮想シリアルポート、関連するネットワークモードの設定手順が記載されています。対応する光ポート構成のDDM診断は、光モジュールの状態確認に役立ちます。トラブルシューティングでは、まず実際の型番、ポート構成、有効になっているモードを確認し、その後、これらの機能を使ってネットワーク、光伝送路、シリアルの問題を切り分けます。これをすべてのシリアルデバイスサーバーに一般化することはできません。
参考資料：Moxaのシリアルネットワーク接続およびパケット化の説明;Feichang製品2855の詳細。2295、2084、2115にある3種類の異常、仮想シリアルポート、複数クライアントに関する内容を取り入れています。図は一般的な説明図であり、実際の製品や実測時間を示すものではありません。
中国語の技術記事から翻訳。原文初公開日：2022-12-20。原文最終改訂日時：2026-10-13T19:15:07+08:00。 中国語の原文を読む
