当前位置：首页 > news >正文

IEC61850实现方案和测试-4-MMS协议

news 来源：原创 2025/7/16 15:41:05

IEC61850实现方案和测试-4作为介绍实现方案和测试的第四篇文章，后续会继续更新，欢迎关注。前三篇如下

第一篇是：IEC61850实现方案和测试-1-CSDN博客

第二篇是：IEC61850实现方案和测试-2-UCA-CSDN博客

第三篇是：IEC61850实现方案和测试-3-libiec61850-CSDN博客

IEC61850-7-2/3/4部分定义了抽象的信息模型和服务，并设计了抽象通信服务接口（ACSI），使信息模型和服务独立于底层通信协议和网络类型。通过特殊通信服务映射（SCSM），IEC61850将ACSI信息模型和服务映射到底层的通信协议（如应用层协议MMS）。除GOOSE、采样值SV和时间同步外，ACSI中大部分模型和服务都映射到MMS协议上，他们是IEC61850通信体系的核心内容。

1 MMS协议的通信框架

MMS协议是基于TCP/Ip之上的一个应用层协议，所以可分为服务器和客户端两部分，服务器提供对应的服务，客户端则请求服务，服务器和客户端的划分都只是逻辑上的，并不规定他们的物理位置，同一台设备，可能既具有服务器的功能，又具有客户端的功能。电力系统中，一般电力设备作为服务器server，主站作为客户端client。

MMS标准协议规范，主要包括9506-1[1]和9506-2[2]两个基本标准，需要可以下载。
链接: https://pan.baidu.com/s/1hET6WD7r9mTWySqEmdswIg 提取码: anmp

1.1 ISO/IEC 9506-1[1]：定义了服务规范

虚拟制造设备（VMD，Virtual Manufacturing Device）概念的引入和定义；
网络环境下各节点之间服务或报文的交换规则定义；
与VMD和服务有关的属性和参数的定义。
ISO9506-1定义了如下几大类服务：
环境及通用管理服务（Environment And General Management Services）；
虚拟制造设备支持服务（VMD Support Services）；
域管理服务（Domain Management Services）；
程序管理服务（Program Invocation Management Services）；
变量访问服务（Variable Access Services）；
信号量管理服务（Semaphore Management Services）；
操作员通信服务（Operator Communication Services）；
事件管理服务（Event Management Services）；
日志管理服务（Journal Management Services）。

1.2 ISO/IEC 9506-2[2]：定义了协议规法

报文的执行序列；
报文或编码的格式；
MMS层与OSI参考模型其它层的相互作用关系。

2 涉及相关协议

2.1 TPKT协议

TPKT协议是应用程数据传输协议，介于TCP和COTP协议之间。这是一个传输服务协议，主要用来在COTP和TCP之间建立桥梁。其英文介绍如下：TPKT is an "encapsulation" protocol. It carries the OSI packet in its own packet's data payload and then passes the resulting structure to TCP, from then on, the packet is processed as a TCP/IP packet. The OSI programs passing data to TPKT are unaware that their data will be carried over TCP/IP because TPKT emulates the OSI protocol Transport Service Access Point(TSAP).TPKT结构如图3：

图3 TPKT协议结构其中，TPKT的结构为：0 (Unsigned integer, 1 byte): Version，版本信息。1 (Unsigned integer, 1 byte): Reserved，保留(值为0x00)。2-3 (Unsigned integer, 2 bytes): Length，TPKT、COTP、S7三层协议的总长度，也就是TCP的payload的长度。举个例子，如图4所示：

图4 一个TPKT的例子从图4中可知，其version=3，length=25（0x0019）。

2.2COTP协议

COTP（ISO 8073/X.224 COTP Connection-Oriented Transport Protocol）是OSI 7层协议定义的位于TCP之上的协议。COTP以“Packet”为基本单位来传输数据，这样接收方会得到与发送方具有相同边界的数据。COTP协议分为两种形态，分别是COTP连接包（COTP Connection Packet）和COTP功能包（COTP Fuction Packet）。

COTP Connection PacketCOTP连接包（COTP Connection Packet）也就是S7Comm的握手包，其格式如图所示。

图COTP连接包的结构其中， COTP连接包的头结构为：0 (Unsigned integer, 1 byte): Length，COTP后续数据的长度（注意：长度不包含length的长度），一般为17 bytes。1 (Unsigned integer, 1 byte): PDU typ，类型有：0x1: ED Expedited Data，加急数据0x2: EA Expedited Data Acknowledgement，加急数据确认0x4: UD，用户数据0x5: RJ Reject，拒绝0x6: AK Data Acknowledgement，数据确认0x7: ER TPDU Error，TPDU错误0x8: DR Disconnect Request，断开请求0xC: DC Disconnect Confirm，断开确认0xD: CC Connect Confirm，连接确认0xE: CR Connect Request，连接请求0xF: DT Data，数据传输2~3 (Unsigned integer, 2 bytes): Destination reference.4~5 (Unsigned integer, 2 bytes): Source reference.6 (1 byte): opt，其中包括Extended formats、No explicit flow control，值都是Boolean类型。7~? (length-7 bytes, 一般为11 bytes): Parameter，参数。一般参数包含Parameter code(Unsigned integer, 1 byte)、Parameter length(Unsigned integer, 1 byte)、Parameter data三部分。算了，还是来个例子，更加明了：

图6 连接请求包图6中，PDU类型为连接请求（0x0e），表示该数据包是一个连接请求包。为了更好对比，图7为图6的连接请求的响应包：

图7 连接确认包

COTP Fuction Packet
相对而言，COTP Fuction Packet比COTP Connection Packet简单多了，其结构如图8所示：

图8 COTP功能包的格式其中， COTPP功能包的头结构为：0 (Unsigned integer, 1 byte): Length，COTP后续数据的长度（注意：长度不包含length的长度），一般为2 bytes。1 (Unsigned integer, 1 byte): PDU type，类型有：0x1: ED Expedited Data，加急数据0x2: EA Expedited Data Acknowledgement，加急数据确认0x4: UD，用户数据0x5: RJ Reject，拒绝0x6: AK Data Acknowledgement，数据确认0x7: ER TPDU Error，TPDU错误0x8: DR Disconnect Request，断开请求0xC: DC Disconnect Confirm，断开确认0xD: CC Connect Confirm，连接确认0xE: CR Connect Request，连接请求0xF: DT Data，数据传输2 (1 byte): opt，其中包括Extended formats、No explicit flow control，值都是Boolean类型。举个例子，如图9所示：

图9 数据传输包上图中，PDU类型为连接请求（0x0f），表示该数据包是一个数据传输的包。

3 设置wireshark mms解析

使用wireshark工具即可抓取mms协议报文，wireshark本省不会自动解析mms协议，需要在工具上进行如下设置。

3.1 选择“编辑”，打开“首选项”

3.2 选择Protocols栏目，找到“PRES”选项

3.3 选择Protocols栏目，找到“PRES”选项，添加设置

添加如下内容并保存，后续抓包即可使用wireshark mms协议解析功能

4 报文分析

报文来看mms协议共有tpkt cotp mms 下图为mms协议整体报文结构

之前的tpkt 和 cotp这一块的就不展开进行介绍了，可以自行去了解一下（我们主要是讲MMS这一层）

4.1 Initiate

发包

Byte[0] a8 消息的类型

Byte[1]26 mms消息的大小

Byte[2]80 LocalDetailCalling参数的类型

Byte[3]03 LocalDetailCalling参数的长度

Byte[4]-[6]04 e2 00 LocalDetailCalling本地详细信息调用参数的值这个字节数不固定取决于后面数字的大小

Byte[7]81 proposedMaxServOutstandingCalling参数的类型

Byte[8]01 proposedMaxServOutstandingCalling参数的长度

Byte[9]01 proposedMaxServOutstandingCalling译提出的最大服务端呼叫数值的值

Byte[10]82 proposedMaxServOutstandingCalled参数的类型

Byte[11]01 proposedMaxServOutstandingCalled的长度

Byte[12]01 proposedMaxServOutstandingCalled译提出的最大服务端被呼叫数值的值

Byte[13]83 proposedDataStructureNestingLevel 参数的类型

Byte[14]01 proposedDataStructureNestingLevel 参数的长度

Byte[15]05 proposedDataStructureNestingLevel 译预先编码的数据结构嵌套级别的值

Byte[16]a4 初始请求详细信息类型

Byte[17]16 初始请求详细信息的长度也就是以后的字节长度

Byte[18]80 proposedVersionNumber参数的类型

Byte[19]01 proposedVersionNumber 参数的长度

Byte[20]01 proposedVersionNumber 译提出的版本号的值

Byte[21]81 padding参数的类型

Byte[22]03 padding和proposedParmeterCBB的长度（这里为什么是两个参数的长度呢，因为Wireshark解析错了这俩个参数是在一个结构体内的）

Byte[23]05 padding 译填充的值

Byte[24][25] f1 00 proposedParmeterCBB 译提出的参数cbb

Byte[26] 82 padding或servicesSupportedCalling参数的类型

Byte[27]0c 自此往后的长度

Byte[28] 03 padding 译填充的值

Byte[29]-[39] servicesSupportedCalling服务支持的呼叫的值

回包

可以看到的是基本是一收一发所有的参数都是与发包时候对应那么就不在一个字节一个字节的阐述了

需要注意的是mms协议Wireshark解析的并不完整、有很多字节是没有解析到的，要注意观察，比如某某值的长度某某值的type都是没有解析到的。

4.2 Read

在介绍一个就够了，这些都是互通的，能认出来一个那么就能认出来其它的。

发包

上面的几层我就不截图了

这样看会直观一些，我现在点的是InvokeID这一块，他的值为04 d0 但是他前面还有a0 27 02 02 是在mms协议的结构体内但是Wireshark没有解析到，这种情况会很经常发生，基本上与我上面说的一样，type和length都没有解析到。

A0 也即为消息的类型 27也即为消息的长度那么02也即为Invokid的类型下一个02也即为Invokid的长度

我现在点击的是confirmedServiceRequest那么可以看到又有两个数值没有解析到 a4 与 21 直接拿之前的经验往上套那么a4 即为confirmedServiceRequest消息的类型 21即为confirmedServiceRequest消息的长度

Read是与confirmedServiceRequest一个结构体内所以他俩的数值是一样。

现在我点击的是 specificationWithResult 那么又可以看到遗留了两个数值80 与 01，80还是为specificationWithResult类型那么01即为mms.specificationWithResult消息的长度

按照这个找法其实这些都是一样的我就不继续往下阐述了。

回包

与发包也是一发一收没有很大的变化只是多了个读取到的数值

参考资料

https://www.cnblogs.com/Db2k/p/13267175.html