シリアル機器のネットワーク接続効率は、Ethernet速度だけでは決まりません。トランザクションには、シリアル伝送、機器の処理、ネットワークでの待機、アプリケーションによる解析が含まれます。ポーリングでは、低速な局や障害局、再試行の影響も加わります。すべての設定値を最大にするのではなく、必要な時間内にデータが正しく到着するよう最適化してください。透過型サーバーが自動的に圧縮、サンプルの同期、任意のプロトコルの修正を行うわけではありません。
1回の応答時間を分解する
要求はコンピューターからネットワーク経由でサーバーへ送られ、その後シリアル回線を1ビットずつ進みます。計測器は要求を完全に受信してから処理し、逆の経路で応答します。各段階で時間がかかります。ネットワークをギガビットに高速化しても、計測器の処理時間やシリアル伝送時間はなくせません。
計算例として、8N1にはスタートビット1ビット、データビット8ビット、ストップビット1ビットが含まれ、1バイトあたり回線上では10ビットになります。9600 bit/sでは、20バイトの伝送に約20.8 msかかります。これは片方向のシリアル伝送時間のみで、要求、処理、ネットワーク、スケジューリングの時間は含みません。トランザクションの応答時間を保証するものではありません。
ポーリング周期内で各局に必要な時間を確保する
各局の通常のトランザクション、無通信区間、スケジューリング、再試行に割り当てる時間を合計して、周期を見積もってください。局数が同じでも、応答や処理が異なるため周期が異なることがあります。更新の実現可能性を判断する前に、プロトコル、要求の長さ、標準的な応答と最大応答を整理してください。
切断された局が長いタイムアウトや再試行を繰り返すと、正常な局に使える時間が奪われます。再試行回数の制限、アラーム、管理された頻度低減、またはアプリケーションの規則に基づく一時的な切り離しを使用してください。タイムアウトを無制限に延長してエラーを隠したり、無差別に短い制限を設けて正当な遅い応答を破棄したりしないでください。
パケット化の待ち時間が応答性に与える影響
サーバーは、所定の文字数に達するか、所定の無通信時間が経過するまで送信を待つ場合があります。これにより小さなパケットは減りますが、最初のバイトの送信が遅れます。待ち時間が短いとオーバーヘッドが増えることがあり、長いとアプリケーションのタイムアウトを引き起こすことがあります。一律のミリ秒値ではなく、プロトコルと周期の要件に合わせて選択してください。設定可能な範囲とフレーミング動作はマニュアルで確認してください。
TCPは順序付きバイトストリームであり、1回の読み取りが1つのメッセージに対応するわけではありません。パケット化の最適化は、長さ、終端文字、妥当性確認に基づくプロトコルのフレーミングに代わるものではありません。パケット数が変わっても、必ずしもデータが失われたとは限りません。誤った指標を最適化しないよう、完全なバイト列とトランザクションを比較してください。
バッファは一時的な繁忙に対応する
ネットワークのバーストデータは、シリアル回線で1ビットずつ出力される前にキューに蓄積されることがあります。有限のバッファは待合場所に似ています。一時的な混雑は収容できますが、流入量が流出量を継続的に上回ると、やがて満杯になります。機器のバッファが満杯になったとき、データを破棄するのか、ブロックするのか、その他の動作をするのかを確認してください。大容量バッファでも、無制限のスループットを提供したり、任意の長さの停止中にデータが失われないことを保証したりはできません。
フロー制御には、互換性のあるインターフェース、配線、ソフトウェアが必要です。RTS/CTSとXON/XOFFは、任意の2線式RS485機器に使える万能な解決策ではありません。データ生成側、キュー、消費側の速度を整合させてください。安定して処理できる容量を超える場合は、再試行を増やすのではなく、要求を減らす、アプリケーションを最適化する、独立したチャネルを割り当てるといった対策を取ってください。
クライアント間でトランザクションを調整する
1つのシリアルポートに複数のネットワークセッションを接続できても、単一マスター方式の計測器へ複数のプログラムが同時に問い合わせてよいわけではありません。コマンドが混在すると、応答の帰属、タイムアウト、実行に混乱が生じます。単に接続数を増やすのではなく、制御用と読み取り専用の役割を定義する、データを一元的に配信する、検証済みのスケジューリングを使用するといった方法を取ってください。
持続的接続は接続確立のオーバーヘッドを回避できますが、切断、無効になったセッション、復旧への対応が必要です。ネットワークのキープアライブが確認するのは接続状態であり、アプリケーションの動作ではありません。許可されていない確認要求を送信せずに、業務上のハートビートの意味を定義してください。再接続時に、バッファ内のすべての書き込みを無条件に再送してはいけません。実行の成否が不明なものは、アプリケーションの規則に従って確認してください。
順序どおりの到着は同期サンプリングではない
TCPが保持するのは接続内の順序であり、計測器間での同時計測ではありません。コンピューターの受信時刻とセンサーのサンプリング時刻は異なります。時間を整合させるには、タイムスタンプの起点、クロック同期、誤差の測定を定義してください。すべてのサーバーがすべてのレコードに自動でタイムスタンプを付けると主張してはいけません。
透過伝送では、エンドポイント間の合意なしに任意の元メッセージを圧縮することはできません。CRCは特定のエラーを検出しますが、すべての障害を自動的に修正するわけではありません。解析を行うゲートウェイと透過型サーバーは役割が異なります。計測器、サーバー、アプリケーションのどこにボトルネックがあるかを特定するため、責任範囲を分けてください。
一度に1つの変数を最適化する
正常動作が確認された設定と生のメッセージを保存し、シリアル側とネットワーク側の時間を記録して、トランザクションの成功、応答時間の分布、タイムアウト、再接続を評価してください。平均が速くても分布の裾にある長い遅延が隠れることがあるため、高パーセンタイル値と最悪の異常値を確認してください。許可なく本番環境に負荷をかけたり、プロトコルを変更したりしないでください。
同一の負荷条件で、パケット化、ポーリング頻度、タイムアウト、再試行の設定を1つずつ評価してください。すべてのポート、1局の障害、ネットワークの中断、アプリケーションの再起動を対象に含めてください。実際の文書に基づいてFCTELのチャネルとモードを選び、CPU名、Ethernet速度、条件の明示されていない宣伝用の曲線ではなく、実測したシステムのサービス水準を基準に受け入れを判断してください。
参考資料：TCPバイトストリーム仕様；FCTELシリアルデバイスサーバーの詳細。図は一般的な仕組みを示しています。曲線は実測値でも性能保証でもありません。
中国語の技術記事から翻訳。原文の初回公開：2025-02-13。原文の最終改訂：2026-10-13T15:49:49+08:00。 中国語の原文を読む
