MMS传输中的OSI 模型
- 格式：doc
- 大小：974.00 KB
- 文档页数：11
MMS传输的OSI模型一、MMS简介MMS（Manufacturing Message Specification）中文翻译为制造报文规范，在介绍MMS之前我们先简单科普一下IEC61850标准。
IEC61850是电力系统自动化领域唯一的全球通用标准，而本文主要介绍的MMS就是运用在IEC61850标准站控层和间隔层之间，MMS通过对实际设备进行面向对象建模方法，实现了网络环境下不同制造设备之间的互操作。
IEC61850标准将其引入电力自动化领域，其核心是将ACSI服务直接映射到MMS标准由于MMS是由ISO技术委员会184（TC184）开发和维护的一种涉及用来在设备或程序之间传送实时数据和监督信息的信息传递系统的国际标准，它的定义如下：每个设备中必须存在一组标准对象（standard objects），可以执行如，读写事件信令（event signaling）等操作。
VMD是主要对象，诸如变量，域，日志，文件等都属于VMD范围内。
在客户端和服务器站之间有一组用来监视或控制上述对象的一组标准信息。
一组用于在传输时将信息映射到位和字节的编码规则。
二、MMS协议栈与组成OSI协议与TCP协议栈对比如图1所示，MMS OSI的实现依赖与TCP/IP 的底四层。
图1 tcp与OSI协议栈对应关系图2 MMS协议栈MMS协议栈对应的TCP的应用层由图2可知，由TPKT、COTP、SESSION 、presentation、association control service、mms组成。
2.1、TPKT协议TPKT是一种“封装”协议。
它在其自己的数据包的数据有效载荷中携带OSI数据包，然后将结构传递给TCP，此后，该数据包将作为TCP / IP数据包进行处理。
将数据传递给TPKT的OSI程序不知道它们的数据将通过TCP / IP传输，因为TPKT模拟OSI协议传输服务访问点（TSAP）。
TPKT协议是应用程数据传输协议，介于TCP和COTP协议之间。
这是一个传输服务协议，主要用来在COTP和TCP之间建立桥梁。
Ethernet IP TCP TPKT COTP SESSION presentation association mmsversion Reserv length1B1B2B图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、SESSION、presentatiosn、association、mms协议的总长度，也就是TCP的payload的长度。
示例如图4所示。
图4 TPKT格式TPKT中的length=194，包含了TPKT的四个字节头部。
整个长度就是TC 的payload长度。
2.2、COTP协议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连接包的头结构为：1、0(Unsigned integer, 1 byte): Length，COTP后续数据的长度（注意：长度不包含length的长度），一般为17 bytes。
2、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，数据传输3、2~3 (Unsigned integer, 2 bytes): Destination reference.4、4~5 (Unsigned integer, 2 bytes): Source reference.5、6 (1 byte): opt，其中包括Extended formats、No explicit flow control，值都是Boolean类型。
6、7~? (length-7 bytes, 一般为11 bytes): Parameter，参数。
一般参数包含Parameter code(Unsigned integer, 1 byte)、Parameter length(Unsigned integer, 1 byte)、Parameter data三部分图5 cotp连接包格式图6为一个COTP连接请求包，type为0x0e。
图6 copt连接请求包示例COTP功能包结构如图7所示：Ethernet IP TCP TPKT COTP SESSION presentation association mmsLength type 1B1B opt1B图7 COTP功能包结构COTPP功能包的头结构为：1、0 (Unsigned integer, 1 byte): Length，COTP后续数据的长度（注意：长度不包含length的长度），一般为2 bytes。
2、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，数据传输3、2 (1 byte): opt，其中包括Extended formats、No explicit flow control，值都是Boolean类型。
图8 ctop 功能包结构示例三、MMS数据包结构与分析MMS包含四种数据包，分别是initiate-RequestPDU（启动-请求PDU）、confirmed-RequestPDU（确认-请求PDU）、initiate-ResponsePDU（启动-应答PDU）、confirmed-ResponsePDU（确认-应答PDU），接下来我们来详细的看一下这四种。
3.1、启动请求图9 启动请求数据包首先看一下这个包，我们可以看到它的组成有以下几个方面1、5~7 localDetailingCalling：本地详细呼叫，这个字节数不固定，取决于后面数字大小，根据国家规定通用MMS要求里写的这个值不应小于64，但推荐至少支持512个8位位组。
2、10 proposedMaxServOutstandingCalling：提出最大服务端呼叫，这个和下面部分内容都和confirmed-RequestPDU有着联系，具体放到下面再讲。
3、13 proposedMaxServOutstandingCalled：提出最大服务端被呼叫4、15 propodedDataStructureNestingLevel：预先编码的数据结构嵌套级别，下面简单提一下这个嵌套级别。
对于结构类型数据，如SEQUENCE OF内容Value字段中是一个或多个数据的TLV，形成分层结构，从外层开始层层嵌套最后嵌套成最简单的数据类型为止。
如下图所示。
图10 TVL结构最后一部分是MMSInitRequestDetail（MMS初始请求详细信息）主要由proposedVersionNumber、proposedParameterCBB、services Supported Calling组成，分别标识相关参数和服务支持的参数，我们着重看一下最后一部分，存在着identify、fileopen等参数，很明显这部分就是标记着全包内容的管理。
3.2、启动应答图11 启动应答示例initiate-ResponsePDU的体结构和initiate-RequestPDU相似，重复之处就不再多说了，这里重点看一下这几个部分。
negociatedMaxServoutstandingCalling：议最大服务端呼叫negociatedMaxServoutstandingCalling：议最大服务端被呼叫negociatedDataStructureNestingLevel：相关的数据结构嵌套级别我们可以发现，initiate-ResponsePDU的这三条和上面initiate-RequestPDU的内容是相对应的，这是因为initiate-ResponsePDU的作用就是对initiate-RequestPDU的内容进行应答，所以要将传递内容进行检测，这也是为什么连这三条后面参数也是一致的。
再看mmsInitResponseDetail的内容，前两条也是作为对之前内容回答，内容一致就不分析了。
直接看最后的serviceSupportedCalled，这一段内容里存在很多参数，主要作用就是对之前包中内容的回应，传递一个回复服务端呼叫的内容。
3.3、确认请求图12 确认请求invokeID：调用者ID，作为数据包唯一标识存在。
confirmedServiceRequest：确认服务请求，后接服务内容，如本次就是getNameList，像这样的服务还有诸如read、write、getVariableAccessAttributes、getNamedVariableListAttributes、fileOpen、fileRead、fileClose、fileDirectory接下来就是getNameList内容参数，如扩展对象类和扩展范围。
