コンピューターがPLCに接続され、リンクランプも点灯したままなのに、パラメーターの読み取りがときどき止まります。少しすると再開し、データも失われていないように見えます。機器の処理が遅いのではなく、TCPが欠落部分を埋めている可能性があります。TCPは、多くの監視用コンピューター、ゲートウェイ、コントローラーが使用するトランスポートの仕組みです。バイトストリームを順序どおりに届けるよう動作します。本ガイドでは、数式による導出を使わずにバイトの流れを追い、誰が記録を保持し、誰が待機するのか、そして最終的にデータを受信できても生産サイクルに影響が出る理由を説明します。
1．ネットワークがデータを運び、エンドポイントが再送する
監視用コンピューターはデータを自身のTCP実装に渡し、その後、ネットワークインターフェースと産業用スイッチを経由してPLCへ送信します。スイッチは通常、Ethernetアドレスを使用してEthernetフレームを転送します。そのTCP接続に代わって、各バイトの確認応答を行うわけではありません。送信記録を保持し、確認応答を処理して、再送のタイミングを決めるのは通信のエンドポイントです。ゲートウェイが接続を終端して別の接続を開始する場合は、経路全体を単一の分割されていないチャネルとして扱わず、2つの接続を個別に解析してください。
TCPを、各位置に番号が付いた連続した原稿と考えてください。転送時には大きさの異なる荷物に分割できますが、受信側は最終的に内容を正しい順序で得る必要があります。この例えが説明するのは、番号付けと欠落部分の補完だけです。TCPは原稿の意味を理解しません。バイトが温度、パラメーターファイル、起動コマンドのどれを表すのかを判断できません。その情報が有効かどうかは、アプリケーションが判断する必要があります。
2．シーケンス番号と確認応答番号は、荷物ではなくバイトを数える
簡単な例として、確立済みの接続が、バイト範囲1001–1100、1101–1200、1201–1300をそれぞれ含む3つのデータセグメントを送信するとします。これらの番号は説明用の例であり、実際の接続の初期シーケンス番号は固定ではありません。SEQは、セグメント内のデータの先頭シーケンス番号を示します。ACKは、連続したストリームの中で受信側が次に期待するバイトを示します。最初のセグメントが到着すると、確認応答は1101を示し、それより前の連続した内容を受信済みであることを確認できます。
2番目のセグメントが欠落し、3番目が到着した場合、受信側は通常、後続のデータをバッファーに保持できますが、累積確認応答は1101のままになります。バイト1300を受信したことと、その間のすべてのバイトがそろっていることは異なります。欠落部分が埋まると、確認応答を先に進められます。ACKはパケット番号ではないため、キャプチャーの行数を数えるだけでは、アプリケーションの内容がどれだけ欠落しているかは分かりません。
3．重複確認応答とタイマーは異なる手掛かりを示す
送信側は、まだ確認応答を受けていないデータを保持します。後続のデータが到着し続けると、受信側は同じ確認応答番号を繰り返し通知し、それ以前に欠落部分があることを示す場合があります。従来型の高速再送の例では、3つの重複ACKを受け取ると、欠落したセグメントの再送が開始されます。現在の実装では、ほかの損失検出方法を使用することもあります。すべての機器が、単純化された1つのタイミング図に厳密に従うわけではありません。
通信量が少ない場合、繰り返し確認応答を発生させるだけの後続データがないことがあります。その場合は、再送タイマーが復旧の仕組みとして働くことがあります。RTO（再送タイムアウト）は、確認応答を待つ時間です。エンドポイントは、すべての接続に同じ固定値を使うのではなく、往復遅延とその変動を考慮します。必要な確認応答がないままタイマーが満了すると、データを再送します。応答がない状態が繰り返されると、一般に待機時間は長くなります。ここで示す特定のミリ秒値は、FCTEL製品に関する保証ではありません。
4．データが復旧しても、目に見える一時停止が生じることがある
再送には時間がかかります。受信側は、欠落部分が埋まるまで待ってから、その後に続く連続したバイトをアプリケーションに渡す場合があります。データがネットワークインターフェースに届いていても、表示がすぐに更新されるとは限りません。これは、トランスポートの仕組みによって起こり得る現象の1つです。リンクランプが点灯していても、アプリケーションの更新が常に時間どおりに行われるとは限りません。また、一度の一時停止だけでは、特定のスイッチポートが原因だとは判断できません。
TCPは、ネットワークの状態に応じて、一度に送信するデータ量も制御します。損失を輻輳の兆候と見なし、送信側が送信量を減らす場合があります。これはエンドポイントのプロトコル内で行われる動作であり、ネゴシエーションで決まったポート速度が自動的に低下したことを意味しません。物理リンクが引き続きギガビット速度を示していても、接続が実際に届ける有効なデータ量は一時的に減少することがあります。信頼性のある転送は欠落データの復旧を試みますが、産業用制御の一定の期限を保証するものではありません。
5．TCPの確認応答はタスク完了通知ではない
TCP ACKは、対向側のTCP受信処理で対応するバイトが受信されたことを確認します。PLCアプリケーションがパラメーターを承認したこと、所定の書き込み先に書き込んだこと、またはモーターの動作を完了したことの証明にはなりません。アプリケーションプロトコルには、多くの場合、独自の応答、例外コード、完了状態があります。トランスポート層の確認応答、プロトコル応答、機器の動作結果は、タイムスタンプをまとめて1つの成功メッセージにするのではなく、個別に記録してください。
同じ接続上で重複するバイトが再送されると、TCPはシーケンス番号を使って重複を認識し、通常は新しいストリーム内容としてアプリケーションに渡しません。一方、アプリケーションがタイムアウトしてコマンドを再送すると、それは別のアプリケーション要求になります。TCPは、2つの要求が同じ意味かどうかを判断できません。再接続後は、要求識別子、実行状態、およびアプリケーションプロトコルで定義された重複要求の規則を確認してください。動作コマンドを際限なく繰り返すことは、適切な完了確認方法ではありません。
6．双方向を調査し、アプリケーションのタイミングと照合する
一時停止した時刻、エンドポイント、プロトコル、データ量、操作を記録してください。そのうえで、ポートのエラー・破棄カウンター、接続ログ、両端のキャプチャーを調べます。同じバイト範囲の再送は有用な手掛かりです。ACKが進んでいるか、データの順序が入れ替わっているか、通知される受信ウィンドウが小さくなったりゼロになったりしていないかも確認してください。ウィンドウは、受信バッファーが受け入れられるデータ量を示すものであり、ケーブルが接続されているかどうかとは別です。
キャプチャーツールは、観測したパケットを解釈して再送と判定します。故障した部品を直接測定したわけではありません。ミラーポートの過負荷、キャプチャー時の取りこぼし、キャプチャー開始の遅れは、解析を誤らせる可能性があります。ネットワークインターフェースのオフロード機能によって、ホスト上のキャプチャーでセグメント分割の見え方が変わることもあります。両側の記録を比較し、往路データの欠落、戻りの確認応答の欠落、単にキャプチャーで観測できなかったパケットを区別してください。
同じ時間帯にフレームチェックエラーが増える場合は、コネクター、配線、シールド、干渉を点検してください。トラフィックのバーストに伴って破棄が増える場合は、送出側で競合するトラフィックとバッファリングを調査してください。ルーターやトンネルを経由する大容量転送だけが失敗する場合は、経路上のサイズ制限も調査してください。条件は一度に1つずつ変更し、変更前後の証拠を残してください。アプリケーションのタイムアウトを延ばすだけでは、トランスポートの遅延を解消せず、症状を隠してしまうことがあります。
戻り方向の通信も重要です。データは届いていても、その確認応答が戻りの経路で失われることがあります。確認応答がなければ、送信側は再送する場合があり、受信側は重複したバイトを認識します。したがって、再送されたという事実だけでは、最初のデータが宛先に届かなかった証拠にはなりません。往路と復路を別々に図示し、受信側の記録と比較してください。そうしなければ、送信側の近くのケーブルを交換しても、実際の戻り経路の問題を見落とす可能性があります。一方向の転送だけで接続全体を代表させるのではなく、双方向を試験してください。
7．内容の正確さと、期限内に利用できる結果を確認する
FCTELの管理型産業用スイッチの資料は、インターフェースと管理機能を確認する出発点になります。実際のモデル、マニュアル、ファームウェアで、どのカウンターとログが提供されるかを確認してください。本記事は、一般的なTCPの動作を説明するものです。スイッチがエンドポイントに代わってTCPを処理することや、他社のプロトコル実装が特定のFCTEL機器の性能を表すことを主張するものではありません。
復旧後は、ファイルやパラメーターの内容を確認し、続いて連続運転中の応答時間の分布と例外を観測してください。動作要求については、完了状態とコマンドを繰り返した場合の挙動も確認してください。現場で合意されたアプリケーションの期限を使用し、単発の一時停止、進行する状態悪化、実際の切断を区別してください。覚えておくべき点は3つです。TCPはバイトの欠落を補うこと、復旧には時間がかかること、そしてデータの受信とタスクの完了は別々に確認する必要があることです。
保守報告書には、症状と証拠を明記する必要があります。どの期間にどのバイト範囲が再送されたか、アプリケーションの応答が遅れたか、ポートカウンターに変化があったかを記載してください。単に「ネットワークの問題」と書くだけでは不十分です。具体的な記録があれば、ネットワーク、機器、ソフトウェアの各チームが、自分の機器は正常だとそれぞれ主張するのではなく、同じ事象を解析できます。キャプチャーに使用した時計が異なる場合は、無関係な2つの事象を結び付けて原因と見なす前に、両者の時刻の関係を確認してください。
技術参考資料： RFC 9293：TCPのシーケンスと確認応答; RFC 6298：再送タイマー; RFC 5681：従来型の高速再送と輻輳制御; Wireshark：TCPの解析; Wireshark：オフロードとキャプチャーの解釈。関連資料： 技術記事 および FCTELE FCM-G24FG4 マネージド 24ポート ギガビットイーサネット＋4ポート コンボスイッチのドキュメント。AIの支援で作成した独自の図は一般的な原理を示すものであり、製品の測定結果ではありません。
