FCTEL オリジナル技術記事 · FCTEL技術チーム
初公開：2026-10-04 · 最終更新：2026-10-04
RS232またはRS485の機器をEthernetに接続しても、1回の読み取りで返されるデータが、その機器からの完全なメッセージ1つであるとは限りません。メッセージの分割や結合は、多くの場合、データ損失ではなく、シリアル層、ネットワーク層、アプリケーション層で境界が異なることを反映しています。これらの層を理解すれば、信頼性の高いパーサーを構築し、障害の実際の原因を特定できます。本記事では一般的な仕組みを説明します。特定のFCTEL製品が対応するモード、バッファの動作、パラメーターの範囲は、その製品のマニュアルで確認する必要があります。
詳細は元の画像を開いて確認してください。図を横方向にスクロールすると、すべてのラベルを原寸で読めます。
UARTは文字をフレーム化し、アプリケーションプロトコルはメッセージを定義する
UARTは通常、スタートビットで文字を開始し、合意した数のデータビットを送り、必要に応じてパリティを付加し、ストップビットで終了します。受信側は、設定されたボーレートと形式に従って文字を復元します。ボーレート、データビット、パリティ、ストップビットを一致させる必要があります。そのため、不適切な信号レベル、ノイズ、サンプリングエラーによって、ネットワークが関与する前の段階で文字エラーが生じることがあります。
8N1では、8ビットのバイトにもスタートビット1つとストップビット1つが必要で、合計10ビット時間となります。例として9,600 bit/sの場合、1文字に要する時間は約1.04 msです。これは計算例であり、製品の性能仕様ではありません。有効なバイトスループットが公称ビットレートより低くなる理由と、到着する文字をバッファが受け入れる必要がある理由を示しています。
RS232、RS422、RS485はそれぞれ異なる電気的インターフェースと接続構成を表し、UARTは文字のタイミングを表します。いずれも、それ自体でアプリケーションメッセージを定義するものではありません。温度の問い合わせは複数のバイトで構成される場合があります。機器は、長さ、区切り文字、固定形式、またはプロトコルで規定された時間間隔によって、メッセージ境界を別途定義する必要があります。
シリアルデバイスサーバーが2つの仕組みをつなぐ方法
受信方向では、まずシリアルインターフェースが電気信号からバイトを復元します。バイトはFIFOまたはソフトウェアバッファに入ります。その後、パケット化ロジックが、実装された長さ条件や待機条件に従って一部のバイトをネットワークスタックに渡します。逆方向では、バイトがネットワーク受信バッファから取り出され、UARTによって1文字ずつ送信されます。各方向には独自のバッファリングとスケジューリングがあります。
1つのアプリケーションメッセージが複数のシリアル受信単位にまたがる場合も、1つの受信単位に複数のメッセージが含まれる場合もあります。パケット化は待機時間と送信効率のトレードオフを調整するものであり、あらゆる上位層プロトコルを自動的に理解するわけではありません。FCTELの公開シリアルサーバー資料には、TCPサーバーモードとTCPクライアントモードが記載されています。特定のフレーミング方式が利用できるかどうか、およびその設定名と範囲は、該当モデルのマニュアルで確認する必要があります。
アップリンクが遮断されている間もシリアル送信元が送信を続けると、バッファの使用量が増加します。TCPのバックプレッシャーはネットワーク送信を制限できますが、適切なフロー制御を備えていないシリアル送信元を停止させることはできません。バッファ容量、対応するハードウェアまたはソフトウェアフロー制御、送信元の動作、切断時の処理方針を合わせて評価する必要があります。TCPによる信頼性の高い転送は、任意の輻輳条件下で無制限に損失なく動作できることを意味しません。
詳細は元の画像を開いて確認してください。図を横方向にスクロールすると、すべてのラベルを原寸で読めます。
TCPが保持するのはバイトの順序であり、個々の送信境界ではない
TCPは接続を順序付きバイトストリームとして提供します。シーケンス番号がバイト位置を識別し、確認応答、再送、フロー制御が転送を管理します。TCPセグメントはネットワーク上の転送単位であり、業務メッセージはアプリケーションプロトコルに属します。送信側の1回の呼び出しと同じ量のデータを、受信側が1回の読み取りで取得する必要はありません。
機器が6バイトのメッセージAに続いて4バイトのメッセージBを生成するとします。正常な転送では、同じ10バイトが同じ順序で届けられます。プログラムは、最初にAの先頭2バイトを読み取り、次に残りの8バイトを読み取ることも、10バイトすべてを一度に読み取ることもあります。これらは一般にメッセージの分割や結合と呼ばれます。バイトが欠けずに正しい順序で届いている場合、どちらもそれ自体ではデータの破損を示しません。
読み取り長は、利用可能なデータ、受信バッファリング、スレッドのスケジューリング、インターフェースの引数に依存します。ネットワークでのセグメント分割は、経路とスタックにも依存します。アプリケーションは、キャプチャしたTCPセグメントの長さから業務メッセージの長さを推定したり、読み取りが返るたびに機器からの応答1つとして扱ったりすることはできません。接続が閉じられた場合も、受信済みの完全なデータを処理し、末尾の未完メッセージを識別する必要があります。
詳細は元の画像を開いて確認してください。図を横方向にスクロールすると、すべてのラベルを原寸で読めます。
堅牢なパーサーは読み取り間で状態を保持する
継続的に保持するバイトバッファを用意します。読み取りのたびにデータを追加します。解析ループでは、まずヘッダーが揃っているかを確認し、次にプロトコルの長さ規則または終端規則を適用します。完全なメッセージだけを検証し、業務層に渡します。未完のバイト列は次の読み取りまで保持し、複数の完全なメッセージは、残りを破棄せずに個別に解析します。
同期マーカー、長さ、ペイロード、チェックサムを含む独自プロトコルでは、長さにヘッダーを含むかどうか、バイトオーダー、許容される最大サイズ、チェックサムの対象範囲を規定してください。図は説明用の架空の形式を使用しており、FCTELのプロトコルではありません。実環境では実際の機器のプロトコルを使用し、バッファの増大に上限を設け、あり得ない長さを拒否してください。1つの不正なバイトによって以降のすべてのメッセージの位置がずれないように、検証失敗後の再同期方法を定義してください。
区切り文字ベースのプロトコルでは、エスケープ処理や、バイナリペイロード内に現れる区切り文字と同じ値への対応が必要です。固定長プロトコルでは、メッセージ種別によって長さが異なる場合を考慮する必要があります。タイミングベースのシリアルプロトコルでは、シリアル回線上で観測される間隔と、ネットワークアプリケーションが認識する到着時刻を区別してください。バッファリングとスケジューリングによって、それらの間隔は変化します。TCPの読み取り間隔が、元のシリアルのフレーム間隔になるとは限りません。
パケット化の待機時間によって変わるもの
待機時間を長くすると、送出前により多くのシリアルバイトをまとめ、小さな転送のオーバーヘッドを削減できる場合がありますが、最初のバイトの送出が遅れる可能性があります。待機時間を短くすると、より早くバイトを転送できる一方で、アプリケーションが受け取る未完メッセージが増える場合があります。どちらも正しい解析の代わりにはなりません。1回の読み取りにつき1メッセージを要求するのではなく、業務上の遅延とデータの完全性を最適化してください。
要求・応答型通信では、機器の処理、シリアル送信、サーバーのバッファリング、ネットワークの往復時間、アプリケーションのスケジューリングを個別に考慮してください。条件を管理したテストを用い、これらの段階をカバーするようにタイムアウトを設定します。再試行の動作は業務上の意味に従う必要があります。タイムアウト後に無条件で再送を無期限に繰り返すのではなく、書き込みコマンドや動作コマンドを繰り返しても安全かどうかを判断してください。
受け入れテストでは内容、タイミング、復旧を検証する
条件を管理したテストでは、識別しやすいシーケンス番号と長さを使用してください。単独のメッセージ、連続するメッセージ、分割された入力、長いペイロード、短い休止を対象に含めます。同じパーサーを意図的に異なる読み取りサイズで動作させ、最終的なメッセージ件数、順序、ペイロード、検証結果を確認してください。これは、単に正常に見える端末画面よりも確かな根拠となります。例は顧客の測定値ではなく、テスト入力として記録してください。
次に、シリアル形式の不一致、アップリンクの中断、輻輳、再接続をそれぞれ個別にテストします。シリアルの文字エラーとネットワーク再送、バッファオーバーフローと通常の分割、業務上のタイムアウトとデータ完全性の障害を区別してください。入力バイト数、解析済みメッセージ、バッファの残存内容、エラー原因、復旧時間を記録し、パケットキャプチャとシリアルログで使用した時刻基準を保持してください。
FCTELのシリアルデバイスサーバーを選定する際は、実際のインターフェース、動作モード、フロー制御、切断時の動作を確認してください。設計上の重要な区別は、サーバーが接続とデータ転送を担い、アプリケーションプロトコルがメッセージを定義し、パーサーが複数回の読み取りにまたがってメッセージを復元するという点です。役割を明確にすることで、通常のストリーム動作をハードウェア障害と誤認するのを防げます。
技術参考資料： IETF RFC 9293、TCPバイトストリームサービス。関連するFCTEL資料： 技術記事 および シリアルデバイスサーバーの製品資料（中国語）.
