MMS（Manufacturing Message Specification）协议分析

1、简介

MMS(Manufacturing Message Specification)中文翻译为制造报文规范，在介绍MMS之前我们先简单科普一下IEC61850标准。

IEC61850是电力系统自动化领域唯一的全球通用标准，而本文主要介绍的MMS就是运用在IEC61850标准站控层和间隔层之间，MMS通过对实际设备进行面向对象建模方法，实现了网络环境下不同制造设备之间的互操作。在2015年前MMS在电力系统远动通信协议中并未应用，但是IEC61850标准将其引入电力自动化领域，将其核心ACSI服务直接映射到MMS标准

由于MMS是由ISO技术委员会184(TC184)开发和维护的一种涉及用来在设备或程序之间传送实时数据和监督信息的信息传递系统的国际标准，它的定义如下。

每个设备中必须存在一组标准对象(standard objects)，可以执行如，读写事件信令(event signaling)等操作。

VMD是主要对象，诸如变量，域，日志，文件等都属于VMD范围内。

在客户端和服务器站之间有一组用来监视或控制上述对象的一组标准信息。

一组用于在传输时将信息映射到位和字节的编码规则。

IEC61850-MMS整体结构

•  和其他通信协议一样，IEC61850也可分为服务器和客户端两部分，服务器提供对应的服务，客户端则请求服务
• 服务器和客户端的划分都只是逻辑上的，并不规定他们的物理位置，同一台设备，可能既具务服务器的功能，又具务客户端的功能
• 服务器和客户端的通信也高度抽象，不规定服务具体怎样被调用的，只规定了服务接口，接口的实现由系统决定(可以为USB、Ethernet、当服务器和客户端位于同一台机器上也可直接进行内存拷贝)当前大部分以Ehternet为主

2、协议栈结构

MMS的协议栈。其实早在1990年就已经根据ISO / IEC 9506-1和ISO / IEC 9506-2两个标准进行了标准化，但是由于OSI的实施不是很简单，所以这个原始版本并没有流行。现在流行的MMS是于1999年波音公司根据互联网协议创建的全新版本。以下是新版MMS堆栈

1. MMS位于ISO七层模型的应用层，其高度抽象，为了便于理解，我们可以将其分为两层：ASCI层(Abstract Service Communication Interface)、MMS层(Manufacturing Message Specification)
2.  ASCI(Abstract Service Communication Interface)层定义了系统的逻辑功能,如：一个设备中有多少个逻辑设备、多少个逻辑节点，每个逻辑节点的属性以及其支持的服务。
3.  ASCI(Abstract Service Communication Interface)层不关心客户和服务器怎么通信，只关心服务器有哪些功能可以调用，哪些数据属性可以获取，哪些节点可以控制
4.  MMS层(Manufacturing Message Specification)定义了从ASCI到具体网络通信的映射
5.  MMS层(Manufacturing Message Specification)不规定通信网络类型，也不规定通信帧的具体格式，只规定通信帧的功能，通信模式
6. 如: MMS规定了一个通信帧需包含哪些内容，这些内容代表什么意义，而不规定这些内容以什么数据形式在网络上体现，因此可以采用不同的数据格式在各种网络上实现，但是服务和客户端要使用同样的数据格式和网络类型

协议包分析

2.1首先是TCP的三次握手，建立连接 

2.2接下来是两个COTP包：

        COTP简单的介绍一下，COTP(ISO 8073/X.224 COTP Connection-Oriented Transport Protocol)，翻译为面向连接的传输协议，这个协议的作用就是进行传输连接的建立，我们仔细观察上图中的两个COTP包，分别被标记为CR和CC,是connect request和connet confirm，功能就是COTP的连接包和返回包。

        2.2.1COTP Connection Packet

            

主要由如下的结构(前方数字代表对应字节)。

0 Length:无符号整型，1byte，用于标记COTP不包括length的后续内容长度，一般为17byte(但我看到的几个包都是14…)

1 PDU Type:无符号整型，1byte，标记状态，注意上图中这行后面的0x0e，代表连接请求，还有其他类型如下所示。

• 0×1: ED Expedited Data，加急数据
• 0×2: EA Expedited Data Acknowledgement，加急数据确认
• 0×4: UD，用户数据
• 0×5: RJ Reject，拒绝
• 0×6: AK Data Acknowledgement，数据确认
• 0×7: ER TPDU Error，TPDU错误
• 0×8: DR Disconnect Request，断开请求
• 0xC: DC Disconnect Confirm，断开确认
• 0xD: CC Connect Confirm，连接确认
• 0xE: CR Connect Request，连接请求
• 0xF: DT Data，数据传输
• 2~3 Destination reference:2bytes,目的地参照符，用来标识目标。
• 4~5 Source reference:2bytes,来源参考，用来标识来源。
• 6 option:1byte，其中有Extended formats和No explicit flow control,值是布尔型。
• 7~ parameter :参数，一般为11bytes,一般包含Parameter code,Parameter length,Parameter data三部分。

这些就是CR包的组成部分，接下来我们看看CC包

    2.2.2COTP Fuction Packet

其实这两个包并没有什么区别，我们对比一下这两个包，主要就是在PDU Type上由0x0e变成0x0d，标志着由连接包变成返回包

2.3MMS分析 

   我们能看到其中包括四种MMS包，分别是initiate-RequestPDU(启动-请求PDU)、confirmed-RequestPDU(确认-请求PDU)、initiate-ResponsePDU(启动-应答PDU)、confirmed-ResponsePDU(确认-应答PDU)

 2.3.1 initiate-RequestPDU

首先看一下这个包，我们可以看到它的组成有以下几个方面

• 5~7 localDetailingCalling: 本地详细呼叫，这个字节数不固定，取决于后面数字大小，根据国家规定通用MMS要求里写的这个值不应小于64，但推荐至少支持512个8位位组。
• 10 proposedMaxServOutstandingCalling：提出最大服务端呼叫，这个和下面部分内容都和confirmed-RequestPDU有着联系，具体放到下面再讲。
• 13 proposedMaxServOutstandingCalled: 提出最大服务端被呼叫
• 15 propodedDataStructureNestingLevel:预先编码的数据结构嵌套级别,下面简单提一下这个嵌套级别。

对于结构类型数据，如SEQUENCE OF内容Value字段中是一个或多个数据的TLV，形成分层结构，从外层开始层层嵌套最后嵌套成最简单的数据类型为止。如下图所示。

最后一部分是MMSInitRequestDetail(MMS初始请求详细信息)主要由proposedVersionNumber、proposedParameterCBB、services Supported Calling组成，分别标识 相关参数和服务支持的参数，我们着重看一下最后一部分，存在着identify、fileopen等参数，很明显这部分就是标记着全包内容的管理

2.3.2 initiate-ResponsePDU 

 initiate-ResponsePDU的内容，总体结构和initiate-RequestPDU相似，重复之处就不再多说了，这里重点看一下这几个部分。

• negociatedMaxServoutstandingCalling:议最大服务端呼叫
• negociatedMaxServoutstandingCalling：议最大服务端被呼叫
• negociatedDataStructureNestingLevel：相关的数据结构嵌套级别

我们可以发现，initiate-ResponsePDU的这三条和上面initiate-RequestPDU的内容是相对应的，这是因为initiate-ResponsePDU的作用就是对initiate-RequestPDU的内容进行应答，所以要将传递内容进行检测，这也是为什么连这三条后面参数也是一致的。

再看mmsInitResponseDetail的内容，前两条也是作为对之前内容回答，内容一致就不分析了。直接看最后的serviceSupportedCalled,这一段内容里存在很多参数，主要作用就是对之前包中内容的回应，传递一个回复服务端呼叫的内容。

2.3.3 confirmed-RequestPDU

     

• invokeID:调用者ID，作为数据包唯一标识存在
• confirmedServiceRequest：确认服务请求，后接服务内容，如本次就是getNameList,像这样的服务还有诸如read、write、getVariableAccessAttributes、getNamedVariableListAttributes、fileOpen、fileRead、fileClose、fileDirectory接下来就是getNameList内容参数，如扩展对象类和扩展范围

2.3.4 confirmed-ResponsePDU

   

基本内容和confirmed-Request一样，只是由confirmed-RequestPDU->confirmed-ResponsePDU、confirmedServiceRequest->confirmedServerResponse 

3、MMS标准协议规范

3.1、基本标准

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

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

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

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

3.2领域配套标准：

1. ISO/IEC 9506-3，适用于工业机器人的通信服务和协议;
2. ISO/IEC 9506-4，适用于工业数字控制的通信服务和协议;
3. ISO/IEC 9506-5，适用于可编程控制器的通信服务和协议;
4. 4.ISO/IEC 9506-6，适用于工业过程控制的通信服务和协议;

参考连接：工控安全MMS协议分析 - 51CTO.COM