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堆棧

MMS位于ISO七層模型的應用層，其高度抽象，為了便于理解，我們可以將其分為兩層：ASCI層(Abstract Service Communication Interface)、MMS層(Manufacturing Message Specification)

?ASCI(Abstract Service Communication Interface)層定義了系統的邏輯功能,如：一個設備中有多少個邏輯設備、多少個邏輯節點，每個邏輯節點的屬性以及其支持的服務。

?ASCI(Abstract Service Communication Interface)層不關心客戶和服務器怎么通信，只關心服務器有哪些功能可以調用，哪些數據屬性可以獲取，哪些節點可以控制

?MMS層(Manufacturing Message Specification)定義了從ASCI到具體網絡通信的映射

?MMS層(Manufacturing Message Specification)不規定通信網絡類型，也不規定通信幀的具體格式，只規定通信幀的功能，通信模式

如: 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]：定義了服務規范

虛擬制造設備（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）。

3.1.2ISO/IEC 9506-2[2]：定義了協議規法

報文的執行序列；

報文或編碼的格式；

MMS層與OSI參考模型其它層的相互作用關系。

3.2領域配套標準：

ISO/IEC 9506-3，適用于工業機器人的通信服務和協議;

ISO/IEC 9506-4，適用于工業數字控制的通信服務和協議;

ISO/IEC 9506-5，適用于可編程控制器的通信服務和協議;

4.ISO/IEC 9506-6，適用于工業過程控制的通信服務和協議;

參考連接：工控安全MMS協議分析 - 51CTO.COM

總結

以上是生活随笔為你收集整理的MMS（Manufacturing Message Specification）协议分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。