はじめに

範囲は

この文書の範囲は、TCP/IP上のMODBUSメッセージングサービスを紹介し、ソフトウェア開発者がこのサービスを使用するのに役立つ参照情報を提供することです。この文書にはMODBUS関数コードの符号化は含まれていません。MODBUSプロトコル仕様[2]を参照してください。

この文書は、MODBUSメッセージ転送サービスの実装を正確かつ包括的に記述しています。その目的は、MODBUSメッセージングサービスを使用するデバイス間の相互運用性を容易にすることです。

この文書は主に3つの部分から構成される。

• TCP/IP上のMODBUSプロトコルの概要
• MODBUSクライアント、サーバー、ゲートウェイツールの機能説明
• MODBUS実装インスタンスのターゲットモデルの推奨実装ガイドライン。

クライアント/サーバモデル

MODBUSメッセージングサービスは、イーサネットTCP/IPネットワークに接続されたデバイス間のクライアント/サーバ通信を提供します。

このクライアント/サーバモデルは、4種類のメッセージに基づいています。

• MODBUSリクエスト
• Modbusの確認
• MODBUS 指示
• Modbusの応答

MODBUSリクエストは、クライアントがトランザクションを開始するためにネットワーク上で送信するメッセージです。

MODBUSは、サーバが受信したリクエストメッセージです。

MODBUSレスポンスは、サーバーから送信されるレスポンス情報です。

MODBUSは、クライアント側で受信した応答情報を確認する

MODBUS Message Transfer Service（クライアント/サーバモデル）は、リアルタイムの情報交換のためのものです。

• 2つのデバイスアプリケーション間
• デバイスアプリケーションと他のデバイス間
• HMI/SCADAアプリケーションとデバイス間
• 1台のPCとオンラインサービスを提供する1台のデバイスプログラム間

正規参照ファイル

この章では、このファイルの前に読みたいファイルのリストを示します。

[2]MODBUSプロトコル仕様

[4]RFC1122

略語の略

ADU--アプリケーションデータユニット

IETF-Internet Engineering Working Groupについて

IP- インターネットプロトコル

MAC- メディアアクセス制御

MB-- MODBUS

MBAPMODBUSプロトコル

PDUプロトコルデータユニット

PLCプログラマブル·ロジック·コントローラ

TCP- 伝送制御プロトコル

BSDバークレーのソフトウェアディストリビューション

MSL- 最大寿命。

背景の概要

プロトコルの説明

一般的な通信構造

MODBUS TCP/IP通信システムには、さまざまな種類のデバイスが含まれます。

• TCP/IPネットワークに接続されたMODBUS TCP/IPクライアントおよびサーバ·デバイス
• 相互接続デバイス：TCP/IPネットワークとシリアルリンクサブネット間を相互接続するブリッジ、ルータ、ゲートウェイなど、MODBUSシリアルリンククライアントとサーバエンドデバイスを接続できるようにする接続。

図1：MODBUS TCP/IP通信

MODBUSプロトコルは、基礎となる通信層とは無関係なプロトコルを定義する。簡易プロトコルデータユニットPDU。特定のバスまたはネットワーク上のMODBUSプロトコルマッピングはアプリケーション·データ·ユニットADUいくつかの追加領域を導入する。

図2：汎用MODBUSフレーム

MODBUSトランザクションを開始するクライアントは、MODBUSアプリケーションデータユニットを確立する。この関数コードは、実行するアクションの種類をサーバに指示します。

TCP/IP上のMODBUS Application Data Unit

このセクションでは、MODBUS TCP/IPネットワークで行われるMODBUSリクエストまたはレスポンスのカプセル化について説明します。

図3：TCP/IP上のMODBUSの要求/応答

TCP/IP上のMODBUSアプリケーションデータユニットは、専用のヘッダを使用して識別されます。このヘッダをMBAPヘッダ（MODBUSプロトコルヘッダ）と呼ぶ.

このヘッダは、シリアルリンク上で使用されるMODBUS RTUアプリケーションデータユニットと比較していくつかの違いを提供します。

• MODBUSシリアルリンクで一般的に使用されるMODBUSスレーブアドレスフィールドを、MBAPヘッダ内の1バイト単位識別子に置き換えます。このユニット識別子は、ブリッジ、ルータ、ゲートウェイなど、単一のIPアドレスを使用して複数の独立したMODBUSエンドポイントユニットをサポートするデバイスの通信に使用されます。
• 受信者がメッセージの完了を検証できるように、すべてのMODBUSリクエストとレスポンスを設計します。MODBUS PDUの固定長機能コードの場合は、機能コードだけで十分です。リクエストまたはレスポンスで可変データを運ぶ関数コードの場合、データフィールドはバイト数を含む。
• MODBUSをTCP上で運ぶ場合、メッセージを複数のパケットに分割して送信しても、受信者がメッセージ境界を認識できるようにMBAPヘッダに追加の長さ情報を運ぶ。明示的および暗黙的な長さ規則の存在とCRC-32エラーチェックコードの使用（イーサネット上で）は、リクエストまたはレスポンスのメッセージに検出されない干渉を最小限に抑えます。

MBAPヘッダの説明

MBAPヘッダには以下のフィールドが含まれる。

ヘッダは7バイト長です。

取引子取引ペアで使用します。応答では、MODBUSサーバは要求のトランザクション識別子を複製します。

プロトコル識別子：システム内の多重化に使用されます。MODBUSプロトコルは、値0で識別されます。

長さ：長さフィールドは、セル識別子とデータフィールドを含む、次のフィールドのバイト数です。

セル識別子：システム内ルーティングのためにこのドメインを使用する.イーサネットTCP-IPネットワークとMODBUSシリアルリンク間のゲートウェイを介したMODBUSまたはMODBUS+シリアルリンクスレーブ間の通信に特化しています。MODBUSクライアントはリクエストでこのフィールドを設定し、サーバはレスポンスで同じ値を返しなければなりません。

すべてのMODBUS/TCP ADUを登録されたポート502でTCPを利用して送信する.

注：異なるドメインはビッグエンディアンでエンコードされます。

MODBUS関数コードの説明

MODBUSアプリケーション層プロトコルで使用される標準機能コードは、MODBUSプロトコル仕様[2]に詳細に記載されています。

機能の説明

MODBUSコンポーネント構造は、MODBUSクライアントとMODBUSサーバーコンポーネントの両方を含む汎用モデルであり、あらゆるデバイスに適用できます。

一部のデバイスは、サーバーまたはクライアントコンポーネントのみを提供します。

この章の最初の部分では、MODBUSメッセージ転送サービスコンポーネントの構造の概要を説明し、次に構造モデル内の各コンポーネントの説明を提供します。

MODBUSアセンブリ構造モデル

図4 Modbusメッセージ転送サービスの概念構造

• 通信アプリケーション層

MODBUSデバイスは、クライアントおよび/またはサーバー MODBUSインターフェイスを提供することができる。

MODBUSバックエンドインターフェイスを提供し、ユーザーアプリケーションオブジェクトへの間接アクセスを可能にします。

このインタフェースは、ディスクリート入力、ディスクリート出力（コイル）、レジスタ入力、レジスタ出力の4つの部分で構成されています。このインターフェイスとユーザーアプリケーションデータのマッピングを定義する必要があります（地域の問題）。

• MODBUSクライアント

MODBUSクライアントを使用すると、ユーザアプリケーションはリモートデバイスとの情報交換を明確に制御できます。MODBUSクライアントは、ユーザーアプリケーションからMODBUSクライアントインターフェイスに送信された要求に含まれるパラメータに基づいてMODBUSリクエストを生成します。

MODBUSクライアントはMODBUSトランザクションを呼び出し、トランザクション管理にはMODBUS検証の待機と処理が含まれます。

• MODBUSクライアント·インタフェース

MODBUSクライアントインターフェイスは、ユーザーアプリケーションがMODBUSアプリケーションオブジェクトへのアクセスを含む様々なMODBUSサービスへのリクエストを生成できるようにするインターフェイスを提供します。実装モデルにおいて例を示すが、MODBUSクライアントインタフェースAPIはここではしない。

• MODBUSサーバ

MODBUSリクエストを受信すると、モジュールは読み取り、書き込み、またはその他のアクションを実行するローカルアクションを有効にします。これらの操作の処理はアプリケーション開発者に透過的です。MODBUSサーバの主な機能は、TCP502ポートからのMODBUSリクエストを待ち、リクエストを処理し、デバイスの状況（フィールド）に応じてMODBUSレスポンスを生成することです。

• MODBUSバックグラウンド·インタフェース

MODBUSバックエンドインターフェイスは、MODBUSサーバーからアプリケーションオブジェクトを定義するユーザーアプリケーションへのインターフェイスです。

• TCP管理層

メッセージングサービスの主な機能の1つは、トラフィックの確立と終了を管理し、TCPコネクション上で確立されたデータフローを管理することです。

• 接続の管理

クライアントとサーバのMODBUSモジュール間の通信には、TCPコネクション管理モジュールの呼び出しが必要です。メッセージ転送TCPコネクションの全体的な管理を担当します。

コネクション管理には、ユーザアプリケーション自身がTCPコネクションを管理するか、ユーザアプリケーションに透過的に接続を管理するモジュールがすべて接続管理を行う2つの可能性があります。後者のプログラムは柔軟性が低い。

TCP 502ポートのリッスンはMODBUSトラフィック用に予約されている。デフォルトでは、この口は強制的にリッスンされます。しかし、市場やアプリケーションによっては、TCP上のMODBUS通信用に追加のポートが必要です。これは、シュナイダー以外の製品との相互運用が必要な場合に該当します。たとえば、ビル制御などです。この目的のために、クライアントとサーバの両方が、TCPスローガンのMODBUSパラメータを設定する可能性をユーザに提供することを強く推奨します。重要なことは、特定のアプリケーションでMODBUSサービス用に追加のTCPサーバポートが設定されている場合でも、TCPサーバポート502は、いくつかの特定のアプリケーションポートを除いて利用可能である必要があることです。

• アクセス制御モジュール

重要な場合には、不要なホストからデバイス内部データへのアクセスを禁止する必要があります。これは、セキュアモードが必要な理由であり、必要に応じてセキュアな処理を実装する理由です。

• TCP/IPスタック層

TCP/IPスタックは、データフロー制御、アドレス管理、およびコネクション管理を特定の製品やシステムのさまざまな制約に適応させるためにパラメータ設定することができます。一般的に、BSDソケットインタフェースはTCPコネクションの管理に使用されます。

• リソース管理とデータフロー制御

MODBUSクライアントとサーバ間のメッセージ転送に出入りするデータフローのバランスをとるために、MODBUSメッセージ転送スタックのすべての層にデータフロー制御機構が設けられています。リソース管理とデータフロー制御モジュールは、まずTCP内部データフロー制御、追加データリンク層の一部のデータフロー制御、およびユーザーアプリケーション層のデータフロー制御に基づいています。

TCP接続管理

接続管理モジュール

全体的な説明

MODBUS通信には、クライアントとサーバ間のTCP接続の確立が必要です。

接続の確立は、ユーザアプリケーションモジュールが直接実現するか、TCP接続管理モジュールが自動的に実現することができます。

最初のケースでは、ユーザーアプリケーションモジュールは、接続を完全に管理するためのアプリケーションプログラムインタフェースを提供する必要があります。このアプローチはアプリケーション開発者に柔軟性を提供しますが、TCP/IPメカニズムの専門知識が必要です。

2つ目のシナリオでは、TCPコネクション管理は完全に存在せず、ユーザアプリケーションはModBUSメッセージを送受信するだけで済みます。TCPコネクション管理モジュールは、必要に応じて新しいTCPコネクションを確立する責任がある。

TCPクライアントとサーバの接続数の定義は、この文書の範囲外である（この文書ではnを使用する）。TCP接続の数は、デバイスの能力によって異なります。

ルールの実装：

• 明確なユーザー要件がない場合は、TCP接続の自動管理を推奨します。
• 推奨MODBUS/TCPトランザクションが処理されるたびに接続を開閉するのではなく、リモートデバイスへの接続を開いて維持します。注意：ただし、MODBUSクライアントはサーバーからのシャットダウン要求を受信し、接続をシャットダウンできる必要があります。接続は必要に応じて再開できます。
• 推奨事項：各MODBUSクライアントは、リモートMODBUSサーバへの少なくともTCP接続を開く必要があります。（同じIPアドレスです。接続を確立するアプリケーションは良い選択です。
• 複数のMODBUSトランザクションを同じTCPコネクション上で同時に有効にすることができます注：この方法では、MODBUSトランザクション識別子を使用してリクエストとレスポンスの一致を一意に識別する必要があります。
• 2つのリモートMODBUSデバイス（1つのクライアントと1つのサーバ）間の双方向通信の場合、クライアントデータフローとサーバデータフローを別々に接続する必要があります。
• TCPフレームは1つのMODBUS ADUしか送信できません。推奨：同じTCP PDU内で複数のリクエストやレスポンスを送信しないでください。

図7：TCPコネクション管理の動作図

1.明示的なTCP接続管理

ユーザアプリケーションモジュールは、すべてのTCP接続を管理します。アクティブおよびパッシブ接続確立、接続終了（PDCP）です。この管理はクライアントとサーバ間のすべての接続を管理する. BSDソケットインタフェースはユーザアプリケーションモジュールでTCPコネクションを管理するために使用される。このソリューションは完全な柔軟性を提供しますが、アプリケーション開発者はTCPに関する十分な知識を持つ必要があります。

デバイスの機能と要件を考慮すると、クライアントとサーバ間の接続数の制限を設定する必要があります。

2. TCP接続の自動管理

TCPコネクション管理は、ユーザアプリケーションモジュールから完全に透過的です。接続管理モジュールは、十分な数のクライアント/サーバ接続を受け入れることができる。それ以外の場合は、許可された接続数を超えた場合に実装メカニズムが必要です。この場合、以下をお勧めします。最も古い未使用の接続を閉じます。

リモートクライアントまたはローカルユーザアプリケーションからの最初のパケットを受信した後、リモートオブジェクトへの接続が確立されます。ネットワークが終了するか、ローカルデバイスが終了すると、この接続は閉じられます。アクセス制御オプションは、接続要求を受信する際に、不正な顧客がデバイスにアクセスする可能性を禁止するために使用できます。

TCPコネクション管理モジュールは、TCP/IPスタックと通信するためにスタックインタフェース（通常はBSDソケットインタフェース）を使用します。

システム要件とサーバリソース間の互換性を維持するために、TCP管理は両方の接続を維持します。図書館内で。

• 最初のもの。図書館内で（優先リンク）図書館内でローカルでアクティブに閉じられない接続で構成されます。このライブラリを構築するための設定が必要です。実装の原理は、このライブラリへの可能なすべての接続を特定のIPアドレスに関連付けることです。このIPアドレスを持つデバイスは“タグ付け”と呼ばれます。“タグ付けされた”デバイスからの新しい接続要求を受信し、優先接続ライブラリから取り出す必要があります。また、同じデバイスが優先接続ライブラリ内のすべての接続を使用しないように、各リモートデバイスが確立できる接続の最大数を設定する必要があります。
• 2番目のライブラリ（非優先接続ライブラリ）には、ラベルなしデバイスへの接続が含まれます。ここで採用されているルールは、タグ付けされていないデバイスからの新しい接続要求があり、ライブラリで接続が利用できない場合、以前に確立された接続を閉じることです。

各ライブラリで利用可能な接続数を割り当てるための構成をオプションとして提供できます。ただし（必須ではありません）、設計者は必要に応じて設計中に接続数を設定できます。

接続管理の説明

• 接続の確立

MODBUSメッセージ転送サービスは、新しい接続を受信し、他のデバイスとデータを交換できるようにポート502にリッスンソケットを提供する必要があります。

メッセージングサービスがリモートサーバとデータを交換する必要がある場合、リモートサーバとデータを交換するために、リモート502との新しいクライアント接続を確立する必要があります。ローカルポートは1024以上でなければならず、顧客接続ごとに異なります。

図8：MODBUS TCP/IP接続の確立

クライアントからサーバへの接続数が承認された接続数よりも多い場合、最も古い未使用の接続は閉じられます。リモートクライアントのIPアドレスが承認されているかどうかをチェックするアクセス制御メカニズムの有効化。許可されていない場合、新しい接続は拒否されます。

• MODBUSデータ変換

開いている正しいTCPコネクションに基づいてMODBUSリクエストを送信する。リモートデバイスのIPアドレスは、確立されたTCPコネクションを見つけるために使用されます。同じリモートデバイスへの複数の接続を確立する場合、MODBUSメッセージを送信するために接続の1つを選択する必要があります。最初の接続、最初の接続など、異なる選択ポリシーが適用されます。MODBUS通信中、接続は常に開いている必要があります。次の章で説明するように、クライアントはプリアントランザクションの終了を待つことなく、1つのサーバに対して複数のトランザクションを開始できます。

• 接続は閉じた。

クライアントとサーバ間のMODBUS通信が終了すると，クライアントは通信のための接続を閉じなければならない.

TCP接続に対する動作モードの影響

一部の動作モード（2つの動作エンドポイント間の通信の切断、1つのエンドポイントの障害と再起動、）は、TCP接続に影響を与えます。接続は、反対側からの確認なしに片側で閉じたり異常に終了したりすると考えることができ、“半オープン”接続と呼ばれます。

この章では、主な動作モードごとにプロパティ。接続の両端にあると仮定します。接続を維持する。TCPのメカニズム。

2つのオペレータ間の通信切断

通信切断の原因として、サーバ側のEthernet接続ケーブルの切断が考えられます。期待される。プロパティそうです：

• 接続上で送信中のパケットがない場合：

通信の中断時間が短い場合接続を維持する。通信切断が検出されないようにするタイマーの値。通信が切れた場合>>接続を維持する。”のタイマーの値。エラーをTCP接続层に返し、接続をリセットする。

• 切断の前後にいくつかのパケットを送信した場合：

TCP再送信アルゴリズムJacobsonアルゴリズム、Karnアルゴリズム、および指数補償アルゴリズムが活性化される。それはおそらくそれにつながる”接続を維持する。”タイマが終了する前にTCPスタック接続層がリセットされます。

サーバ侧の障害と再

サーバ障害および再の后、クライアントは“半开いた”接続です。期待される。プロパティそうです：

• 半オープン接続でパケットが送信されない場合：

“Keep Connection”タイマがまだタイミング中である限り、クライアント側から見ると、接続は半分は開いてます。その後、TCP管理層にエラーが返され、コネクションがリセットされます。

• 半オープン接続でパケットを送信する場合：

サーバは存在しない接続でデータを受信します。TCP層のスタックはリセットを送信する命令はクライアントの半開いた接続を閉じます。

クライアント侧の障害と再

クライアント障害および再の后、サーバ侧は“半开いた”接続です。期待される。の状態です。そうです：

• 半オープン接続でパケットが送信されない場合：

限り”。接続を維持する。”タイマーはまだタイミング中であり、サーバー側から見ると、この接続は半分は開いてます。その後、TCP管理層にエラーが返され、コネクションがリセットされます。

• もしそこにいたら”接続を維持する。”タイマーがタイミングを完了する前に、クライアントは新しい接続を開きます。

2つのケーススタディが必要です。

• オープンされたコネクションは、サーバ側の半オープンなコネクションと同じ特性（同じソースと宛先、同じソースと宛先IPアドレス）を持つため、コネクション確立タイムアウト後（バークレーでは多くの場合75ms）、TCPスタック層はコネクションをオープンすることができない。長いタイムアウト時間の通信不能を避けるために、クライアントが再起動した後、元の接続とは異なるソーススローガンで接続を確立することをお勧めします。
• 開いたコネクションは，サーバ側の半開いたコネクションとは異なる特性（異なるソースと同じ宛先，同じソースと宛先IPアドレス）を持つため，TCPスタック層でコネクションを開き，サーバ側のTCP管理層に信号を送信する.

サーバ側TCP管理層がリモートクライアントIPアドレスを持つ接続のみをサポートしている場合、元の半オープン接続を閉じて新しい接続を使用することができます。

サーバ側TCP管理層が複数のリモートクライアントIPアドレスを持つ接続をサポートしている場合、新しい接続は開いたままであり、元の接続も半開いたままである。接続を維持する。タイマーが終了し、TCP管理層にエラーが返されます。その後、TCP管理者は元のコネクションをリセットできます。

アクセス制御モジュール

このモジュールの目的は、リモートクライアントへのTCP接続を許可または禁止できる正当に許可されたリモートIPアドレスのリストをチェックすることです。

極めて重要なことです機会に。アプリケーション開発者は、ネットワークへのアクセスを保証するアクセス制御モジュールを選択する必要があります。この場合、リモートIPごとにアクセスを許可または禁止する必要があります。ユーザーはIPアドレスのリストを提供し、各IPアドレスが正当に許可されているかどうかを明記します。デフォルトでは、ユーザーが設定していないIPアドレスはセーフモードで禁止されます。したがって、アクセス制御モードを使用して、未知のIPアドレスからのアクセス接続を閉じます。

TCP/IPスタックの使用

TCP/IPスタックは、接続、データの送受信を管理するためのインターフェイスを提供し、スタックを有効にするためのパラメータ設定も可能です。性格は不明。機器やシステムの制約に適応する。

この章の目的は、スタックインターフェイスの概要と、スタックのパラメータ設定に関するいくつかの情報を提供することです。割り当て概要は主にMODBUSメッセージ転送で使用される機能の一部です。

詳細については、インターネット通信ソフトウェアのベンダーと開発者のためのガイダンスを提供するRFC 112 2をお読みください。RFC 112 2は、インターネットに接続するホストが採用すべき標準プロトコルと、明確な要件とオプションのセットを詳述しています。

スタックインターフェイスは、一般的にこの文書で説明するBSDインタフェースに基づいています。

BSDソケットインタフェースの応用

注：いくつかのTCP/IPスタックはパフォーマンス上の考慮から他のタイプのインタフェースを提案する。MODBUSクライアントまたはサーバはこれらの特定のインターフェイスを使用できますが、この文書ではその使用については説明しません。

ソケットは通信のエンドポイントであり、通信の基本的な構成要素である。MODBUS通信は、ソケットを介したデータ送受信が可能です。TCO/IPライブラリは、TCPを使用し、接続ベースの通信サービスを提供するストリームソケットのみを提供します。

socket関数は、ソケットを作成するために使用します。返されるソケット番号は、作成者がソケットにアクセスするために使用します。ソケットはアドレス（IPアドレスとスローガン）なしで作成されます。ポートがソケットにバインドされるまで、データは受信できません。

bind関数は、スローガンをソケットにバインドするために使用します。bind関数は、ソケットと指定されたスローガン間の接続を確立します。

接続を初期化するには、クライアントはconnect関数を送信して、ソケット番号、リモートIPアドレス、およびリモートリスニング·スローガンを指定する必要があります。

接続を完了するには、サーバ側では、listen呼び出しで指定したソケット番号を指定するaccept関数を送信する必要がありますパッシブ接続確立。新しいソケットが作成され、元と同じ機能を持ちます。この新しいソケットはクライアントのソケットに接続し、ソケット番号をサーバー側に返します。したがって、初期ソケットはサーバに接続したい他のクライアントが使用できるように解放されます。

TCPコネクションが確立されると、データを渡すことができます。Send関数とrecv関数は、接続されたソケットで使用するように特別に設計されています。

setsockopt関数を使用すると、ソケットの作成者はソケットにいくつかのオプションを設定できます。これらのオプションは、ソケットの動作特性を記述します。

select関数を使用すると、プログラマはすべてのソケットでイベントをテストできます。

shutdown関数を使用すると、ソケットのコンシューマがsendやrecvを終了できます。

ソケットが不要になったら、close関数を使用してソケットの記述情報を破棄できます。

図9：Modbus情報交換

上の図は、クライアントとサーバ間の完全なMODBUS通信プロセスを示しています。クライアントは接続を確立し、最初のリクエストへの応答を待たずに3つのMODBUSリクエストをサーバに送信します。すべての応答を受信した後、クライアントは通常通り接続を閉じます。

TCPレイヤ·パラメータ設定{{TCPれいやぱらめーたせってい}}

TCP/IPスタックのいくつかのパラメータは、製品またはシステムの制限に適合するように調整することができます。TCP層の以下のパラメータは調整できます。

• 各接続のパラメータ

SO-RCVBUF, SO-SNDBUF:

これらのパラメータにより、送受信ソケットインタフェースに高いリミットを設定できます。これらのパラメータを調整することでトラフィック制御管理を実現できます。受信バッファのサイズは、各接続の広告ウィンドウの最大値です。パフォーマンスを向上させるためには、ソケットキャッシュのサイズを大きくする必要があります。それ以外の場合は、内蔵ドライブのリソースが枯渇する前にTCPウィンドウを閉じるために、これらの値は内蔵ドライブのリソースよりも小さくなければなりません。

受信バッファのサイズは、TCPウィンドウサイズ、TCP最大セグメントのサイズ、入力フレームの受信にかかる時間によって異なります。最大セグメントサイズは300ワードであるため（MODBUSリクエストには最大256ワード+MBAPヘッダが必要）、キャッシュに3フレームが必要な場合はソケットキャッシュサイズを900ワードに変更できます。最大のキャッシュ要件とスケジュールされた時間を満たすために、TCPウィンドウサイズを大きくすることができます。

TCP-NODELAY:

通常、ローカルエリアネットワーク（LAN）上の小さなパケット（tinygramsと呼ばれる）の転送は、ほとんどのローカルエリアネットワークが輻輳していないため問題になりませんが、これらのtinygramsはワイドエリアネットワーク上で輻輳を引き起こします。“NAGLEアルゴリズム”と呼ばれる単純なスキームは、少量のデータを収集し、前のメッセージのTCP応答が到着したときに送信するものです。

より良いリアルタイム機能を得るには、少量のデータをセグメントに収集して送信しようとするのではなく、直接送信することをお勧めします。このため、クライアントとサーバの接続の“NAGLEアルゴリズム”を無効にするTCP-NODELAYオプションを強制することをお勧めします。

SO-REUSEADDR:

MODBUSサーバがリモートクライアントによって開始されたTCPコネクションをシャットダウンすると、コネクションが“待機時間”状態（2つのMSL：Maximum Segment Life-）にある間、そのコネクションで使用されているローカルスローガンを使用して新しいコネクションを開くことはできません。

推奨：クライアントとサーバーの接続ごとに、SO-REUSEADDRオプションを指定して、この制限を回避します。このオプションを使用すると、接続の一部として2MSL期間中、クライアントを待機し、ソケットインタフェースをリッスンするスローガンを自身に割り当てることができます。

SO-KEEPALIVE:

TCP/IPプロトコルデフォルトでは、空きTCP接続を介してデータを送信しません。したがって、このプロセスがTCPコネクション側でデータを送信しない場合、2つのTCPモジュール間でデータが交換されることはありません。これは、クライアントサイドアプリケーションとサーバーサイドアプリケーションの両方がカウンタを使用して接続の生存性を検出し、接続を閉じると仮定します。

推奨：クライアントとサーバの接続の両端でKEEPALIVEオプションを使用して、相手が障害を起こして死んだか、障害を起こして再起動したかを確認できます。

ただし、KEEPALIVEを使用すると、非常に良好な接続が発生し、瞬時の障害時に通信が中断され、接続タイマのタイミング期間が短すぎると不要なネットワーク帯域幅が消費される可能性があることに留意する必要があります。

• TCPレイヤ全体のパラメータ

TCP接続確立タイムアウト

バークレーのほとんどのシステムでは、新しい接続の確立時間を75秒に設定しており、これはリアルタイムアプリケーションの制限に対応するデフォルト値です。

接続パラメータの保持

接続のデフォルトアイドル時間は2時間です。このアイドル時間を超えると、Keep接続試行がトリガーされます。最初のホールド接続試行の後、試行に対する応答が受信されるまで、最大回数で75秒ごとに試行を送信します。

アイドル接続でホールド接続試行を発行できる最大数は8回です。最大試行回数の試行後に応答がない場合、TCPはアプリケーションにエラーシグナルを送信し、アプリケーションがコネクションを閉じることを決定するために使用します。

タイムアウトおよび再送パラメータ

TCPパケットの損失が検出されると、そのパケットは再送信されます。損失を検出する方法の1つは、再送タイムアウトRTOを管理することであり、リモートからの確認応答が受信されなければ、タイムアウトは終了する。

TCPはRTOの動的評価を行う.このために、再送されていないパケットの送信後にラウンドトリップタイム（RTT）を測定する。ラウンドトリップ時間（RTT）は、パケットがリモートデバイスに到着し、リモートデバイスから確認応答を取得するのにかかる時間です。コネクションのラウンドトリップ時間は動的に計算されますが、TCPが3秒以内にRTTの推定値を取得できない場合、RTTのデフォルト値は3秒に設定されます。

RTOが推定されている場合は、次のメッセージ送信に使用されます。推定RTOが終了する前に次のメッセージの確認が受信されない場合、有効化インデックス補償Algorithm特定の期間内に許可される同じメッセージの最大再送回数。その後，確認が届かなければ接続は終了する.

一部のスタックでは、接続が終了するまでの再送の最大回数と再送の最大時間を設定できます。

TCP標準ではいくつかの再送信アルゴリズムが定義されている。

• ジェイコブソンのRTO推定再送信タイムアウトRTOの推定に使用されます。
• Karnのアルゴリズム再送信セグメントではRTO推定を行うべきではない。
• 指数補償アルゴリズム定義：64秒の制限時間内の各再送信に対して、再送信タイムアウトを倍増させます。
• 高速再送信アルゴリズム3回の重複確認を受信した後に再送信が許可されます。LAN上では、RTOの終了を待つよりもパケット損失の検出が速くなる可能性があるため、このアルゴリズムを検討する。

MODBUSの実装では、これらのアルゴリズムを推奨します。

IP層のパラメータ設定

IPパラメータ

以下のパラメータは、MODBUS実装のIP層で設定する必要があります。

• ローカルIPアドレス：IPアドレスは、クラスA、B、またはCのいずれかです。
• サブネットマスク：IPネットワークは、異なる物理メディア（イーサネット、ワイドエリアネットワークなど）の使用、ネットワークアドレスのより効率的な使用、ネットワークトラフィックの制御など、さまざまな理由でサブネットに分割されます。サブネットマスクは、ローカルIPアドレスのタイプと一致する必要があります。
• デフォルトゲートウェイ：デフォルトゲートウェイのIPアドレスは、ローカルIPアドレスと同じサブネット内にある必要があります。0.0.0.0の値は禁止されている。ゲートウェイが定義されていない場合、この値は127.0.0.1またはローカルIPアドレスに設定できます。

ニュース：Modbus新聞トランスポーテーションサービスはIP層でセグメント機能を要求しない.

ローカルIP側は、ローカルIPアドレス、サブネットマスク、および（0.0.0.0とは異なる）欠落ゲートウェイで構成する必要があります。

通信アプリケーション層

MODBUSクライアント

図10 MODBUSクライアント

MODBUSクライアント設計

MODBUS/TCPプロトコルは、クライアントの簡単な設計を可能にします。次の図は、クライアントがMODBUS要求を送信し、MODBUS応答を処理する主な処理を示しています。

図11：MODBUSクライアントの動作図

MODBUSクライアントは3種類のイベントを受信できます。

• ユーザーアプリケーションからリクエストを送信する新しい要件。この場合、MODBUSリクエストをエンコードし、TCP Management Component Serviceを使用してネットワーク経由で送信する必要があります。下位層（TCP管理モジュール）は、TCPコネクションエラーまたはその他のエラーメッセージに起因するエラーメッセージを返します。
• TCP管理からのレスポンス。この場合、クライアントはレスポンスの内容を分析し、ユーザアプリケーションに確認を送信する必要があります。
• 応答がないためタイムアウト終了。ネットワーク経由で再試行メッセージを送信するか、否定的な確認をユーザーアプリケーションに送信することができます。

注：これらの再試行はMODBUSクライアントによって開始され、TCP確認なしでTCP層によって他の種類の再試行を実行できます。

MODBUSリクエストの生成

ユーザアプリケーションからリクエストを受信した後、クライアントはMODBUSリクエストを生成し、TCP管理者に送信する必要があります。

MODBUSリクエストの生成は、いくつかのサブタスクに分割できます。

• MODBUSトランザクションのインスタンス化により、クライアントは対応するリクエストとレスポンスを照合し、ユーザーアプリケーションに確認を送信するために必要なすべての情報を格納できます。
• MODBUSリクエスト（PDU+MPABヘッダ）のエンコード。要求を開始するユーザアプリケーションは、クライアントが要求をエンコードできるように、必要なすべての情報を提供する必要があります。MODBUS PDUは、MODBUSプロトコルに従って符号化されます（MODBUS関数コード、関連パラメータ、アプリケーションデータ[2]）。MBAPヘッダーのすべてのフィールドを埋める。そして、MBAPヘッダをプレフィックスとしてMODBUS要求ADUを生成する。
• MODBUSリクエストADUをTCP管理モジュールに送信します。TCP管理モジュールは、リモートサーバから正しいTCPソケットを検索します。MODBUS ADUに加えて、宛先IPアドレスを渡す必要があります。

以下の図は、図17よりもリクエスト生成のプロセスを詳しく示しています。

図12：要求生成操作の概略図

以下の例は次のとおりです。アドレス0 5のリモートサーバから1ワードを読み取るMODBUSリクエストADUエンコーディング。

• MODBUSはADUエンコーディングを要求します。

（*）MODBUSプロトコル仕様[2]を参照。

• 取引子

トランザクション識別子は、要求と将来の応答を関連付けるために使用されます。したがって、TCPコネクションでは、この識別子は同時に一意でなければなりません。この識別子の使用方法はいくつかあります。

• 例えば、リクエストごとにカウンタをインクリメントするカウンタ付きの単純な“TCPシーケンス番号”として使用できます。
• また、現在のリモートサーバと未処理のリクエストを記憶するために、トランザクションの内容を識別するスマートインデックスまたはポインタとしても使用できます。

通常、MODBUSシリアルリンクでは、クライアントは一度に1つのリクエストを送信しなければなりません。つまり、クライアントは2番目のリクエストを送信する前に最初のリクエストへの応答を待つ必要があります。MODBUS TCPでは、サーバからの確認を待たずに同じサーバに複数のリクエストを送信できます。MODBUS/TCPとMODBUSシリアルリンク間のゲートウェイは、これら2つの動作間の互換性を保証します。

サーバが受信するリクエストの数は、サーバの容量、すなわちサーバリソースの量とTCPウィンドウサイズによって異なります。同様に、クライアントが同時に開始するトランザクションの数も、クライアントのリソース容量によって異なります。この実装パラメータは“NnmberMax of ClientTransaction”と呼ばれ、MODBUSクライアントの機能として記述する必要があります。デバイスの種類に応じて、このパラメータの値は1~16です。

• ユニット識別子

MODBUSまたはMODBUS+シリアルリンクサブネットでデバイスをアドレス指定する場合、このドメインはルーティング目的で使用されます。この場合、“Unit Identifier”はリモートデバイスのMODBUSスレーブアドレスを運びます。

- MODBUSサーバがMODBUS+またはMODBUSシリアルリンクサブネットに接続され、ブリッジまたはゲートウェイを介してこのサーバのアドレスを設定する場合、ブリッジまたはゲートウェイの背後にあるサブネットに接続されているスレーブデバイスを識別するためにMODBUSユニット識別子が必要です。宛先IPアドレスはブリッジ自体のアドレスを識別し、ブリッジはMODBUSユニット識別子を使用して正しいスレーブデバイスに要求を転送します。

- 割り当てられたシリアルリンク上のMODBUSスレーブデバイスアドレスは1~247（10進）で、アドレス0はブロードキャストアドレスとして使用されます。

TCP/IPでは、IPアドレスはMODBUSサーバのアドレス指定に使用されるため、MODBUSユニット識別子は役に立ちません。値は0 x FFです。

- TCP/IPネットワークに直接接続されているMODBUSサーバをアドレス指定する場合、“セル識別子”フィールドで有効なMODBUSスレーブアドレスを使用しないことをお勧めします。自動システムでIPアドレスが再割り当てされ、以前にMODBUSサーバに割り当てられていたIPアドレスがゲートウェイに割り当てられた場合、有効なスレーブアドレスを使用するとゲートウェイのルーティングがうまくいかないために問題が発生することがあります。無効なスレーブアドレスを使用すると、ゲートウェイは問題なくMODBUD PDUを単に破棄します。推奨：“ユニット識別子”の無効な値として0 x FFを使用してください。

注：0はMODBUS/TCPデバイスとの直接通信にも使用できます。

Modbusの確認

TCPコネクションでは、応答フレームが受信されると、MBAPヘッダ内のトランザクション識別子が応答をTCPコネクションに送信された元のリクエストに関連付けるために使用されます。

• トランザクション識別子が未解決のトランザクションを参照していない場合、応答は破棄されます。
• トランザクション識別子が未解決のトランザクションを参照する場合、応答は、MODBUS確認（肯定的または否定的確認）をユーザアプリケーションに送信するために分解されなければならない。

分解応答は、MBAPヘッダとMODBUS PDUをチェックする応答です。

• MBAPヘッダ

プロトコル識別子が0 x 0000であることを確認した後、長さはMODBUSレスポンスのサイズを与えます。

応答がTCP/IPネットワークに直接接続されているMODBUSサーバデバイスからの場合、TCPコネクション識別子はリモートサーバを明確に識別するのに十分です。したがって、MBAPヘッダに運ばれたセル識別子は無効であり、このセル識別子は破棄されなければならない。

リモートサーバがシリアルリンクサブネットに接続されており、応答がブリッジ、ルート、またはゲートウェイから来ている場合、セル識別子（値≠ 0 x FF）は、最初の応答を送信したリモートMODBUSサーバを識別します。

• MODBUS応答

関数コードを確認し、MODBUSプロトコルに従ってMODBUS応答フォーマットを分析する必要があります。

• 関数コードがリクエストで使用されているものと同じで、レスポンスの形式が正しい場合、MODBUSレスポンスが肯定的な確認としてユーザアプリケーションに発行されます。
• 関数コードがMODBUS例外コード（関数コード+80 H）の場合は、肯定的な確認として例外応答がユーザアプリケーションに発行されます。
• 関数コードがリクエストで使用されているものと異なる場合（=予期しない関数コード）、またはレスポンスの形式が間違っている場合は、否定の確認としてエラー信号がユーザーアプリケーションに送信されます。

注：肯定的な確認とは、サーバーが要求されたコマンドを受信し、応答したことを確認することです。サーバが要求されたコマンドで要求された操作を正常に実行できたことを意味するものではありません（MODBUS例外応答は実行に失敗したことを示します）。

以下の図は、図17よりも確認処理の手順を詳細に示している。

図13：MODBUS図

タイムアウト管理

MODBUS/TCP上のトランザクションに必要な応答時間は意図的に規定されていない.

これは、ミリ秒レベルのI/Oスキャンから数秒の遅延を伴う長距離無線リンクまで、MODBUS/TCPが可能な限り幅広い通信シナリオで使用されることが期待されているためです。

クライアントの観点からは、タイムアウトは、合理的な応答時間を決定するために、ネットワーク上で予想される転送遅延を考慮する必要があります。この転送遅延は、スイッチドイーサネットでは数ミリ秒、WAN接続では数百ミリ秒になります。

逆に、クライアントがアプリケーションを起動して再試行するタイムアウト時間は、予想される最大合理的な応答時間よりも大きい必要があります。これに従わなければ、ターゲットデバイスやネットワークが過密になり、エラーが増える可能性があります。これは常に避けるべき機能です。

したがって、実際には、高いパフォーマンスをアプリケーションで使用されるクライアントのタイムアウトは、常にネットワークトポロジと期待されるクライアントのパフォーマンスに関連しているように見えます。

タイムファクターが重要でないシステムでは、TCPデフォルト値をタイムアウト値として使用することが多く、ほとんどのプラットフォームでは数秒後に通信障害が報告されます。

MODBUSサーバ侧

図14：MODBUSサーバ侧

MODBUSサーバの役割は、アプリケーションオブジェクトへのアクセスとリモートクライアントへのサービスを提供することです。

ユーザーのアプリケーションに応じて、さまざまな種類のアクセスを提供します。

• 簡単なアクセス：アプリケーションオブジェクトのプロパティを取得または設定します。
• 高度なアクセス：特定のアプリケーションサービスを開始する

MODBUSサーバには、次の条件が必要です。

• アプリケーションオブジェクトのプロパティを取得または設定するために、アプリケーションオブジェクトを読み取りまたは書き込み可能なMODBUSオブジェクトにマッピングします。
• アプリケーションオブジェクトに対してサービスを開始する方法を提供する;

実行中、MODBUSサーバは受信したMODBUSリクエストを分析し、必要な操作を処理し、MODBUSレスポンスを返さなければならない。

MODBUSサーバ

MODBUSサーバの設計は、次の2つの側面に依存します。

• アプリケーションオブジェクトへのアクセスの種類（プロパティへの単純アクセスまたはサービスへの高度アクセス）;
• MODBUSサーバーとユーザーアプリケーション間の相互作用の種類（同期または非同期）。

以下の図は、TCP管理からMODBUSリクエストを取得し、リクエストを解析して必要なアクションを処理し、MODBUSレスポンスを返すためにサーバが行う主な処理を示しています。

図15：MODBUS命令の処理動作図

前の操作図に示すように：

• MODBUSサーバ自体は、ユーザアプリケーションとの相互作用なしに、一部のサービスを即座に処理できます。
• 一部のサービスは、処理されるユーザーアプリケーションとの明示的な相互作用を必要とする。
• 一部の高度なサービスは特定のインターフェイス、すなわちMODBUSバックエンドサービスを呼び出す必要があります。たとえば、ユーザーアプリケーション層プロトコルに従って、複数のMODBUSリクエスト/レスポンストランザクションのタイミングを使用してユーザーアプリケーションサービスを開始することができます。バックグラウンドサービスは、グローバルユーザーアプリケーションサービスの実行を容易にするために、すべての個々のMODBUSトランザクションを正しく実行する責任があります。

詳細は以下の章で説明します。

MODBUSサーバは、複数のMODBUSリクエストを同時に受信し、サービスを提供できます。サーバーが同時に受信できるMODBUSリクエストの最大数は、MODBUSサーバーの主な機能の1つです。この量は、サーバーの設計と処理能力とストレージ能力に依存します。この実装パラメータは“NumberMaxOfServerTransaction”と呼ばれ、MODBUSサーバの機能として記述されなければならない。デバイスの能力に応じて、その値の範囲は1 〜 16です。

“NumberMaxOfServerTransaction”パラメータは、MODBUSサーバーの動作とパフォーマンスに非常に大きな影響を与えます。特に重要なのは、管理される同時MODBUSトランザクションの数が、MODBUSリクエストに対するサーバーの応答時間に影響を与える可能性があることです。

MODBUS PDUの検証

次の図は、MODBUS PDUの確認操作を示しています。

図16：MODBUS PDUの確認操作のフローチャート

MODBUS PDU検証機能は、まずMBAPヘッダを分解する。プロトコル識別子ドメインを確認する必要があります

• MODBUSプロトコルタイプと異なる場合は、この指示を削除します。
• これが正しい場合（= MODBUSプロトコル型;値は0 x 0 0）、MODBUSトランザクションの例を即座に示します。

サーバーが指定できるMODBUSトランザクションの最大数は、パラメータ“NumberMaxOfTransaction”（システムまたは構成パラメータ）によって定義されます。

無効なトランザクションが発生した場合、サーバーはMODBUS例外応答を生成します（例外コード6：サーバーがビジー）。

トランザクションが有効な場合は、次の情報を格納するために開始されます。

• 指示を送信するために使用されるTCPコネクション識別子TCP Managementによって与えられる
• MODBUSトランザクションID（MBAPヘッダで与えられる）
• セル識別子（MBAPヘッダで与えられる）

次に，MODBUS PDUを分解する.まず、関数コードを分析する：

• 無効な場合、MODBUS例外応答を生成する（例外コード1：無効な機能）
• 関数コードを受信すると、サーバは“MODBUSサービス処理”操作を開始します。

MODBUSサービス処理

図17：MODBUSサービスフロー図

以下の例のデバイスソフトウェアとハードウェアアーキテクチャに応じて、要求されたMODBUSサービス処理はさまざまな方法で実行できます。

• 小型デバイスまたはシングルスレッドアーキテクチャ内では、MODBUSサーバはユーザアプリケーションデータに直接アクセスでき、サーバ自体はバックグラウンドサービスを呼び出すことなく要求されたサービスをローカルで処理できます。

この処理は、“MODBUSプロトコル仕様”に従って行われます。エラーが発生した場合、MODBUS例外応答を生成します。

• モジュール式マルチプロセッサデバイスまたはマルチスレッドアーキテクチャでは、“通信層”と“ユーザーアプリケーション層”は2つの独立したエンティティであり、通信エンティティはいくつかの重要でないサービスを完全に処理でき、他のサービスはアプリケーションバックエンドサービスがユーザーアプリケーションエンティティと協調して完了する必要がある。

ユーザーアプリケーションと対話するためには、MODBUSバックエンドサービスは、ユーザーアプリケーションのトランザクションを処理し、ユーザーアプリケーション呼び出しと対応するレスポンスを適切に管理するためのすべての適切なメカニズムを実行する必要があります。

ユーザーアプリケーションインタフェース（バックグラウンドインタフェース）

MODBUSバックエンドサービスでは、いくつかのポリシーを実行して作業を完了することができますが、ユーザーネットワークスループット、インターフェイス帯域幅の使用量、応答時間、さらには設計ワークロードの観点からも、これらのポリシーは不均一です。

MODBUSバックエンドサービスは、ユーザーアプリケーションに適切なインターフェイスを使用します。

• シリアルリンクベースの物理インタフェース、デュアルポートRAMスキーム、単純なI/Oケーブル、またはオペレーティングシステムが提供するメッセージ転送サービスベースの論理インタフェースなどです。
• ユーザーアプリケーションへのインタフェースは、同期または非同期です。

MODBUSバックエンドサービスは、適切なデザインパターンを使用して、ターゲット属性を取得/設定したり、サービスをトリガーしたりします。場合によっては、単純な“ゲートウェイモード”で十分です。他のケースでは、単純な交換テーブル履歴からより複雑な繰り返しメカニズムまで、設計者はキャッシュポリシーを備えた“プロキシモード”を実行する必要があります。

MODBUSバックエンドサービスは、ユーザーアプリケーションと対話するためのプロトコル変換を実装する責任があります。したがって、メッセージの分割と再編成、データの一貫性の保証、および必要なすべての同期を実現するメカニズムが必要です。

MODBUSレスポンスの生成

リクエストが処理されると、MODBUSサーバは適切なMODBUSサーバトランザクションを使用してレスポンスを生成し、TCP管理コンポーネントにレスポンスを送信する必要があります。

処理結果に応じて、次の2種類の応答を生成できます。

• 肯定的なModbus応答：
• レスポンス機能コード=リクエスト機能コード
• MODBUSの例外応答：
• 目的は、処理中に検出されたエラーに関する情報をクライアントに提供することである
• レスポンス機能コード=リクエスト機能コード+0 x 80
• エラーの原因を示す例外コードを提供します。

MODBUSレスポンスPDUはMBAPヘッダでプレフィックスされ、トランザクションボディのデータを使用してMBAPヘッダを生成する必要があります。

• ユニット識別子

受信したMODBUSリクエストでユニット識別子が与えられると、そのユニット識別子をコピーしてトランザクションの本記事に格納します。

• 長さは

サーバーは、MODBUS PDUとユニット識別子ワードのサイズを計算します。この値を[長さ]フィールドに設定します。

• プロトコル識別子

プロトコル識別子フィールドを0 x 0000（MODBUSプロトコル）に設定し、受信したMODBUSリクエストにプロトコル識別子を指定します。

• 取引子

このフィールドを“トランザクション識別子”の値に設定し、初期要求に関連付けられ、に格納します。

トランザクション本記事に格納されたTCPコネクションを利用して、正しいMODBUSクライアントに対してMODBUSレスポンスを返します。レスポンスが送信されると、トランザクションボディはアイドル状態にする必要があります。

実装ガイド

本章の目的は，メッセージ転送サービスを実現するための実例を提案することである.以下で説明するモデルは、クライアントまたはサーバがMODBUSメッセージ転送サービスを実装するためのガイドとして使用できます。

オブジェクトモデルのスケマティック図

図18：MODBUSメッセージングサービスオブジェクトモデルの概略図

4つの主要なパッケージはオブジェクトモデルの回路図を構成します。

• 他のパッケージコンポーネントの動作モードを構成および管理する構成層
• TCP管理：TCP/IPスタックとTCP接続を管理する通信アプリケーション層を接続します。これはソケットインターフェイスの管理を指します。
• 通信アプリケーション層は、片側のMODBUSクライアントと反対側のMODBUSサーバで構成されます。パッケージとユーザーアプリケーションへのリンク。
• デバイスアプリケーションに対応するユーザーアプリケーションは、完全にデバイス関連であるため、このドキュメントでは議論しません。

このモデルは、OSタイプ、ストレージ管理などの実装の選択には関係ありません。このような無依存性を保証するために，TCP管理層と通信層との間および通信層とユーザアプリケーション層との間には一般インタフェース層（generic Interface layers）が使用される.

インタフェースを実装するためのさまざまな実装方法があります：2つのタスク間の転送、共有メモリ、シリアルリンクインタフェース、プロセスコールなど。

以下の実装モデルを定義するために、いくつかの仮定がなされる。

• スタティックメモリ管理
• サーバの同期処理
• すべてのソケット受信に関するタスクを処理します。

TCP管理パッケージ

図19：MODBUS TCP管理パッケージ

TCP管理パッケージには、次のクラスが含まれます。

ClnterfaceConnexionこのクラスの役割は、接続に使用するリポジトリを管理することです。

CltemConnexion：接続を記述するために必要なすべての情報を含むクラス。

CTCPConnexion：TCPコネクションを自動的に管理するメソッドを提供します（CStackTCP_IPはインターフェイスソケットを提供します）。

CconnexionMngt：このクラスはすべての接続を管理し、CinterfaceindicationMsgとCinterfaceRoseponseMsgを介してMODBUSサーバ/MODBUSクライアントにリクエスト/レスポンスを送信します。このクラスは、接続確立のアクセス制御も処理します。

CMBAP：MODBUS MBAPを読み書き/分析するメソッドを提供します。

CStackTCP_IP：このクラスはソケットサービスを実行し、スタックのパラメータ設定を提供します。

Configuration Layerパッケージ

図20 MODBUS Configuration Layerパッケージ

構成層パッケージには、次のクラスが含まれます。

TConfigreObject：コンポーネント同士の構成に必要なデータをグループ化するクラス。CoperatingModeクラスのm_Confireメソッドで構造体を設定します。設定が必要な各クラスは、このオブジェクトから独自のデータを取得します。設定データは実装自体に関係します。そのため、クラスのプロパティテーブルをインスタンスとして提供します。

CoperatingMode：このクラスの役割は、TConfigueObject（ユーザの設定に応じて）を設定し、以下のクラスの操作モードを管理することです。

• CMODBUSServer
• CMODBUSClient
• CconnexionMngt

通信層パッケージ

図21：MODBUS通信アプリケーション層パッケージ

通信アプリケーション層パッケージには、次の種類があります。

CMODBUS Server：CinterfaceIndicationMsgからMODBUS問い合わせを受信します（m_ServerRecievingMessageメソッドを使用して）。このクラスの役割は、クエリに基づいてMODBUSレスポンスまたはMODBUS例外を確立することです。このクラスはMODBUSサーバのGraph Stateを実装します。レスポンスは、クラスCoperatingModeがユーザ設定と正しい動作モードを送信した場合にのみ生成できます。

CMODBUS Client：CinterfaceUser ApplicationクラスからMODBUSクエリを読み込みます。クライアントのタスクはm_ClientReceiving Messageメソッドを使用してクエリを受信することです。このクラスは、MODBUSクライアントのState Graphを実装し、（ネットワークからの）クエリに応答するトランザクションを管理します。クエリは、クラスCoperatingModeがユーザ設定と正しい動作モードを送信した場合にのみ、ネットワーク経由で送信できます。

CTransaction：トランザクションを管理するメソッドと構造を実装します。

インターフェイス·クラス

CInterfaceUser Application：このクラスは、ユーザアプリケーションとのインターフェイスを表し、ユーザデータにアクセスする2つの方法を提供します。実際の実装では、ハードウェアおよびソフトウェアデバイスの能力に応じて、このアプローチは異なる方法で実装されます（ターミナルドライブ、PCMCIAインスタンスへのアクセス、共有メモリなど）。

CInterfaceIndicationMsg：ネットワークからMODBUSサーバにクエリを送信し、ネットワークからクライアントに応答を送信するために使用されるインターフェイスクラス。このクラスは、TCP Managementと通信アプリケーション層パッケージを（ネットワークから）接続することを可能にする。このクラスの実装はネットワークに関連します。

CInterfaceResponseMsg：このインターフェイス·クラスは、サーバーからのレスポンスの受信と、クライアントからネットワークへの問い合わせの送信に使用されます。このクラスは、通信アプリケーション層パッケージとTCPManagementを（ネットワークに）接続させる。このクラスの実装はデバイスに関連します。

通信実装のクラスの図

以下のクラスの回路図は、完全な実装スキームの回路図です。

図22：クラスの概要

シーケンス図

次に、クライアントMODBUSトランザクションとサーバー MODBUSトランザクションを説明するために、2つのシーケンス図を説明します。

図23 MODBUSクライアントのシーケンス図

クライアントシーケンス図をよりよく理解するために、簡単なコメントを以下に示します。

ステップ1：ユーザアプリケーションからの問い合わせを読み込む（m_Readメソッドを介して）。

ステップ2：クライアントの仕事は、MODBUS問い合わせを（m_ClientReceiving Messageメソッドを介して）受信することです。これがクライアントの入り口です。問合せと対応する応答を相互に調整するために，問合せが得られたとき，クライアントはトランザクション処理リソース（クラス名：CTransaction）を使用する. MODBUS問い合わせは、コールクラスインタフェースCInterfaceResponseMsgを介してTCP_Managementに送信されますm_MODBUSRequestメソッドを介して。

ステップ3：接続が確立され、接続で何もする必要がない場合は、ネットワーク経由でメッセージを送信します。そうでなければ、ネットワーク上でメッセージを送信する前にオープンな接続が必要です。

この時点で、クライアントは最後に議論された応答（リモートサーバからの）を待ちます。

ステップ4：ネットワークからの応答がすでに受信されている場合、TCP/IPスタックはデータを受信します（m_EventOnStackメソッドを暗黙的に呼び出します）。

接続が確立されている場合、MBAPが読み込まれて接続オブジェクト（ストレージリソースやその他の情報を提供する）を復元します。

ネットワークからのデータを読み込み、クラスインタフェースCinterfaceIndicationMsgを介してクライアントに確認を送信します（m_MODBUSConfirmationメソッドを介して）。クライアントのタスクは、MODBUS確認を（m_ClientReceivingResponseメソッドを介して）受信することです。

最後に、書き込み応答が（m_Writedataメソッドを介して）ユーザに適用され、トランザクションリソースはアイドル状態になります。

MODBUS Server Exchangeの例を以下に示します。

図24 MODBUSサーバーシーケンス図

クライアントシーケンス図をよりよく理解するために、簡単なコメントを以下に示します。

ステップ1：クライアントがネットワーク経由で問い合わせ（MODBUS問い合わせ）を送信しました。TCP/IPスタックはデータを受信する（密かにm_EventOnSocketメソッドを呼び出す）。

ステップ2：リクエストは接続リクエストであるか、接続リクエストでないか（m_IsConnexionRequestメソッドを使用）場合があります。要求が接続要求であれば、接続オブジェクトとMODBUSフレームを送受信するバッファ（m_GetObjectConnexion）を割り当てる。その後、接続アクセス制御を確認して受け入れる必要があります。

ステップ3：クエリがMODBUSリクエストの場合、（m_ReceiveDataメソッドを介して）完全なMODBUSクエリを読み出すことができます。この時点で、MBAPを解析する必要がありますm_IsMdbHeadercorrectメソッドにより。CInterfaceIndicationMessagingクラスを介してサーバタスクtaskに完全なフレームを送信しますm_MODBUSIndicationメソッドを介して。サーバーの仕事は、MODBUS QUERYを（m_ServerReceiving Messageメソッドを介して）受信し、解析することです。

エラー（サポートされていない関数コードなど）が発生した場合は、MODBUS例外フレーム（m_BuildMODBUSException）を生成し、それ以外の場合はレスポンスを生成します。

ステップ4：CInterfaceResponseMessaging（m_MODBUSResponseメソッドを使用）を介してネットワーク上で応答を送信します。m_Dataメソッドにより接続オブジェクトに対する（接続子の元など）を行い、ネットワーク上にデータを送信する。

クラスとメソッドの説明

MODBUSサーバ侧クラス

クラス名CMODBUSServer

クラス名：CMODBUSServer

Stotype実装クラス

サーバモードでMODBUSメッセージ転送を管理する方法を提供する

MODBUSクライアントクラス

クラス名CMODBUSClient

クラス名CMODBUSClient

クライアントモードでMODBUSメッセージ転送を管理する方法を提供する

Stereotype実装クラス

インターフェイスのクラス

インタフェース指示クラス

クラス名CInterfaceIndicationMsg

既知のサブクラス

CConnexionMngt

クラス名：CInterfaceIndicationMsg

TCP_ManagementからMODBUSサーバまたはクライアントにメッセージを送信するクラス

Stereotypeインターフェース

インタフェース応答クラス

クラス名CInterfaceonseg

既知のサブクラス：

CMODBUSClient、CMODBUSServer

classCInterfaceResponseMsg

クライアントまたはサーバからTCP_Managementに応答または问い合わせを送信するクラス

Stereotypeインターフェース

接続管理クラス

クラス名CConnexionMngt

クラス名：CConnexionMngt

すべてのTCP接続を管理するクラス

Stotype実装クラス