引言

范围

这个文件的范围是介绍TCP/IP上的MODBUS报文传输服务，提供参考信息以帮助软件开发者使用这种服务。这个文中不包括MODBUS功能码的编码内容，这些信息请参阅MODBUS协议规范[2]。

这个文件准确而全面地描述了MODBUS报文传输服务的实现。其目的是便于在那些使用MODBUS报文传输服务的设备之间进行可互操作。

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

• 在TCP/IP上的MODBUS协议概述
• MODBUS客户机、服务器和网关工具的功能描述
• 针对一个MODBUS实现实例的目标模型建议的实现准则。

客户机/服务器模型

MODBUS报文传输服务提供设备之间的客户机/服务器通信，这些设备联接在一个Ethernet（以太网） TCP/IP网络上。

这个客户机/服务器模式是基于4种类型报文：

• MODBUS 请求
• MODBUS 证实
• MODBUS 指示
• MODBUS 响应

MODBUS请求是客户机在网络上发送用来启动事务处理的报文

MODBUS指示是服务端接收的请求报文

MODBUS响应是服务器发送的响应信息

MODBUS证实是在客户端接收的响应信息

MODBUS报文传输服务（客户机/服务器模型）用于实时信息交换：

• 在两个设备应用程序之间
• 在设备应用和其它设备之间
• 在HMI/SCADA应用程序和设备之间
• 在一个PC和一个提供在线服务的设备程序之间

规范性引用文件

这章给出了在这个文件之前喜欢阅读的文件列表：

[2] MODBUS协议规范

[4] RFC1122

缩略语

ADU — 应用数据单元

IETF — 因特网工程工作组

IP — 互连网协议

MAC — 介质访问控制

MB — MODBUS

MBAP — MODBUS协议

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的请求/响应

在TCP/IP上使用一种专用报文头识别MODBUS应用数据单元。将这种报文头称为MBAP报文头（MODBUS协议报文头）。

这种报文头提供一些与串行链路上使用的MODBUS RTU应用数据单元比较的差别：

• 用MBAP报文头中的单个字节单元标识符取代MODBUS串行链路上通常使用的MODBUS从地址域。这个单元标识符用于设备的通信，这些设备使用单个IP地址支持多个独立MODBUS终端单元，例如：网桥、路由器和网关。
• 用接收者可以验证完成报文的方式设计所有MODBUS请求和响应。对于MODBUS PDU有固定长度的功能码来说，仅功能码就足够了。对于在请求或响应中携带一个可变数据的功能码来说，数据域包括字节数。
• 当在TCP上携带MODBUS时，即使将报文分成多个信息包来传输，办事在MBAP报文头上携带附加长度信息，以便接收者能识别报文边界。显式和隐式长度规则的存在以及CRC-32差错校验码的使用（在以太网上）将对请求或响应报文产生极小的未检出干扰。

MBAP报文头描述

MBAP报文头包括下列域：

报文头为7个字节长：

事务处理标识符：用于事务处理配对。在响应中，MODBUS服务器复制请求的事务处理标识符。

协议标识符：用于系统内的多路复用。通过值0识别MODBUS协议。

长度：长度域是下一个域的字节数，包括单元标识符和数据域。

单元标识符：为了系统内路由，使用这个域。专门用于通过以太网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设备可以提供一个客户机和/或服务器MODBUS接口。

可提供一个MODBUS后台接口，允许间接的访问用户应用对象。

此接口由四部分组成：离散量输入、离散量输出（线圈）、寄存器输入和寄存器输出。此接口与用户应用数据之间的映射必须加以定义（本地问题）。

• MODBUS客户机

MODBUS客户机允许用户应用清晰地控制与远端设备的信息交换。MODBUS客户机根据用户应用向MODBUS客户接口发送的需求中所包含的参数生成一个MODBUS请求。

MODBUS客户机调用一个MODBUS的事务处理，事务处理管理包括MODBUS证实的等待和处理。

• MODBUS客户机接口

MODBUS客户机接口提供一个接口，使得用户应用能够生成对包括访问MODBUS应用对象在内的各类MODBUS服务的请求。尽管在实现模型中以实例说明，但是MODBUS客户机接口（API）在这里不进行描述。

• MODBUS服务器

在收到一个MODBUS请求以后，模块激活一个本地操作进行读、写、或完成其他操作。这些操作的处理对应用程序开发人员来说都是透明的。MODBUS服务器的主要功能是等待来自TCP502口的MODBUS请求，处理这一请求，然后生成一个MODBUS应答，应答取决于设备状况（场境）。

• MODBUS后台接口

MODBUS后台接口是一个从MODBUS服务器到定义应用对象的用户应用之间的接口。

• TCP管理层

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

• 连接管理

在客户机和服务器的MODBUS模块之间的通信需要调用TCP连接管理模块。它负责全面管理报文传输TCP连接。

连接管理中存在两种可能：用户应用自身管理TCP连接，或全部由这个模块进行连接管理，而对用户应用透明。后一种方案灵活性较差。

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

• 访问控制模块

在某些至关重要的场合，必须禁止不需要的主机对设备内部数据的访问。这既是为什么需要安全模式，也是在需要时实现安全处理的原因。

• TCP/IP栈层

TCP/IP的栈可以进行参数配置，以便于使得数据流控制、地址管理和连接管理适应于特定的产品或系统的不同的约束。一般说来，BSD套接字接口就用来管理TCP连接。

• 资源管理和数据流控制

为了平衡MODBUS客户机与服务器之间进出报文传输的数据流，在MODBUS报文传输栈的所有各层均设置了数据流控制机制。资源管理和数据流控制模块首先是基于TCP内部数据流控制，附加数据链路层的某些数据流控制，以及用户应用层的数据流控制。

TCP连接管理

连接管理模块

总体描述

MODBUS通信需要建立客户机与服务器之间的TCP连接。

连接的建立可以由用户应用模块直接实现，也可以由TCP连接管理模块自动完成。

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

在第二种方案中，TCP连接管理完全不出现，用户应用仅需要发送和接受MODBUS报文。TCP连接管理模块负责在需要时建立新的TCP连接。

TCP客户机和服务器连接数量的定义不属于本文件的范畴（在本文中采用n）。根据设备能力，TCP连接的数量会不同。

实现规则：

• 如果没有明确的用户需求，建议采用自动的TCP连接管理
• 建议：打开并保持与远端设备的连接，而不要在每次MODBUS/TCP事务处理时打开和关闭连接。注：然而，MODBUS客户必须能够接收来自服务器的关闭请求，并关闭连接。当需要时，连接可以被重新打开。
• 建议：每一个MODBUS客户至少要打开与远端MODBUS服务器的TCP连接（同一IP地址）。一个应用建立一个连接是好的选择。
• 几个MODBUS事务处理可以在同一个TCP连接上被同时激活注：如果以此方式，MODBUS事务处理标识必须被用来唯一地识别请求与响应的匹配。
• 在两个远端MODBUS设备（一个客户机和一个服务器）之间双向通信的情况下，有必要为客户机数据流和服务器数据流分别建立连接。
• 一个TCP帧只能传送一个MODBUS ADU。建议：不要在同一个TCP PDU中发送多个请求或应答。

图7：TCP连接管理操作图

1． 显式TCP连接管理

用户应用模块负责管理所有的TCP连接：主动的和被动的连接建立、连接结束………。对客户机与服务器间所有的连接进行这种管理。BSD套接字接口用在用户应用模块中来管理TCP连接。这种方案提供了完全的灵活性，但也意味着应用开发人员要具备充分的有关TCP的知识。

考虑到设备的能力和需求，必须进行配置客户机与服务器间连接数的限制。

2． 自动TCP连接管理

TCP连接管理对用户应用模块是完全透明的。连接管理模块可以接受足够数量的客户机/服务器连接。否则，在超过所授权数量的连接时必须有一种实现机制。在这种情况下，我们建议：关闭最早建立的不使用的连接。

在收到第一个来自远端客户机或本地用户应用的数据包后，就建立了与远端对象的连接。如果一个网络进行终止或本地设备决定终止，此连接将被关闭。在接收连接请求时，访问控制选项可用来禁止未授权客户访问设备的可能性。

TCP连接管理模块采用栈接口（通常BSD套接字接口）来与TCP/IP栈进行通信。

为了保持系统需求与服务器资源之间的兼容，TCP管理将保持两个连接库。

• 第一个库（优先连接库）由那些从不被本地主动关闭的连接组成。必须提供一个配置来建立这个库。实现的原理是将这个库的每一个可能的连接与一个特定的IP地址联系起来。具有这个IP地址的设备被称为“标记的”。任何一个被“标记的”设备的新的连接请求必须被接收，并从优先连接库中取出。还有必要设置允许每个远端设备最多建立连接的数量，以避免同一设备使用优先连接库中所有的连接。
• 第二个库（非优先连接库）包括了非标记设备的连接。这里采用的规则是：当有来自非标记设备的新的连接请求，以及库中没有连接可用时，关闭早些时候建立的连接。

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

连接管理描述

• 连接建立

MODBUS报文传输服务必须在502口上提供一个侦听套接字，允许接收新的连接和与其他设备交换数据。

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

图8：MODBUS TCP/IP连接建立

如果客户机与服务器的连接数量大于授权的连接数量，则最早建立的无用的连接被关闭。激活访问控制机制检查远端客户机的IP地址是否是经过授权的。如果未经授权，将拒绝新的连接。

• MODBUS数据变换

基于已经打开的正确的TCP连接发送MODBUS请求。远端设备的IP地址用于寻找所建的TCP连接。在与同一个远端设备建立多个连接时，必须选择其中一个连接用于发送MODBUS报文，可以采取不同的选择策略，例如：最早的连接、第一个连接。在MODBUS通信的全过程中，连接必须始终保持打开。如同下列各章所描述的一样，一个客户机可以向一个服务器启动多个事务处理，而不必等待前序事物处理结束。

• 连接关闭

当客户机与服务器间的MODBUS通信结束时，客户机必须关闭用于通信的连接。

操作模式对TCP连接的影响

某些操作模式（两操作端点之间通信断开、一个端点的故障和重新启动、………）会对TCP连接产生影响。一个连接可被视为在这一侧关闭或异常终止而没有另一侧的确认，称这种连接为“半打开”的连接。

本章描述每种主要操作模式的特性。假设在连接的两端采用了“ 保持连接 ”TCP机制。

两操作端之间通信断开

通信断开的原因可以是服务器侧以太网连接电缆断开。预期的特性是：

• 如果在连接上没有正在发送数据包：

如果通信断开持续的时间短于“保持连接”计时器的值，将察觉不到通信断开。如果通信断开时间超过“保持连接”计时器的值，将一个错误返回到TCP连接层，由其复位连接。

• 如果在连接断开的前后发送一些数据包：

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

服务器端的故障和重新启动

在服务器故障和重新启动以后，客户端处于“半打开”连接状态。预期的特性是：

• 如果在半打开的连接上没有发送数据包：

只要“保持连接”计时器还在计时中，从客户端看，连接是半打开的。之后，将返回一个错误到TCP管理层，由其复位连接。

• 如果在半打开的连接上发送一些数据包：

服务器在不存在的连接上接收数据。TCP层的栈发送一个复位指令来关闭客户端的半打开的连接。

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

在客户机故障和重新启动以后，服务器侧处于“半打开”连接状态。预期的的状态是：

• 如果在半打开的连接上没有发送数据包：

只要“保持连接”计时器还在计时中，从服务器端看，这种连接是半打开的。之后，将返回一个错误到TCP管理层，由其复位连接。

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

必须分两种情况研究：

• 所打开的连接与服务器侧半打开的连接具有相同的特性（相同的源和目的口、相同的源和目的IP地址），所以，在连接建立超时后（伯克利实现的多数情况下为75ms），TCP栈层将不能打开连接。为了避免较长超时时间内不能进行通信，建议：在客户机端重新启动后，确保使用与原有连接不同的源口号建立连接。
• 所打开的连接与服务器侧半打开的连接具有不同的特性（不同的源口和相同的目的口、相同的源和目的IP地址），所以，在TCP栈层上打开连接，并向服务器侧的TCP管理层发送信号。

如果服务器侧TCP管理层仅支持一个远端客户机IP地址的连接，那么可以关闭原来的半打开的连接，使用新的连接。

如果服务器侧TCP管理层支持多个远端客户机IP地址的连接，那么新的连接保持打开状态，原来的连接也保持半打开状态，直到“保持连接”计时器计时结束，此时，将返回一个错误到TCP管理层。之后，TCP管理层将能够复位原有的连接。

访问控制模块

这个模块的目的是检查每一个新的连接，对照一个合法授权的远程IP地址列表，它可以授权或禁止一个远端客户机的TCP连接。

在至关重要的场合，应用开发人员需要选择访问控制模块来保证网络的访问。在这种情况下，需要对每个远端IP授权或禁止访问。用户需提供一个IP地址的列表，并特别注明每个IP地址是否合法授权。在缺省情况下，在安全模式中，用户未配置的IP地址均被禁止。所以，借助于访问控制模式，关闭来自未知的IP地址的访问连接。

TCP/IP栈的使用

TCP/IP栈提供了一个接口，用来管理连接、发送和接收数据，还可以进行参数配置，以使得栈的特性适应于设备或系统的限制。

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

对于更多的信息，建议阅读RFC 1122，这个RFC 1122为厂商和开发商提供了互联网通信软件的指南。RFC 1122详述了一个连接到互联网的主机必须采用的标准协议，以及一组明确的需求和选项。

栈接口一般是基于本文件中描述的BSD（伯克利软件分配代码）接口。

BSD套接字接口的应用

注：有些TCP/IP栈从性能考虑提出其他类型的接口。MODBUS客户机或服务器可以使用这些特定的接口，但是在本文件中对这种使用不做描述。

一个套接字是一个通信端点，它是通信中的基本构成块。通过套接字发送和接收数据可以执行一个MODBUS通信。TCO/IP库仅提供了使用TCP和提供基于连接的通信服务的流套接字。

socket()函数用来创建套接字。返回的一个套接字号被创建者用来访问套接字。套接字创建时没有地址（IP地址和口号）。直到一个口被绑定到该套接字时，方可接收数据。

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

为了初始化一个连接，客户端必须发送connect()函数来指定套接字号、远端IP地址和远端侦听口号（主动连接建立）。

为了完成连接，服务器端必须发送accept()函数指定以前在listen()调用中所指定的套接字号（被动连接建立）。一个新的套接字被创建，并具有与最初相同的特性。这个新的套接字连接到客户机的套接字，而将套接字号返回到服务器端。于是，释放初始套接字，以便为其他欲与服务器连接的客户机使用。

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

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

select()函数允许编程人员测试所有套接字上的事件。

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

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

图9：MODBUS信息交换

上图给出了客户机与服务器间的完整的MODBUS通信过程。客户机建立一个连接，向服务器发送3个MODBUS请求，而不等待第一个请求的应答到来。在收到所有的应答后，客户机正常地关闭连接。

TCP层参数配置

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

• 每个连接的参数

SO-RCVBUF, SO-SNDBUF:

这些参数允许为发送和接收用套接字接口设定高限位。可以通过调整这些参数来实现流量控制管理。接收缓存区的的大小即为每个连接advertised window的最大值。为了提高性能，必须增加套接字缓存区的大小。否则，这些值必须小于内部驱动器的资源，以便在内部驱动器的资源耗尽之前关闭TCP窗口。

接收缓存区大小取决于TCP窗口大小、TCP最大段的大小和接收输入帧所需的时间。由于最大段的尺寸为300个字（一个MODBUS请求需要最大256字+MBAP报文头）,如果需要3帧进行缓存，可将套接字缓存区大小调整为900字。为了满足最大的缓存需求和预定的时间，可以增加TCP窗口的大小。

TCP-NODELAY:

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

为了获得更好的实时特性，建议：将小量的数据直接发送，而不要试图将其收集到一个段内再发送。这就是为什么建议强制TCP-NODELAY选项，这个选项禁用客户机和服务器连接的“NAGLE算法”。

SO-REUSEADDR:

当MODBUS服务器关闭一个由远端客户启动的TCP连接时，在这个连接处于“时间等待”状态（两个MSL：最大段寿命）的过程中，该连接所用的本地口号不能被再次用来打开一个新的连接。

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

SO-KEEPALIVE:

TCP/IP协议缺省状态下，不通过空闲的TCP连接发送数据。因此，如果在TCP连接端这个过程没有发送数据，在两个TCP模块间就没有交换任何数据。这就假设客户机端应用和服务器端应用均采用计数器来探测连接的存活性，以便关闭连接。

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

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

• 整个TCP层的参数

TCP连接建立超时:

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

保持连接参数:

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

在一个空闲连接上发出保持连接试探的最大数是8次。如果发出最大试探次数之后而没有收到应答，TCP向应用发出一个错误信号，由应用来决定关闭连接。

超时与重发参数:

如果检测到一个TCP报文丢失，将重发此报文。检测丢失的方法之一是管理重发超时（RTO），如果没有收到来自远端的确认，超时终止。

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

如果已经估算出RTO，它将被用于下一个报文的发送。如果在估算的RTO终止之前没有收到下一个报文的确认，启用指数补偿算法。在一个特定的时间段内，允许相同报文最大次数的重发。之后，如果收不到确认，连接终止。

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

在TCP标准中定义了一些重发算法：

• Jacobson 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地址、子网掩码和省缺网关（不同于0.0.0.0）配置本地IP端。

通信应用层

MODBUS客户端

图10：MODBUS客户端

MODBUS客户端设计

MODBUS/TCP协议使得能够对一个客户端进行简单的设计。下图描述了客户端发送MODBUS请求并处理MODBUS应答的主要处理过程。

图11：MODBUS客户端操作示意图

一个MODBUS客户机可以接收三类事件：

• 一个来自用户应用的发送请求的新需求，在这种情况下，必须对MODBUS请求进行编码，并使用TCP管理组件服务通过网络进行发送MODBUS请求。下层（TCP管理模块）会返回一个错误信息，这些错误信息是由于TCP连接错误或其他错误信息所导致的。
• 来自TCP管理的一个响应，在这种情况下，客户端必须分析响应的内容，并向用户应用发送一个证实。
• 由于无响应而超时结束。可以通过网络发送一个重试电文，或向用户应用发送一个否定证实。

注：这些重试是由MODBUS客户机启动的，可以在无TCP确认的情况下由TCP层来进行其它类型的重试。

MODBUS请求的生成

在收到来自用户应用的需求后，客户端必须生成一个MODBUS请求，并发送到TCP管理。

可以将生成MODBUS请求分解成为几个子任务：

• MODBUS事务处理的实例化，使客户机能够存储所有需要的信息，以便将响应与相应的请求匹配，并向用户应用发送证实。
• MODBUS请求（PDU+MPAB报文头）的编码。启动需求的用户应用必须提供所有需要的信息，使得客户机能够将请求编码。根据MODBUS协议进行MODBUS PDU的编码（MODBUS功能码、相关参数和应用数据[2]）。填充MBAP报文头的所有域。然后，将MBAP报文头作为PDU前缀，生成MODBUS请求ADU。
• 发送MODBUS请求ADU到TCP管理模块，TCP管理模块负责对远端服务器寻找正确TCP的套接字。除了MODBUS ADU以外，还必须传递目的IP地址。

下图比图17更深入地描述了请求生成的过程。

图12：请求生成操作示意图

下面给出了实例：从地址为05的远端服务器读1个字的MODBUS请求ADU编码

• MODBUS请求ADU编码：

（*）参见MODBUS协议规范[2]

• 事务处理标识符

事务处理标识符用于将请求与未来响应之间建立联系。因此，对TCP连接来说，在同一时刻，这个标识符必须是唯一的。有几种使用此标识符的方式：

• 例如：可以作为一个带有计数器的简单“TCP顺序号”，在每一个请求时增加计数器；
• 也可以用作智能索引或指针，来识别事务处理的内容，以便记忆当前的远端服务器和未处理的请求。

通常，在MODBUS串行链路上，客户机必须一次发送一个请求。这意味着这个客户机在发送第二个请求之前必须等待对第一个请求的回答。在MODBUS TCP上，可以向同一个服务器发送多个请求而不需等待服务器的证实。MODBUS/TCP到MODBUS串行链路之间的网关负责保证这两种操作之间的兼容性。

服务器收接受的请求数量取决于其容量，即：服务器资源量和TCP窗口尺寸。同样，客户机同时启动事务处理的数量也取决于客户机的资源容量。这个实现参数称为“NnmberMaxofClientTransaction”，必须作为MODBUS客户机的一个特性进行描述。根据设备的类型，此参数取值为1～16。

• 单元标识符

在MODBUS或MODBUS+串行链路子网中对设备进行寻址时，这个域是用于路由的目的。在这种情况下，“Unit Identifier”携带一个远端设备的MODBUS从站地址：

– 如果MODBUS服务器连接到MODBUS+或MODBUS串行链路子网，并通过一个桥或网关配置地址这个服务器，MODBUS单元标识符对识别连接到网桥或网关后的子网的从站设备是必需的。目的IP地址识别了网桥本身的地址，而网桥则使用MODBUS单元标识符将请求转交给正确的从站设备。

– 分配串行链路上MODBUS从站设备地址为1～247（10进制），地址0作为广播地址。

对TCP/IP来说，利用IP地址寻址MODBUS服务器；因此，MODBUS单元标识符是无用的。必需使用值0xFF。

– 当对直接连接到TCP/IP网络上的MODBUS服务器寻址时，建议不要在“单元标识符”域使用有效的MODBUS从站地址。在一个自动系统中重新分配IP地址的情况下，并且如果以前分配给MODBUS服务器的IP地址又被指配给网关，使用一个有效的从站地址可能会由于网关的路由不畅而引起麻烦。使用无效的从站地址，网关仅是简单地废弃MODBUD PDU，而不会有任何问题。建议：在采用0xFF作为“单元标识符”的无效值。

注：0也可以用作与MODBUS/TCP设备直接通信。

处理MODBUS证实

在TCP连接中，当收到一个响应帧时，位于MBAP报文头中的事务处理标识符用来将响应与先前发往TCP连接的原始请求联系起来：

• 如果事务处理标识符没有提及任何未解决的事务处理，那么必须废弃响应；
• 如果事务处理标识符提及了未解决的事务处理，那么必须分解响应，以便向用户应用发送MODBUS证实（肯定的或否定的证实）；

分解响应就是检验MBAP报文头和MODBUS PDU的响应：

• MBAP报文头

在检验协议标识符必为0x0000以后，长度给出了MODBUS响应的大小。

如果响应来自直接连接到TCP/IP网络的MODBUS服务器设备，TCP连接识别码足以清晰地识别出远端服务器。因此，MBAP头中携带的单元标识符是无效的，必须废弃这个单元标识符。

如果将远端服务器连接在一个串行链路子网上，并且响应来自一个网桥、路由或网关，那么单元标识符（值≠0xFF）识别发送初始响应的远端MODBUS服务器。

• MODBUS响应PDU

必须检验功能码，根据MODBUS协议，分析MODBUS的响应格式：

• 如果功能码与请求中所用的功能码相同，并且如果响应的格式是正确的，那么，向用户应用发出MODBUS响应作为肯定的证实。
• 如果功能码是一个MODBUS异常码（功能码+80H），向用户应用发出一个异常响应作为肯定的证实。
• 如果功能码与请求中所用的功能码不同（= 非预期的功能码），或如果响应的格式是错误的，那么，向用户应用发出一个错误信号作为否定的证实。

注：肯定证实是指服务器收到请求命令并做出响应的证实。并不意味着服务器能够成功地完成请求命令中要求的操作（MODBUS异常响应指明执行操作失败）。

下图比图17更深入地描述了证实处理的过程。

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

超时管理

对MODBUS/TCP上事务处理所需响应时间有意不作规定。

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

从客户机的角度，超时必须考虑网络上预期的传输延迟，以便确定一个合理的响应时间。这种传输延迟可能是交换式以太网中的几个毫秒，或广域网连接中的几百毫秒。

反过来讲，任何客户机启动应用重试使用的超时时间应该大于预期的最大的合理响应时间。如果不遵循这一点，目标设备或网络就存在过度拥挤的潜在危险，而反过来会导致更多的错误。这是一个应该始终避免的特性。

因此，在实际中，在高性能应用中所使用的客户机超时似乎总是与网络拓扑和期望的客户机性能有关。

时间因素不很重要的系统经常采用TCP缺省值作为超时值，在多数平台上，几秒钟之后将报告通信故障。

MODBUS服务器端

图14：MODBUS服务器端

MODBUS服务器的作用是为应用对象提供访问以及为远端客户机提供服务。

根据用户应用，提供不同类型的访问：

• 简单访问：获得或设定应用对象的属性；
• 高级访问：启动一个特定的应用服务

MODBUS服务器必须：

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

在运行过程中，MODBUS服务器必须分析接收到的MODBUS请求，处理所需的操作，返回MODBUS响应。

MODBUS服务器设计

MODBUS服务器设计取决于如下两个方面：

• 对应用对象访问的类型（对属性的简单访问或对服务的高级访问）；
• MODBUS服务器与用户应用之间交互作用的类型（同步或异步）。

下图描述了服务器进行的主要处理过程，以便获得来自TCP管理的MODBUS请求，然后，分析请求，处理所需的操作，返回MODBUS响应。

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

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

• MODBUS服务器本身可以立即处理一些服务，没有与用户应用之间的交互作用；
• 一些服务还可能需要与被处理的用户应用进行明显的交互作用；
• 有些高级服务需要调用特定的接口，即：MODBUS后台服务。例如：可能根据用户应用层协议，使用若干个MODBUS请求/响应事务处理的时序来启动用户应用服务。后台服务负责所有单个MODBUS事务处理的正确进行，以便于执行全局用户应用服务。

在下列各章中给出更完整的描述。

MODBUS服务器可以接收并同时为多个MODBUS请求提供服务。服务器可以同时接收MODBUS请求的最大数量是MODBUS服务器的主要特性之一。这个数量取决于服务器的设计以及它的处理和存储能力。将这个实现参数称为“NumberMaxOfServerTransaction”，必须作为MODBUS服务器的一个特性描述这个实现参数。根据设备的能力，它的取值范围为：1～16，。

“NumberMaxOfServerTransaction”参数对MODBUS服务器的操作和性能有非常显著的影响。尤其重要的是，所管理的并发MODBUS事务处理的数量可能影响服务器对MODBUS请求的响应时间。

MODBUS PDU检验

下图描述了MODBUS PDU检验操作。

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

MODBUS PDU检验功能首先是分解MBAP报文头。必须检验协议标识符域：

• 如果与MODBUS协议类型不同，那么废除这个指示。
• 如果是正确的（= MODBUS协议类型；值为0x00），立即举例说明一个MODBUS事务处理。

一个服务器可以距离说明的MODBUS事务处理的最大数量由参数“NumberMaxOfTransaction”（系统或配置参数）来定义。

在无效的事务处理的情况下，服务器生成一个MODBUS异常响应（异常码6：服务器繁忙）。

如果事务处理是有效的，它将被启动，以便存储下列信息：

• 用于发送指示的TCP连接标识符（由TCP管理给出）
• MODBUS事务处理ID（MBAP报文头中给出）
• 单元标识符（MBAP报文头中给出）

然后，分解MODBUS PDU。首先分析功能码：

• 当无效时，生成MODBUS异常响应（异常码1：无效功能）
• 如果接收功能码，服务器启动一个“MODBUS服务处理”操作。

MODBUS服务处理

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

根据后面实例中的设备软件和硬件结构，可以用不同的方式进行要求的MODBUS服务处理：

• 在一个小型设备或单线程体系结构内，MODBUS服务器可以直接访问用户应用数据，服务器自身可以本地处理要求的服务，而无需调用后台服务。

根据“MODBUS协议规范”，进行这种处理。在出现错误的情况下，生成MODBUS异常响应。

• 在一个模块化的多处理器的设备或多线程体系结构中，“通信层”和“用户应用层”是两个独立的实体，通信实体可以完全地处理一些不重要的服务，而其他的服务需要应用后台服务与用户应用实体协调完成。

为了实现与用户应用的交互作用，MODBUS后台服务必须执行所有适当的机制，以便处理用户应用的事务处理，并且正确管理用户应用调用和相应的响应。

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

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

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

• 或基于串行链路的物理接口，或双口RAM方案，或一条简单的I/O电缆，或由操作系统提供的基于报文传输服务的逻辑接口。
• 到用户应用的接口可以是同步的或异步的。

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

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

MODBUS响应的生成

一旦处理请求，MODBUS服务器必须使用适当的MODBUS服务器事务处理生成一个响应，并且必须将响应发送到TCP管理组件。

根据处理结果，可以生成两类响应：

• 肯定的MODBUS响应：
• 响应功能码 = 请求功能码
• MODBUS异常响应：
• 目的是为客户机提供与处理过程检测到的错误相关的信息
• 响应功能码 = 请求功能码+0x80
• 提供异常码来表明出错的原因。

MODBUS响应PDU必须以MBAP报文头做前缀，使用事务处理正文中的数据生成MBAP报文头。

• 单元标识符

当在所收到的MODBUS请求中给出单元标识符时，拷贝这个单元标识符，并将其存储在事务处理的正文中。

• 长度

服务器计算MODBUS PDU和单元标识符字的大小。在“长度”域中设置这个值。

• 协议标识符

设置协议标识符域为0x0000（MODBUS协议），在所收到的MODBUS请求中给出协议标识符。

• 事务处理标识符

设置这个域为“事务处理标识符”值，它与初始请求有关，并将其存储在。

利用事务处理正文中存储的TCP连接对正确的MODBUS客户机返回MODBUS响应。当发送响应时，事务处理正文必须释空闲的。

实现指南

本章的目的是提出一个实现报文传输服务的实例。下面所描述的模型可用作客户机或服务器实现MODBUS报文传输服务过程的指南。

对象模型示意图

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

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

• 配置层，它配置和管理其它程序包组件的操作模式
• TCP管理，它使TCP/IP栈和管理TCP连接的通信应用层连接。这指的是套接字接口的管理。
• 通信应用层，它由在一侧的MODBUS客户机和在另一侧的MODBUS服务器组成。该程序包和用户应用链接。
• 用户应用，它和设备应用相对应，它完全与设备有关，因此在本文件中不予讨论。

本模型与实现的选择无关，例如：OS类型、存储管理等。为保证这种无相关性，在TCP管理层和通信层之间以及在通信层和用户应用层之间使用普通界面层（generic Interface layers）。

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

为定义下面的实现模型，作了一些假定：

• 静态存储器管理
• 服务器的同步处理
• 处理有关所有套接字接收的任务。

TCP管理程序包

图19：MODBUS TCP管理程序包

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

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

CltemConnexion：该类含有描述连接所需要的所有信息。

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

CconnexionMngt：该类管理所有连接，并通过CinterfaceindicationMsg和CinterfaceRoseponseMsg向MODBUS服务器/MODBUS客户机发送请求/响应。该类还处理连接建立的访问控制。

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：该接口类用于从服务器接受响应，以及从客户机向网络发送询问。该类使通信应用层程序包和TCPManagement连接（向网络）。该类的实现和设备有关。

通信实现的类的示意图

下列类的示意图是一个完整的实现方案的示意图。

图22：类的示意图

序列图

下面描述了两个序列图，以便说明客户机MODBUS事务处理和服务器MODBUS事务处理。

图23：MODBUS客户机序列图

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

第一步：读来自用户应用的询问(通过m_Read方法)。

第二步：客户机的任务是接收MODBUS询问（通过m_ClientReceivingMessage方法）。这是客户机的进入点。为了使询问和相应的响应相互协调，当得到询问时，客户机使用事务处理资源（类名：CTransaction）。通过呼叫类接口CInterfaceResponseMsg向TCP_Management发送MODBUS询问（通过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）。之后，必须检查和接受连接访问控制。

第三步：如果询问是MODBUS请求，那么可以读出完整的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报文传输的方法

MODBUS客户机类

类名：CMODBUSClient

类名：CMODBUSClient

提供用客户机模式管理MODBUS报文传输的方法

Stereotype实现类

接口的类

接口指示类

类名：CInterfaceIndicationMsg

直接已知的子类

CConnexionMngt

类名：CInterfaceIndicationMsg

从TCP_Management向MODBUS服务器或客户机发送报文的类

Stereotype接口

接口响应类

类名：CInterfaceResponseMsg

直接已知的子类：

CMODBUSClient、CMODBUSServer

class CInterfaceResponseMsg

从客户机或服务器向TCP_Management发送响应或询问的类

Stereotype接口

连接管理类

类名：CConnexionMngt

类名：CConnexionMngt

管理所有TCP连接的类

Stereotype 实现类

Modbus协议在TCP／IP上的实现指南

白银会员免费

黄金会员免费

资源价格 ¥0.00 销售数量 68 发布时间 2024年5月8日 更新时间 2024年5月8日

开通会员

已付费？登录 或 刷新