Modbus protocol standard

Modbusプロトコル在TCP/IP上的実装ガイド

freeFree Technical Resource

This content is free to read, suitable for basic learning and search traffic.

modbus Technical Team

May 8, 2024 约 53 min read

引言

範囲

这个文件的範囲是介绍TCP/IP上的MODBUS报文传输服务，提供参照信息以帮助软件開発者たちは使用这种服务。这个文中不包括MODBUS機能コード的编码内容，这些信息请参阅MODBUSプロトコルの仕様[2]。

这个文件准确而包括的地説明了MODBUS报文传输服务的実装。其目的是便于在那些使用MODBUS报文传输服务的デバイス之间进行可互操作。

这个文件主要由三部分组成：

在TCP/IP上的MODBUS协议概述
MODBUS客户机、サーバー·サーバー和ゲートウェイ工具的功能説明
针对一个MODBUS実装实例的目标模型建议的実装准则。

客户机/サーバー·サーバー模型

MODBUS报文传输服务提供デバイス之间的客户机/サーバー·サーバー通信，这些デバイス联接在一个Ethernet（Ethernet） TCP/IP网络上。

这个客户机/サーバー·サーバーモード是基于4种タイプ报文：

MODBUS Request
MODBUS 证实
MODBUS 指示
MODBUS Response

MODBUSリクエスト是客户机在网络上送信用来启动トランザクション処理的报文

MODBUS指示是サーバー側。受信的リクエスト报文

MODBUSレスポンス是サーバー·サーバー送信的レスポンス信息

MODBUS证实是在クライアント側は受信的レスポンス信息

MODBUS报文传输服务（客户机/サーバー·サーバー模型）用于实时信息交換：

在2つデバイス应用程序之间
在デバイス应用和其它デバイス之间
在HMI/SCADA应用程序和デバイス之间
在一个PC和一个提供オンライン服务的デバイス程序之间

规范性引用文件

这章给出了在这个文件之前喜欢阅读的文件リスト：

[2] MODBUSプロトコルの仕様

[4] RFC1122

缩略语

ADU -- 应用データユニット

IETF -- 因特网工程工作组

IP -- 互连网协议

MAC -- 介质アクセス控制

MB -- MODBUS

MBAP -- MODBUSProtocol

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应用データユニット

这节説明了MODBUS TCP/IP网络中进行的MODBUSリクエスト或レスポンス的封装。

图3：TCP/IP上的MODBUS的リクエスト/Response

在TCP/IP上使用一种专用报文头识别MODBUS应用データユニット。将这种报文头称为MBAPmessage header（MODBUS协议报文头）。

这种报文头提供一些与串行链路上使用的MODBUS RTU应用データユニット比较的差别：

用MBAP报文头中的单バイト単位。ユニット标识符取代MODBUS串行链路上通常使用的MODBUS住所から。域。这个ユニット标识符用于デバイス的通信，这些デバイス使用单个IPアドレスサポート多个独立MODBUS终端ユニット，例如：网桥、ルータの設置和ゲートウェイ。
用受信者可以验证完成报文的方式设计すべてのMODBUSリクエスト和レスポンス。对于MODBUS PDU有固定長さ的機能コード来说，仅機能コード就足够了。对于在リクエスト或レスポンス中携带一个可变データ的機能コード来说，データ域包括Bytesの数。
当在TCP上携带MODBUS时，即使将报文分成多个信息包来传输，办事在MBAP报文头上携带附加長さ信息，以便受信者能识别报文边界。显式和隐式長さルール的存在以及CRC-32差错チェックコード的使用（在イーサネット（イーサネット）上）将对リクエスト或レスポンス报文产生极小的未检出干渉。

MBAP报文头説明

MBAP报文头包括下列域：

域	Length	Description	客户机	Server
トランザクション元标识符	2バイト単位。	MODBUSRequest/レスポンストランザクション処理的识别码	客户机启动	サーバー·サーバー从受信的リクエスト中重新コピー
Protocol Identifier	2バイト単位。	0=MODBUSProtocol	客户机启动	サーバー·サーバー从受信的リクエスト中重新コピー
Length	2バイト単位。	以下バイト的数量	客户机启动（Request）	Server（Response）启动
Unit identifier	1バイト単位。	串行链路或其它バス上连接的远程スレーブ的识别码	客户机启动	サーバー·サーバー从受信的リクエスト中重新コピー

报文头为7バイト単位。长：

トランザクション処理标识符：用于トランザクション処理配对。在レスポンス中，MODBUSサーバー·サーバーコピーリクエスト的トランザクション処理标识符。

Protocol Identifier：用于系统内的多路复用。経由值0识别MODBUSProtocol。

Length：長さ域是下一个域的Bytesの数，包括ユニット标识符和データ域。

Unit identifier：为了系统内路由，使用这个域。专门用于経由イーサネット（イーサネット）TCP-IP网络和MODBUS串行链路之间的ゲートウェイ对MODBUS或MODBUS+串行链路スレーブ的通信。MODBUS客户机在リクエスト中に設置。这个域，在レスポンス中サーバー·サーバー必须利用相同的值戻る这个域。

在登録的502ポート上利用TCP送信すべてのMODBUS/TCP ADU。

注：用Big-endian编码不同域。

MODBUS機能コード説明

在MODBUSプロトコルの仕様[2]中详细説明了MODBUSアプリケーション層プロトコル上使用的標準機能コード。

功能説明

这里提供的MODBUS组件構造是一个既包含MODBUS客户机又包含MODBUSサーバー·サーバー组件的通用模型，適用される任何デバイス。

一部のデバイス可能仅提供サーバー·サーバー或客户机组件。

本章的第一部分，给出一个有关MODBUS报文传输服务组件構造的简要概述，然后，给出構造模型内部每一个组件的説明。

MODBUS组件構造模型

图4 MODBUS报文传输服务概念構造

通信アプリケーション層

一个MODBUSデバイス可以提供一个客户机和/或サーバー·サーバーMODBUSInterface。

可提供一个MODBUS后台接口，允许间接的アクセス用户应用对象。

此接口由四部分组成：离散量入力、离散量出力（コイル）、レジスタ入力和レジスタ出力。此接口与用户应用データ之间的マッピング追加する必要がある以定义（本地問題）。

基本データ表	オブジェクトタイプ	属性	説明
离散量入力	1位	読み取り専用	此类データ可来自I/Osystem
コイル	1位	读-写	此类データ可被应用程序修改
レジスタ入力	16位字	読み取り専用	此类データ可来自I/Osystem
レジスタ出力	16位字	只写	此类データ可被应用程序修改

MODBUS客户机

MODBUS客户机允许用户应用清晰地控制与远端デバイス的信息交換。MODBUS客户机根据用户应用向MODBUS客户接口送信的需求中所包含的参数生成一个MODBUSRequest。

MODBUS客户机调用一个MODBUS的トランザクション処理，トランザクション処理管理包括MODBUS证实的待機中和処理。

MODBUS客户机接口

MODBUS客户机接口提供一个接口，使得用户应用能够生成对包括アクセスMODBUS应用对象在内的各类MODBUS服务的リクエスト。尽管在実装模型中以实例説明，但是MODBUS客户机接口（API）ここで不进行説明。

MODBUSServer

在收到一个MODBUSリクエスト以后，モジュール激活一个本地操作进行读、写、或完成其他操作。这些操作的処理对应用程序开发人员来说都是透明的。MODBUSサーバー·サーバー的主要功能是待機中来自TCP502口的MODBUSRequest，処理这一リクエスト，然后生成一个MODBUS应答，应答取决于デバイス状况（场境）。

MODBUS后台接口

MODBUS后台接口是一个从MODBUSサーバー·サーバー到定义应用对象的用户应用之间的接口。

TCP管理层

报文传输服务的主要功能之一是管理通信的建立和结束，管理建立在TCP连接上的データ流。

连接管理

在客户机和サーバー·サーバー的MODBUSモジュール之间的通信呼び出しが必要ですTCP连接管理モジュール。它负责包括的管理报文传输TCPconnect。

连接管理中存在两种可能：用户应用自身管理TCPconnect，或すべて由这个モジュール进行连接管理，而对用户应用透明。后一种方案灵活性较差。

TCP 502口的侦听是为MODBUS通信保留的。在缺省ステータス下，强制侦听这个口。然而，一部の市场或应用可能需要其他口作为TCP上MODBUS的通信之用。当需要与非施奈德（Schneider）产品进行互操作时，就属于这种情况，例如：在建筑控制中。为此，强烈建议：客户机和サーバー·サーバー均应向用户提供对TCP口号上的MODBUS参数进行設定的可能性。重要的是：即使在某一个特定的应用中为MODBUS服务設定了其他TCPサーバー·サーバー口，除一些特定应用口外，TCPServer502口必须仍然是可用的。

アクセス控制モジュール

在某些至关重要的场合，必须禁止必要なし。的マスター对デバイス内部データ的アクセス。这既是なぜか。需要セキュリティモード，也是在需要时実装セキュリティ処理的原因。

TCP/IP栈层

TCP/IP的栈可以进行参数設定，以便于使得データフロー制御制、アドレス管理和连接管理适应于特定的产品或系统的不同的约束。一般说来，BSD套接字接口就用来管理TCPconnect。

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

为了平衡MODBUS客户机与サーバー·サーバー之间进出报文传输的データ流，在MODBUS报文传输栈的すべての各层均設定了データフロー制御制机制。リソース管理和データフロー制御制モジュール首先是基于TCP内部データフロー制御制，附加データ链路层的某些データフロー制御制，以及用户アプリケーション層的データフロー制御制。

TCP连接管理

连接管理モジュール

总体説明

MODBUS通信需要建立客户机与サーバー·サーバー之间的TCPconnect。

连接的建立可以由用户应用モジュール直接実装，也可以由TCP连接管理モジュール自动完成。

在第一种情况下，用户应用モジュール必须提供应用程序接口，以便完全管理连接。这种方式为应用开发人员提供了灵活性，但需要TCP/IP机制方面的专长。

在第二种方案中，TCP连接管理完全不出现，用户应用仅需要送信和接受MODBUSmessage。TCP连接管理モジュール负责在需要时建立新的TCPconnect。

TCP客户机和サーバー·サーバー连接数量的定义不属于本記事件的范畴（在本記事中采用n）。根据デバイス能力，TCP连接的数量会不同。

実装ルール：

もしない明确的用户需求，建议采用自动的TCP连接管理
建议：打开并保持与远端デバイス的连接，而不要在每次MODBUS/TCPトランザクション処理时打开和接続を閉じる。注：然而，MODBUS客户必须能够受信来自サーバー·サーバー的关闭リクエスト，并接続を閉じる。当需要时，连接可以被重新打开。
建议：每一个MODBUS客户至少要打开与远端MODBUSサーバー·サーバー的TCPconnect（同一IPaddress）。一个应用建立一个连接是好的選択。
几个MODBUSトランザクション処理可以在同一个TCP连接上被同时激活注：もし以此方式，MODBUSトランザクション処理标识必须被用来唯一地识别リクエスト与レスポンス的マッチング。
在2つ远端MODBUSdevice（一个客户机和一个サーバー·サーバー）之间双向通信的情况下，有必要为客户机データ流和サーバー·サーバーデータ流分别建立连接。
一个TCPフレーム只能传送一个MODBUS ADU。建议：不要在同一个TCP PDU中送信多个リクエスト或应答。

图7：TCP连接管理操作图

1．显式TCP连接管理

用户应用モジュール负责管理すべての的TCPconnect：主动的和被动的接続の確立、连接结束………。对客户机与サーバー·サーバー间すべての的连接进行这种管理。BSD套接字接口用在用户应用モジュール中来管理TCPconnect。这种方案提供了完全的灵活性，但也意味着应用开发人员要具备充分的有关TCP的知识。

考虑到デバイス的能力和需求，必须进行設定客户机与サーバー·サーバー间连接数的限制。

2．自动TCP连接管理

TCP连接管理对用户应用モジュール是完全透明的。连接管理モジュール可以接受足够数量的客户机/サーバー·サーバー连接。否则，在超过所認証数量的连接时必须有一种実装机制。在这种情况下，我们建议：关闭最早建立的不使用的连接。

在收到第一个来自远端客户机或本地用户应用的データパケットは后，就建立了与远端对象的连接。もし一个网络进行终止或本地デバイス决定终止，此连接将被关闭。在受信接続リクエスト时，アクセス控制选项可用来禁止未認証客户アクセスデバイス的可能性。

TCP连接管理モジュール采用栈接口（通常BSD套接字接口）来与TCP/IP栈进行通信。

为了保持系统需求与サーバー·サーバーリソース之间的兼容，TCP管理将保持2つ连接库。

第一个库（优先连接库）由那些从不被本地主动关闭的连接组成。必须提供一个設定来建立这个库。実装的原理是将这个库的每一个可能的连接与一个特定的IPアドレス联系起来。具有这个IPアドレス的デバイス被称为“标记的”。任何一个被“标记的”デバイス的新的接続リクエスト必须被受信，并从优先连接库中取出。还有必要設定允许每个远端デバイス最多建立连接的数量，以避免同一デバイス使用优先连接库中すべての的连接。
第二个库（非优先连接库）包括了非标记デバイス的连接。这里采用的ルール是：当有来自非标记デバイス的新的接続リクエスト，以及库中ない连接可用时，关闭早些时候建立的连接。

一个設定可作为选项提供来分配每个库中可用连接的数量。然而（非强制性的），もし需要，设计人员可在设计期间设定连接的数量。

连接管理説明

接続の確立

MODBUS报文传输服务必须在502口上提供一个侦听套接字，允许受信新的连接和与其他デバイス交換データ。

当报文传输服务需要与远端サーバー·サーバー交換データ时，它必须与远端502口建立一个新的客户连接，以便与远距离交換データ。本地口必须高于1024，并且每个客户连接各不相同。

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

もし客户机与サーバー·サーバー的连接数量大于認証的连接数量，则最早建立的无用的连接被关闭。激活アクセス控制机制チェック远端客户机的IPアドレス是否是经过認証的。もし未经認証，将拒绝新的连接。

MODBUSデータ变换

基于已经打开的正确的TCP连接送信MODBUSRequest。远端デバイス的IPアドレス用于寻找所建的TCPconnect。在与同一个远端デバイス建立多个连接时，必须選択其中一个连接用于送信MODBUSmessage，可以采取不同的選択策略，例如：最早的连接、第一个连接。在MODBUS通信的全过程中，连接必须始终保持打开。如同下列各章所説明的一样，一个客户机可以向一个サーバー·サーバー启动多个トランザクション処理，而不必待機中前序事物処理结束。

连接关闭

当客户机与サーバー·サーバー间的MODBUS通信结束时，客户机必须关闭用于通信的连接。

操作モード对TCP连接的影响

某些操作モード（两操作端点之间通信断开、一个端点的故障和重新启动、………）会对TCP连接产生影响。一个连接可被视为在这一侧关闭或異常终止而ない另一侧的確認，称这种连接为“半打开”的连接。

本章説明每种主要操作モード的characteristic。假设在连接的两端采用了“ 保持连接 ”TCP机制。

两操作端之间通信断开

通信断开的原因可以是サーバー·サーバー侧イーサネット（イーサネット）连接电缆断开。预期的characteristic是：

もし在连接上ない正在送信データパケットは：

もし通信断开持续的时间短于“保持连接”计时器的值，将察觉不到通信断开。もし通信断开时间超过“保持连接”计时器的值，将一个エラー戻る到TCP连接层，由其复位连接。

もし在连接断开的前后送信一些データパケットは：

TCP重新传输算法（Jacobson算法、Karn算法以及指数补偿算法）被激活。这可能导致在“保持连接”计时器终止之前TCP栈连接层复位。

サーバー側。的故障和重新启动

在サーバー·サーバー故障和重新启动以后，クライアント側は处于“半打开”连接ステータス。预期的characteristic是：

もし在半打开的连接上ない送信データパケットは：

只要“保持连接”计时器还在计时中，从クライアント側は看，连接是半打开的。之后，将戻る一个エラー到TCP管理层，由其复位连接。

もし在半打开的连接上送信一些データパケットは：

サーバー·サーバー在不存在的连接上受信データ。TCP层的栈送信一个复位指令来关闭クライアント側は的半打开的连接。

客户机端的故障和重新启动

在客户机故障和重新启动以后，サーバー·サーバー侧处于“半打开”连接ステータス。预期的的ステータス是：

もし在半打开的连接上ない送信データパケットは：

只要“保持连接”计时器还在计时中，从サーバー側。看，这种连接是半打开的。之后，将戻る一个エラー到TCP管理层，由其复位连接。

もし在“保持连接”计时器完成计时前，客户机打开一个新的连接：

必须分两种情况研究：

所打开的连接与サーバー·サーバー侧半打开的连接具有相同的特性（相同的源和目的口、相同的源和目的IPaddress），所以，在接続の確立タイムアウト后（伯克利実装的多数情况下为75ms），TCP栈层将不能打开连接。为了避免较长タイムアウト時間内不能进行通信，建议：在客户机端重新启动后，确保使用与原有连接不同的源口号建立连接。
所打开的连接与サーバー·サーバー侧半打开的连接具有不同的特性（不同的源口和相同的目的口、相同的源和目的IPaddress），所以，在TCP栈层上打开连接，并向サーバー·サーバー侧的TCP管理层送信信号。

もしサーバー·サーバー侧TCP管理层仅サポート一个远端客户机IPアドレス的连接，那么可以关闭原来的半打开的连接，使用新的连接。

もしサーバー·サーバー侧TCP管理层サポート多个远端客户机IPアドレス的连接，那么新的连接保持打开ステータス，原来的连接也保持半打开ステータス，直到“保持连接”计时器计时结束，此时，将戻る一个エラー到TCP管理层。之后，TCP管理层将能够复位原有的连接。

アクセス控制モジュール

这个モジュール的目的是チェック每一个新的连接，对照一个合法認証的远程IPアドレスリスト，它可以認証或禁止一个远端客户机的TCPconnect。

在至关重要的场合，应用开发人员需要選択アクセス控制モジュール来保证网络的アクセス。在这种情况下，需要对每个远端IP認証或禁止アクセス。用户需提供一个IPアドレス的リスト，并特别注明每个IPアドレス是否合法認証。在缺省情况下，在セキュリティモード中，用户未設定的IPアドレス均被禁止。所以，借助于アクセス控制モード，关闭来自未知的IPアドレス的アクセス连接。

TCP/IP栈的使用

TCP/IP栈提供了一个接口，用来管理连接、送信和受信データ，还可以进行参数設定，以使得栈的特性适应于デバイス或系统的限制。

本章的目的是给出有关栈接口的综述，以及一些与栈的参数設定有关的信息。总揽综述主要是MODBUS报文传输所使用的一些特性。

对于もっと見る的信息，建议阅读RFC 1122，这个RFC 1122为厂商和开发商提供了互联网通信软件的ガイド。RFC 1122详述了一个连接到互联网的マスター必须采用的標準プロトコル，以及一组明确的需求和选项。

栈接口一般是基于本記事件中説明的BSD（伯克利软件分配代码）Interface。

BSD套接字接口的应用

注：一部のTCP/IP栈从性能考虑提出其他タイプ的接口。MODBUS客户机或サーバー·サーバー可以使用这些特定的接口，但是在本記事件中对这种使用不做説明。

一个套接字是一个通信端点，它是通信中的基本构成块。経由套接字送信和受信データ可以执行一个MODBUSCommunication。TCO/IP库仅提供了使用TCP和提供基于连接的通信服务的流套接字。

socket()函数用来作成套接字。戻る的一个套接字号被作成者用来アクセス套接字。套接字作成时ないアドレス（IPアドレス和口号）。直到一个口被绑定到该套接字时，方可受信データ。

bind()函数用来绑定一个口号到套接字。bind()函数在套接字与所指定的口号之间建立一个连接。

为了初期化一个连接，クライアント側は必须送信connect()函数来指定套接字号、远端IPアドレス和远端侦听口号（主动接続の確立）。

为了完成连接，サーバー側。必须送信accept()函数指定以前在listen()调用中所指定的套接字号（被动接続の確立）。一个新的套接字被作成，并具有与最初相同的特性。这个新的套接字连接到客户机的套接字，而将套接字号戻る到サーバー側。。于是，释放初始套接字，以便为其他欲与サーバー·サーバー连接的客户机使用。

在TCP接続の確立以后，データ即可被传递。将Send()和recv()函数专门地设计成与已经连接的套接字一道使用。

setsockopt()函数允许套接字的作成者用套接字建立若干选项。这些选项説明了套接字的操作特征。

select()函数允许プログラミング人员测试すべての套接字上的事件。

shutdown()函数允许套接字的使用者来终止send()和/或recv()。

一旦不再需要套接字，可以使用close()函数来放弃套接字的説明信息。

图9：MODBUS信息交換

上图给出了客户机与サーバー·サーバー间完全に。的MODBUS通信过程。客户机建立一个连接，向サーバー·サーバー送信3个MODBUSRequest，而不待機中第一个リクエスト的应答到来。在收到すべての的应答后，客户机正常地接続を閉じる。

TCP层参数設定

可以调整TCP/IP栈的一些参数以使得其特性满足产品或系统的限制。TCP层的下列参数可以进行调整：

每个连接的参数

SO-RCVBUF, SO-SNDBUF:

这些参数允许为送信和受信用套接字接口设定高限位。可以経由调整这些参数来実装トラフィック控制管理。受信缓存区的的大小即为每个连接advertised window的最大值。为了提高いパフォーマンスを，必须增加套接字缓存区的大小。否则，这些值必须小于内部驱动器的リソース，以便在内部驱动器的リソース耗尽之前关闭TCP窗口。

受信缓存区大小取决于TCP窗口大小、TCP最大段的大小和受信入力フレーム所需的时间。由于最大段的尺寸为300个字（一个MODBUSリクエスト需要最大256字+MBAPmessage header）,もし需要3フレーム进行缓存，可将套接字缓存区大小调整为900字。为了满足最大的缓存需求和预定的时间，可以增加TCP窗口的大小。

TCP-NODELAY:

通常，小报文（称为：tinygrams）在局域网（LAN）上的传输不会产生問題，因为多数局域网是不拥堵的，但是，这些tinygrams在广域网上将会造成拥堵。一个称为“NAGLE算法”的简单方案是：收集小量的データ，当前面报文的TCP確認到达时再用单个进行送信。

为了获得更好的实时特性，建议：将小量的データ直接送信，而不要试图将其收集到一个段内再送信。这就是なぜか。建议强制TCP-NODELAY选项，这个选项無効客户机和サーバー·サーバー连接的“NAGLE算法”。

SO-REUSEADDR:

当MODBUSサーバー·サーバー关闭一个由远端客户启动的TCP连接时，在这个连接处于“时间待機中”status（2つMSL：最大段寿命）的过程中，该连接所用的本地口号不能被再次用来打开一个新的连接。

建议：为每个客户机和サーバー·サーバー连接，指明SO-REUSEADDR选项，以迂回这个限制。此选项允许为自身分配一个口号，它作为连接的一部分在2MSL期间内待機中客户机并侦听套接字接口。

SO-KEEPALIVE:

TCP/IP协议缺省ステータス下，通信不可过空闲的TCP连接送信データ。因此，もし在TCP连接端这个过程ない送信データ，在2つTCPモジュール间就ない交換任何データ。这就假设客户机端应用和サーバー側。应用均采用カウンター·カウンター来探测连接的存活性，以便接続を閉じる。

建议：在客户机与サーバー·サーバー连接两端均采用KEEPALIVE选项，以便查询另一端得知对方是否故障并死机，或故障并重新启动。

然而，我们必须牢记，采用KEEPALIVE可能引起一个非常良好的连接，在瞬间故障时通信中断，もし保持连接计时器计时周期短すぎる，将占用不必要的网络带宽。

整个TCP层的参数

TCP接続の確立タイムアウト:

多数伯克利推出的系统将新接続の確立的时限设定为75秒，这个缺省值应该适应于实时的应用限制。

保持接続パラメータ:

连接的缺省暇なとき间是2小时。超过此暇なとき间将触发一个保持连接试探过程。第一个保持连接试探后，在最大次数内每隔75秒送信一个试探，直到收到对试探的应答为止。

在一个空闲连接上发出保持连接试探的最大数是8次。もし发出最大试探次数之后而ない收到应答，TCP向应用发出一个エラー信号，由应用来决定接続を閉じる。

タイムアウト与重发参数:

もし检测到一个TCP报文丢失，将重发此报文。检测丢失的方法之一是管理重发タイムアウト（RTO），もしない收到来自远端的確認，タイムアウト终止。

TCP进行RTO的动态评估。为此，在送信每个非重发的报文后测量往返时间(RTT)。往返时间（RTT）是指报文到达远端デバイス并从远端デバイス获得一个確認所用的时间。一个连接的往返时间是动态計算的，然而，もしTCP不能在3秒钟内获得RTT的估计，那么，就设定RTT的缺省值为3秒。

もし已经估算出RTO，它将被用于下一个报文的送信。もし在估算的RTO终止之前ない收到下一个报文的確認，Enable指数补偿算法。在一个特定的时间段内，允许相同报文最大次数的重发。之后，もし受信できない。確認，连接终止。

可以对某些栈設定连接终止之前重发的最大次数和重发的最长时间。

在TCP標準中定义了一些重发算法：

Jacobson RTO估計算法用来估计重发タイムアウト(RTO)；
Karn算法指出，在重发段，不应进行RTO估计；
指数补偿算法定义：对于64秒时间上限内每一次重发，加倍重发タイムアウト；
快速重发算法允许在收到3个重复確認之后进行重发。考虑这个算法是因为：在LAN上，可能会导致报文丢失的检测快于待機中RTO终止的检测。

在MODBUS実装中，推奨される使用这些算法。

IP层的参数設定

IPparameter

下列参数必须在MODBUS実装的IP层进行設定：

本地IPaddress：IPアドレス可以是A、B或C类的一种。
サブネットマスク：可基于各种原因，将IP网络划分成子网：使用不同的物理介质（例如：Ethernet、广域网等）、更有效的使用网络アドレス、以及控制网络トラフィック的能力。サブネットマスク必须与本地IPアドレス的タイプ相一致。
缺省ゲートウェイ：缺省ゲートウェイ的IPアドレス必须与本地IPアドレス在同一子网内。禁止使用0.0.0.0的值。もしない定义ゲートウェイ，那么此值可设为127.0.0.1或本地IPaddress。

注：MODBUS报文传输服务在IP层上不要求段功能。

应该利用本地IPaddress、サブネットマスク和省缺ゲートウェイ（不同于0.0.0.0）設定本地IP端。

通信アプリケーション層

MODBUSクライアント側は

图10：MODBUSクライアント側は

MODBUSクライアント側は设计

MODBUS/TCP协议使得能够对一个クライアント側は进行简单的设计。下图説明了クライアント側は送信MODBUSリクエスト并処理MODBUS应答的主要処理过程。

图11：MODBUSクライアント側は操作示意图

一个MODBUS客户机可以受信三类事件：

一个来自用户应用的リクエストの送信的新需求，在这种情况下，必须对MODBUSリクエスト进行编码，并使用TCP管理组件服务経由网络进行送信MODBUSRequest。下层（TCP管理モジュール）会戻る一个エラー信息，这些エラー信息是由于TCP连接エラーまたは他のエラー信息所导致的。
来自TCP管理的一个レスポンス，在这种情况下，クライアント側は必须分析レスポンス的内容，并向用户应用送信一个证实。
由于応答なし。而タイムアウト结束。可以経由网络送信一个重试电文，或向用户应用送信一个否定证实。

注：这些重试是由MODBUS客户机启动的，可以在无TCP確認的情况下由TCP层来进行其它タイプ的重试。

MODBUSリクエスト的生成

在收到来自用户应用的需求后，クライアント側は必须生成一个MODBUSRequest，并送信到TCP管理。

可以将生成MODBUSリクエスト分解成为几个子任务：

MODBUSトランザクション処理的实例化，使客户机能够存储すべての需要的信息，以便将レスポンス与相应的リクエストマッチング，并向用户应用送信证实。
MODBUSRequest（PDU+MPABmessage header）的编码。启动需求的用户应用必须提供すべての需要的信息，使得客户机能够将リクエスト编码。根据MODBUS协议进行MODBUS PDU的编码（MODBUSfunction code、相关参数和应用データ[2]）。填充MBAP报文头的すべての域。然后，将MBAP报文头作为PDU前缀，生成MODBUSRequestADU。
sendMODBUSRequestADUtoTCP管理モジュール，TCP管理モジュール负责对远端サーバー·サーバー寻找正确TCP的套接字。除了MODBUS ADU以外，还必须传递目的IPaddress。

下图比图17更深入地説明了リクエスト生成的过程。

图12：リクエスト生成操作示意图

下面给出了实例：住所から。为05的远端サーバー·サーバー读1个字的MODBUSRequestADUCoding

MODBUSRequestADUCoding：

	説明	大小	实例
MBAPmessage header	トランザクション処理标识符Hi	1	0x15
	トランザクション処理标识符Lo	1	0x01
	Protocol Identifier	2	0x0000
	Length	2	0x0006
	Unit identifier	1	0xFF
MODBUSRequest	function code（*）	1	0x03
	starting address	2	0x0005
	number of registers	2	0x0001

（*）参见MODBUSプロトコルの仕様[2]

トランザクション処理标识符

トランザクション処理标识符用于将リクエスト与未来レスポンス之间建立联系。因此，对TCP连接来说，在同一时刻，这个标识符必须是唯一的。有几种使用此标识符的方式：

例如：可以作为一个带有カウンター·カウンター的简单“TCP顺番号”，在每一个リクエスト时增加カウンター·カウンター；
也可以用作智能索引或指针，来识别トランザクション処理的内容，以便记忆当前的远端サーバー·サーバー和未処理的リクエスト。

通常，在MODBUS串行链路上，客户机必须一次送信一个リクエスト。这意味着这个客户机在送信第二个リクエスト之前必须待機中对第一个リクエスト的回答。在MODBUS TCP上，可以向同一个サーバー·サーバー送信多个リクエスト而不需待機中サーバー·サーバー的证实。MODBUS/TCPtoMODBUS串行链路之间的ゲートウェイ负责保证这两种操作之间的兼容性。

サーバー·サーバー收接受的リクエスト数量取决于其容量，即：サーバー·サーバーリソース量和TCP窗口尺寸。同样，客户机同时启动トランザクション処理的数量也取决于客户机的リソース容量。这个実装参数称为“NnmberMaxofClientTransaction”，必须作为MODBUS客户机的一个特性进行説明。根据デバイス的タイプ，此参数取值为1～16。

Unit identifier

在MODBUS或MODBUS+串行链路子网中对デバイス进行寻址时，这个域是用于路由的目的。在这种情况下，“Unit Identifier”携带一个远端デバイス的MODBUSslave address：

- もしMODBUSサーバー·サーバー连接到MODBUS+或MODBUS串行链路子网，并経由一个桥或ゲートウェイの構成アドレス这个サーバー·サーバー，MODBUSユニット标识符对识别连接到网桥或ゲートウェイ后的子网的スレーブデバイス是必需的。目的IPアドレス识别了网桥本身的アドレス，而网桥则使用MODBUSユニット标识符将リクエスト转交给正确的スレーブデバイス。

- 分配串行链路上MODBUSスレーブデバイスアドレス为1～247（decimal），address0作ブロードキャストアドレス。

对TCP/IP来说，利用IPアドレス寻址MODBUSServer；因此，MODBUSユニット标识符是无用的。必需使用值0xFF。

- 当对直接连接到TCP/IP网络上的MODBUSサーバー·サーバー寻址时，建议不要在“Unit identifier”域使用有效的MODBUSslave address。在一个自动系统中重新分配IPアドレス的情况下，并且もし以前分配给MODBUSサーバー·サーバー的IPアドレス又被指配给ゲートウェイ，使用一个有效駅からの住所可能会由于ゲートウェイ的路由不畅而引起麻烦。使用无效駅からの住所，ゲートウェイ仅是简单地废弃MODBUD PDU，而不会有任何問題。建议：在采用0xFF作为“Unit identifier”的无效值。

注：0也可以用作与MODBUS/TCPデバイス直接通信。

処理MODBUS证实

在TCP连接中，当收到一个レスポンスフレーム时，位于MBAP报文头中的トランザクション処理标识符用来将レスポンス与先前发往TCP连接的元のリクエスト联系起来：

もしトランザクション処理标识符ない提及任何未解決的トランザクション処理，那么必须废弃レスポンス；
もしトランザクション処理标识符提及了未解決的トランザクション処理，那么必须分解レスポンス，以便向用户应用送信MODBUS证实（肯定的或否定的证实）；

分解レスポンス就是检验MBAP报文头和MODBUS PDU的レスポンス：

MBAPmessage header

在检验协议标识符必为0x0000以后，長さ给出了MODBUSレスポンス的大小。

もしレスポンス来自直接连接到TCP/IP网络的MODBUSサーバー·サーバーデバイス，TCP连接识别码足以清晰地识别出远端サーバー·サーバー。因此，MBAP Head中携带的ユニット标识符是无效的，必须废弃这个ユニット标识符。

もし将远端サーバー·サーバー连接在一个串行链路子网上，并且レスポンス来自一个网桥、路由或ゲートウェイ，那么ユニット标识符（值≠0xFF）识别送信初始レスポンス的远端MODBUSServer。

MODBUSResponsePDU

必须检验機能コード，根据MODBUSProtocol，分析MODBUS的応答の形式：

もし機能コード与リクエスト中所用的機能コード相同，并且もしレスポンス的格式是正确的，那么，向用户应用发出MODBUSレスポンス作为肯定的证实。
もし機能コード是一个MODBUSException Code（function code+80H），向用户应用发出一个異常な応答作为肯定的证实。
もし機能コード与リクエスト中所用的機能コード不同（= 非预期的機能コード），或もしレスポンス的格式是エラー的，那么，向用户应用发出一个エラー信号作为否定的证实。

注：肯定证实是指サーバー·サーバー收到リクエスト命令并做出レスポンス的证实。并不意味着サーバー·サーバー能够成功地完成リクエスト命令中要求的操作（MODBUS異常な応答指明执行操作に失敗しました）。

下图比图17更深入地説明了证实処理的过程。

图13：MODBUS证实処理操作示意图

タイムアウト管理

对MODBUS/TCP上トランザクション処理所需応答時間有意不作规定。

这是因为：从毫秒级的I/O扫描到延时几秒钟的远距离无线链路，预期MODBUS/TCP会用于可能最宽泛的通信场合。

从客户机的角度，タイムアウトは必須考虑网络上预期的传输延迟，以便确定一个合理的応答時間。这种传输延迟可能是交換式イーサネット（イーサネット）中的几个毫秒，或广域网连接中的几百毫秒。

反过来讲，任何客户机启动应用重试使用的タイムアウト時間应该大于预期的最大的合理応答時間。もし不遵循这一点，目标デバイス或网络就存在过度拥挤的潜在危险，而反过来会导致もっと見る的エラー。这是一个应该始终避免的特性。

因此，在实际中，在高いパフォーマンスを应用中所使用的客户机タイムアウト似乎总是与网络トポロジー和期望的客户机性能有关。

时间因素不很重要的系统经常采用TCP缺省值作为タイムアウト值，在多数プラットフォーム上，几秒钟之后将报告通信故障。

MODBUSサーバー側。

图14：MODBUSサーバー側。

MODBUSサーバー·サーバー的作用是为应用对象提供アクセス以及为远端客户机提供服务。

根据用户应用，提供不同タイプ的アクセス：

简单アクセス：获得或设定应用对象的属性；
エキスパートアクセス：启动一个特定的应用服务

MODBUSサーバー·サーバー必须：

将一个应用对象マッピング成可读或可写的MODBUS对象，以便获得或设定应用对象的属性；
提供一种对应用对象启动服务的方法；

在运行过程中，MODBUSサーバー·サーバー必须分析受信到的MODBUSRequest，処理所需的操作，戻るMODBUSResponse。

MODBUSサーバー·サーバー设计

MODBUSサーバー·サーバー设计取决于如下2つ方面：

对应用对象アクセス的タイプ（对属性的简单アクセス或对服务的エキスパートアクセス）；
MODBUSサーバー·サーバー与用户应用之间交互作用的タイプ（同步或异步）。

下图説明了サーバー·サーバー进行的主要処理过程，以便获得来自TCP管理的MODBUSRequest，然后，分析リクエスト，処理所需的操作，戻るMODBUSResponse。

图15：処理MODBUS指令操作示意图

象前面的操作示意图示出的那样：

MODBUSサーバー·サーバー本身可以立即処理一些服务，ない与用户应用之间的交互作用；
一些服务还可能需要与被処理的用户应用进行明显的交互作用；
一部のエキスパート服务呼び出しが必要です特定的接口，即：MODBUS后台服务。例如：可能根据用户アプリケーション層プロトコル，使用若干个MODBUSRequest/レスポンストランザクション処理的时序来启动用户应用服务。后台服务负责すべての单个MODBUSトランザクション処理的正确进行，以便于执行全局用户应用服务。

在下列各章中给出更完全的説明。

MODBUSサーバー·サーバー可以受信并同时为多个MODBUSリクエスト提供服务。サーバー·サーバー可以同时受信MODBUSリクエスト的最大数量是MODBUSサーバー·サーバー的主要特性之一。这个数量取决于サーバー·サーバー的设计以及它的処理和存储能力。将这个実装参数称为“NumberMaxOfServerTransaction”，必须作为MODBUSサーバー·サーバー的一个特性説明这个実装参数。根据デバイス的能力，它的取值範囲为：1～16，。

“NumberMaxOfServerTransaction”参数对MODBUSサーバー·サーバー的操作和性能有非常显著的影响。尤其重要的是，所管理的并发MODBUSトランザクション処理的数量可能影响サーバー·サーバー对MODBUSリクエスト的応答時間。

MODBUS PDU检验

下图説明了MODBUS PDU检验操作。

图16：MODBUS PDU检验操作流程图

MODBUS PDU检验功能首先是分解MBAPmessage header。必须检验协议标识符域：

もし与MODBUS协议タイプ不同，那么废除这个指示。
もしそうなら正确的（= MODBUS协议タイプ；值为0x00），立即举例説明一个MODBUSトランザクション処理。

一个サーバー·サーバー可以距离説明的MODBUSトランザクション処理的最大数量由参数“NumberMaxOfTransaction”（系统或設定参数）来定义。

在无效的トランザクション処理的情况下，サーバー·サーバー生成一个MODBUSException Response（Exception Code6：サーバー·サーバー繁忙）。

もしトランザクション処理是有效的，它将被启动，以便存储下列信息：

用于送信指示的TCP连接标识符（由TCP管理给出）
MODBUSトランザクション処理ID（MBAP报文头中给出）
Unit identifier（MBAP报文头中给出）

然后，分解MODBUS PDU。首先分析機能コード：

当无效时，生成MODBUSException Response（Exception Code1：无效功能）
もし受信機能コード，サーバー·サーバー启动一个“MODBUS服务処理”Operation。

MODBUS服务処理

图17：MODBUS 服务処理操作流程图

根据后面实例中的デバイス软件和硬件構造，可以用不同的方式进行要求的MODBUS服务処理：

在一个小型デバイス或单线程体系構造内，MODBUSサーバー·サーバー可以直接アクセス用户应用データ，サーバー·サーバー自身可以本地処理要求的服务，而无需调用后台服务。

根据“MODBUSプロトコルの仕様”，进行这种処理。在出现エラー的情况下，生成MODBUSException Response。

在一个モジュール化的多処理器的デバイス或多线程体系構造中，“通信层”和“用户アプリケーション層”是2つ独立的实体，通信实体可以完全地処理一些不重要的服务，而其他的服务需要应用后台服务与用户应用实体协调完成。

为了実装与用户应用的交互作用，MODBUS后台服务必须执行すべての适当的机制，以便処理用户应用的トランザクション処理，并且正确管理用户应用调用和相应的レスポンス。

用户应用接口（后台接口）

在MODBUS后台服务中，可以执行几种策略来完成工作，虽然从用户网络吞吐量、接口带宽使用、応答時間、甚至设计工作量的角度，这几种策略是不均衡的。

MODBUS后台服务将对用户应用采用适当接口：

或基于串行链路的物理接口，或双口RAM方案，或一条简单的I/O电缆，或由オペレーティングシステム提供的基于报文传输服务的逻辑接口。
到用户应用的接口可以是同步的或异步的。

MODBUS后台服务还将使用适当的设计モード来得到/设定目标属性或触发服务。在某些情况下，一个简单的“ゲートウェイモード”将是足够的。在其他情况下，从简单的交換表历史到更复杂的重复机制中，设计者将必须执行带有高速缓存策略的“代理サーバー·サーバーモード”，。

MODBUS后台服务有责任実装协议的转换，以便与用户应用进行交互作用。因此，它必须具有机制来実装报文的分拆和重组、データ一致性保证以及すべての需要的同步等功能。

MODBUSレスポンス的生成

一旦処理リクエスト，MODBUSサーバー·サーバー必须使用适当的MODBUSサーバー·サーバートランザクション処理生成一个レスポンス，并且必须将レスポンス送信到TCP管理组件。

根据結果の処理，可以生成两类レスポンス：

肯定的MODBUSResponse：
レスポンス機能コード = リクエスト機能コード
MODBUSException Response：
目的是为客户机提供与処理过程检测到的エラー相关的信息
レスポンス機能コード = リクエスト機能コード+0x80
提供異常コード。来表明出错的原因。

Exception Code	MODBUSName	備考
01	非法的機能コード	サーバー·サーバー不機能の理解码
02	非法的データアドレス	与リクエスト有关
03	非法的データ值	与リクエスト有关
04	サーバー·サーバー故障	在执行过程中，サーバー·サーバー故障
05	Confirm	サーバー·サーバー接受服务调用，但是需要相对长的时间完成服务。因此，サーバー·サーバー仅戻る一个服务调用受信的確認。
06	サーバー·サーバー繁忙	サーバー·サーバー不能接受MODBUSRequestPDU。客户应用由责任决定是否和何时重发リクエスト。
0A	ゲートウェイ故障	ゲートウェイ路经是无效的。
0B	ゲートウェイ故障	目标デバイス没応答がある。。ゲートウェイ生成这个異常信息。

MODBUSResponsePDU必须以MBAP报文头做前缀，使用トランザクション処理正文中的データ生成MBAPmessage header。

Unit identifier

当在所收到的MODBUSリクエスト中给出ユニット标识符时，拷贝这个ユニット标识符，并将其存储在トランザクション処理的正文中。

Length

サーバー·サーバー計算MODBUS PDU和ユニット标识符字的大小。在“Length”域中に設置。这个值。

Protocol Identifier

設定协议标识符域为0x0000（MODBUSProtocol），在所收到的MODBUSリクエスト中给出协议标识符。

トランザクション処理标识符

設定这个域为“トランザクション処理标识符”值，它与初始リクエスト有关，并将其存储在。

利用トランザクション処理正文中存储的TCP连接位置合わせ确的MODBUS客户机戻るMODBUSResponse。当送信レスポンス时，トランザクション処理正文必须释空闲的。

実装ガイド

本章的目的是提出一个実装报文传输服务的实例。下面所説明的模型可用作客户机或サーバー·サーバー実装MODBUS报文传输服务过程的ガイド。

对象模型示意图

图18：MODBUS报文传输服务对象模型示意图

四种主要程序包构成对象模型示意图：

設定层，它設定和管理其它程序包组件的操作モード
TCP管理，它使TCP/IP栈和管理TCP连接的通信アプリケーション層连接。这指的是套接字接口的管理。
通信アプリケーション層，它由在一侧的MODBUS客户机和在另一侧的MODBUSサーバー·サーバー组成。该程序包和用户应用链接。
用户应用，它和デバイス应用相对应，它完全与デバイス有关，因此在本記事件中不予讨论。

本模型与実装的選択无关，例如：OSType、存储管理等。为保证这种无相关性，在TCP管理层和通信层之间以及在通信层和用户アプリケーション層之间使用普通界面层（generic Interface layers）。

有不同的実装方法実装该界面：两项任务之间的传输、共享存储器、串行链接界面、过程呼叫等。

为定义下面的実装模型，作了一些假定：

静态存储器管理
サーバー·サーバー的同步処理
処理有关すべての套接字受信的任务。

TCP管理程序包

图19：MODBUS TCP管理程序包

TCP管理程序包包括下列类：

ClnterfaceConnexion：该类的作用是管理用于连接的存储库。

CltemConnexion：该类含有説明连接所需要的すべての信息。

CTCPConnexion：该类提供自动管理TCP连接的方法（CStackTCP_IP提供接口套接字）。

CconnexionMngt：该类管理すべての连接，并経由CinterfaceindicationMsg和CinterfaceRoseponseMsg向MODBUSServer/MODBUS客户机リクエストの送信/Response。该类还処理接続の確立的アクセス控制。

CMBAP：该类提供读/写/分析MODBUS MBAP的方法。

CStackTCP_IP：该类执行套接字服务并提供栈的参数設定。

設定层程序包

图20：MODBUS設定层程序包

設定层程序包包括下列类：

TConfigreObject：该类将各组件相互設定所需的データ分组。用CoperatingMode类中的m_Confire方法填充这个構造。每个需要設定的类从这个对象中取得自己的データ。設定データ与実装本身有关。因此，提供该类的属性表作为一个实例。

CoperatingMode：该类的作用是填充TConfigueObject（根据用户的設定）和管理下述类的操作モード。

CMODBUSServer
CMODBUSClient
CconnexionMngt

通信层程序包

图21：MODBUS通信アプリケーション層程序包

通信アプリケーション層程序包包括以下各类：

CMODBUSServer：从CinterfaceIndicationMsg中受信MODBUS询问（経由m_ServerRecievingMessage方法）。该类的作用是根据询问建立MODBUSレスポンス或MODBUS異常（从网络进入）。该类実装MODBUSサーバー·サーバー的Graph State。只有类CoperatingMode送信了用户設定和正确的操作モード，才可能生成レスポンス。

CMODBUSClient：从类CinterfaceUserApplication中読み取りMODBUS询问，客户机的任务是用m_ClientReceivingMessage方法受信询问。该类実装MODBUS客户机的State Graph，并且管理链接带応答がある。的询问的トランザクション処理（来自网络的）。只有类CoperatingMode送信了用户設定和正确的操作モード，才能経由网络送信询问。

CTransaction：该类実装管理トランザクション的方法和構造。

接口类

CInterfaceUserApplication：该类表示与用户应用的接口，它提供两种アクセス用户データ的方法。在实际的実装中，根据硬件和软件デバイス的能力，用不同的方式実装这种方法（相当于一个终端驱动器、アクセスPCMCIA的实例、共享存储器等）。

CInterfaceIndicationMsg：该接口类用来从网络向MODBUSサーバー·サーバー送信询问，以及从网络向客户机送信レスポンス。该类使TCPManagement和通信アプリケーション層程序包连接（从网络中）。该类的実装与网络有关。

CInterfaceResponseMsg：该接口类用于从サーバー·サーバー接受レスポンス，以及从客户机向网络送信询问。该类使通信アプリケーション層程序包和TCPManagementconnect（向网络）。该类的実装和デバイス有关。

通信実装的类的示意图

下列类的示意图是一个完全的実装方案的示意图。

图22：类的示意图

序列图

下面説明了2つ序列图，以便説明客户机MODBUSトランザクション処理和サーバー·サーバーMODBUSトランザクション処理。

图23：MODBUS客户机序列图

为更好地理解客户机序列图，简单的注释为：

最初のステップ：读来自用户应用的询问(経由m_Read方法)。

第二のステップ：客户机的任务是受信MODBUS询问（経由m_ClientReceivingMessage方法）。这是客户机的进入点。为了使询问和相应的レスポンス相互协调，当得到询问时，客户机使用トランザクション処理リソース（类名：CTransaction）。経由呼叫类接口CInterfaceResponseMsg向TCP_ManagementsendMODBUS询问（経由m_MODBUSRequest方法）。

第三のステップ：如过已建立连接，并且必要なし。对连接做什么，那么経由网络送信报文。否则，在网络上可以送信报文之前，必须有开放的连接。

此时，客户机待機中最后讨论的レスポンス（来自远程サーバー·サーバー）。

第四のステップ：若从已经从网络得到レスポンス，那么TCP/IP栈受信データ（隐蔽地呼叫m_EventOnStack方法）。

もし已建立连接，那么读MBAP以恢复连接对象（连接对象提供存储リソース和其它信息）。

読み取り来自网络的データ，経由类接口CinterfaceIndicationMsg向客户机送信证实（経由m_MODBUSConfirmation方法）。客户机的任务是受信MODBUS证实（経由m_ClientReceivingResponse方法）。

最后，向用户应用写入レスポンス（経由m_Writedata方法），并且トランザクション処理リソース是空闲的。

下面是MODBUSサーバー·サーバー交換的实例：

图24：MODBUSサーバー·サーバー序列图

为更好地理解客户机序列图，简单的注释为：

最初のステップ：某客户机已経由网络送信了询问（MODBUS询问）。TCP/IP栈受信データ（隐蔽地呼叫m_EventOnSocket方法）。

第二のステップ：リクエスト可能是接続リクエスト，也可能ではない接続リクエスト（経由m_IsConnexionRequest方法）。もしリクエスト是接続リクエスト，那么分配连接对象和收发MODBUSフレーム的缓冲器（m_GetObjectConnexion）。之后，必须チェック和接受连接アクセス控制。

第三のステップ：もし询问是MODBUSRequest，那么可以读出完全的MODBUS Query（経由m_ReceiveData方法）。此时，必须分析MBAP（経由m_IsMdbHeadercorrect方法）。経由CInterfaceIndicationMessaging类向サーバー·サーバー任务（task）送信完全的フレーム（経由m_MODBUSIndication方法）。サーバー·サーバー的任务是受信MODBUS QUERY（経由m_ServerReceivingMessage方法）并加以分析。

もし有差错出现（未サポート的機能コード等），生成MODBUS異常フレーム形（m_BuildMODBUSException），否则生成レスポンス。

第四のステップ：経由CInterfaceResponseMessaging（経由m_MODBUSResponse方法）在网络上送信レスポンス。経由m_SendData方法进行对连接对象的処理（恢复连接説明符等），在网络上送信データ。

类和方法的説明

MODBUSサーバー側。的类

类名：CMODBUSServer

类名：CMODBUSServer

Stereotype実装类

提供用サーバー·サーバーモード管理MODBUS报文传输的方法

域综述
protected char	GlobalStateMODBUSサーバー·サーバー的ステータス

构造器综述
CMODBUSServer(TConfigureObject * lnkConfigureObject)构造器：生成内部对象

方法综述
protected void	m_InitServerFunctions(void )为填充功能阵列“m_ServerFunction”数列构造器呼叫的功能
bool	m_Reset(void )重新設定サーバー·サーバー的方法，もし重新設定，那么戻る肯定值
int	m_ServerReceivingMessage(TItemConnexion * lnkMODBUS)与CindicationMsg：：m_MODBUSIndication的接口，以从网络受信询问，如有問題，戻る否定值
bool	m_Start(void )启动サーバー·サーバー的方法，もし启动，戻る肯定值
bool	m_Stop(void )停止サーバー·サーバー的方法，もし停止，戻る肯定值
protected void	m_tServerMODBUS(void )サーバー·サーバー的MODBUS任务..

MODBUS客户机类

类名：CMODBUSClient

提供用客户机モード管理MODBUS报文传输的方法

Stereotype実装类

域综述
protected char	GlobalStateMODBUS客户机的ステータス

构造器综述
CMODBUSClient(TConfigureObject * lnkConfigureObject)构造器：生成内部对象，启动0变量

方法综述
Int	m_ClientReceivingMessage(TItemConnexion * lnkMODBUS)从アプリケーション層受信报文传输的接口：呼叫データの読み取り呼叫的CinterfaceUserApplication::m_Read 为トランザクション処理取得存储器的CInterfaceConnexion::m_GetObjectConnexion もし有問題，那么戻る否定值
Bool	m_Reset(空的)重新設定组件的方法，もし重新設定，戻る肯定值
bool	m_Start(空的)启动组件的方法，もし启动，戻る肯定值
bool	m_Stop(空的)停止组件的方法，もし停止，戻る肯定值
protected 空的	m_tClientMODBUS(空的)客户机的MODBUS任务....

接口的类

接口指示类

类名：CInterfaceIndicationMsg

直接已知的子类

CConnexionMngt

类名：CInterfaceIndicationMsg

从TCP_Management向MODBUSサーバー·サーバー或客户机送信报文的类

StereotypeInterface

方法综述
int	m_MODBUSConfirmation(TItemConnexion * lnkObject)受信进入レスポンス和呼叫客户机的方法：経由可用参照值、报文排队、远程过程呼叫等, ...
int	m_MODBUSIndication(TItemConnexion * lnkObject)读进入MODBUS询问和呼叫サーバー·サーバー的方法：経由可用参照值、报文排队、远程过程呼叫等, ...

接口レスポンス类

类名：CInterfaceResponseMsg

直接已知的子类：

CMODBUSClient、CMODBUSServer

class CInterfaceResponseMsg

从客户机或サーバー·サーバー向TCP_Management送信レスポンス或询问的类