シリアルサーバーは、2種類のプラグをそのまま接続する装置ではありません。まず電気トランシーバー回路でシリアル信号を受信し、UARTを通じてバイトを復元した後、プロセッサーとネットワークインターフェースを介してネットワークへ送信します。逆方向の処理も、これらの段階を経由します。インターフェースの誤接続、パラメーターの不一致、バッファの輻輳、アプリケーションプロトコルのエラーを区別するには、内部のデータ経路を理解する必要があります。
1.どのような問題を解決するのか?
多くの計測器、コントローラー、カードリーダーでは、現在もRS232、RS422、またはRS485インターフェースが使われている一方、コンピューターや中央システムでは主にEthernetが使われています。シリアルサーバーは両者の間でデータを転送し、既存の端末にネットワーク経由でアクセスできるようにします。ネットワークケーブルを接続しただけで測定値を理解するわけではなく、すべての旧来のソフトウェアとの完全な互換性を保証するものでもありません。また、機器の処理速度を無限に高めるものでもありません。
コンピューターで計測器を読み取る場合を考えてみましょう。コンピューターはまず指定されたネットワークチャネルを確立し、計測器が認識できる要求を送信します。シリアルサーバーはその要求バイトを計測器に送り、応答をコンピューターへ返します。要求のどのフィールドが局番で、どのフィールドが読み取り値なのかは、アプリケーションプロトコルによって定義されます。透過伝送とプロトコル変換は異なる機能であり、機種選定時には個別に確認する必要があります。
2.電気トランシーバーとUARTはそれぞれ何をするのか?
ケーブル上に最初に現れるのは電気信号であり、すでに解釈されたレジスター値ではありません。シリアル用の電気トランシーバーは、対応するインターフェースの信号レベルと駆動を担います。RS232は一般に基準点に対する信号を使用し、RS485は2本の信号線間の電圧差を使用します。RS422は通常、送信と受信に独立した差動ペアを使用します。端子の外観が似ているからといって、直接相互接続することはできません。
UARTは、合意されたバイトフォーマットに従って送受信を行う非同期シリアルコントローラーです。送信時には、データをスタートビット、データビット、任意のパリティビット、ストップビットで構成します。受信時には、ボーレートとフォーマットに従って信号を判定し、バイトを復元します。ボーレート、データビット、パリティビット、ストップビットのすべてを一致させる必要があり、「両方とも9600である」ことだけを確認しても不十分です。

古い記事では、Modbusを必須の「通信チップ」として説明していますが、これは誤解を招きます。Modbusは通信プロトコルであり、そのメッセージはプロセッサー上のソフトウェアで解析できます。機器にModbusという特定の名称のチップが搭載されている必要はありません。同様に、RS485インターフェースがあることは電気的な接続方式を示すだけであり、その機器がModbus RTUをModbus TCPに変換できる証拠にはなりません。
3.バッファを省略できない理由
シリアルデータとネットワークデータは、同じペースで到着するわけではありません。Ethernetでは多数のバイトが一度に届く場合がありますが、シリアルポートはボーレートに従って1つずつ送信する必要があるため、機器には一時保存用のバッファリングが必要です。逆方向の受信でも、シリアルのバイトが一定の長さまで蓄積されるか、一定時間待機した後に、送信用としてネットワークへ渡される場合があります。
バッファは一時的な待機場所のようなものですが、容量には限りがあります。長期にわたりネットワークからの書き込み速度がシリアルポートの出力速度を上回り続けると、フロー制御、受け付け拒否、またはデータ破棄が発生するまで、キューが増え続ける可能性があります。具体的な動作は機種によって異なります。ネットワークインターフェースが高速であっても、端末側のシリアルポートが同じ速度で動作できるわけではありません。連続伝送では、フロー制御、アプリケーションの受信確認、機器のバッファリング規則を確認してください。
TCPは順序付きバイトストリームを提供し、正常な配送時にはバイトの順序を維持しますが、アプリケーションによる個々の書き込みのメッセージ境界は保持しません。アプリケーション側では、引き続きバイトを蓄積し、独自のプロトコルに従ってフレームを組み立てる必要があります。バッファがオーバーフローしていなくても、不完全なフレームを完全なフレームとして扱えば解析に失敗します。すべての問題をハードウェアのパケット損失に帰することはできません。
4.プロセッサー、ネットワークインターフェース、管理機能
プロセッサーは設定プログラムとネットワーク通信プログラムを実行し、シリアルチャネル、接続状態、バッファリングを管理します。Ethernetインターフェースは、対応するネットワーク信号の送受信を行います。RJ45は一般的な電気ポート用コネクターにすぎず、プラグの形状だけでは、機器が対応する速度、電源供給、サービスプロトコルを判断できません。光ポートを備えた製品では、光モジュールとリンクの仕様も確認する必要があります。
管理用Webページとサービスデータチャネルも区別する必要があります。HTTPのWebページは設定に使われますが、計測器のデータもHTTPで伝送しなければならないという意味ではありません。機器がTCP Client、TCP Server、またはUDPに対応している場合にのみ、それぞれのサービスアクセス方式に対応していることが示されます。利用可能なモード、同時接続数、キープアライブ、再接続、登録機能は、実際の機種とファームウェアに照らして確認してください。
ウォッチドッグは、プログラムが正常に応答しなくなったときに動作を復旧させるために使用できる、異常監視とリセットの仕組みです。ただし、リセットでは配線の誤り、局番の重複、不適切なアプリケーションのタイムアウト設定は修正できず、制御コマンドが繰り返し実行されていないことを証明することもできません。機器が頻繁に再起動する場合は、自動再起動を正常で安定した動作と見なすのではなく、原因を記録してください。

5.絶縁と保護はチップ名だけでは判断できない
絶縁は異なる電気部分間の直接的な導電経路を制限するために使用され、サージ保護は規定条件下で過渡的な影響に対処するために使用されます。この2つは同じ機能ではありません。また、シリアルポートに個別の番号が付いていても、チャネル間が電気的に絶縁されているとは限りません。絶縁がシリアルポートとシステムの間にあるのか、ポート間にあるのかに加え、定格条件と接地要件を確認する必要があります。
産業現場では、電源入力、筐体の設置、環境要件も確認してください。「産業用グレード」という言葉から、すべての製品が同じ耐雷保護レベルや温度範囲を備えていると推測することはできません。保守時には、自分の判断でカバーを開けたり、用途不明の端子を短絡させたりしないでください。ループバック試験には、対応するインターフェースで認められた方法を使用する必要があります。特に、RS232の試験配線をRS485バスに適用しないでください。
6.内部経路に沿って問題を特定する
ネットワーク接続に失敗した場合は、まずアドレス、ポート、役割、アクセスポリシーを確認してください。ネットワーク接続には成功しているのにシリアル応答がない場合は、要求がシリアル出力まで到達しているかを確認し、その後、インターフェース、配線、フォーマット、計測器の局番を検証してください。応答バイトは確認できても読み取り値が誤っている場合は、生のメッセージを保存し、解析規則、スケーリング、バイト順を確認してください。
試験では、まず短いケーブルと正常動作が確認済みの端末1台を使用し、一度に変更する条件は1つだけにして、シリアル側とネットワーク側の両方のカウントを記録してください。その後、負荷を徐々に増やし、連続動作と切断からの復旧を確認します。制御サービスでは、タイムアウト後のコマンドの状態も確認し、再送をあらゆる障害に対する万能な解決策として扱わないでください。
7.具体的な製品で機能を確認する
飛暢科技のFCT-1500シリーズの詳細には、RS232/422/485インターフェース構成、仮想シリアルポート、TCP Server/Clientモードが記載されており、分散した端末をネットワーク化するための機種選定の参考にできます。該当シリーズで提供される光ポート構成は、遠隔ネットワーク伝送に使用できますが、シリアルインターフェースの種類とプロトコル変換機能については、注文した機種と有効なモードに従って確認する必要があります。
機種を選定する際は、まずインターフェース数、電気規格、アプリケーションプロトコル、ソフトウェアのアクセス方式を列挙し、その後、管理機能と診断機能を検討してください。既存の端末を継続使用すれば改修作業を減らせますが、互換性試験は省略できません。ハードウェア、電気的な信号形式、サービスプロトコルを分けて考えることで、初心者でも「接続できる」「バイトを受信できる」「サービスが正しく動作する」がそれぞれ異なる判断である理由を理解しやすくなります。
参考資料:IETF TCP仕様;飛暢科技 FCT-1500シリーズの詳細。図は一般的な原理図であり、実際の製品や測定結果を示すものではありません。
中国語の技術記事から翻訳。原文の初公開日:2022-04-26。原文の最終改訂日時:2026-10-13T20:24:48+08:00。 中国語の原文を読む


