面向服務(wù)端的變電站自主可控站控層服務(wù)協(xié)議一致性測試技術(shù)

鄭明忠，卜強生，高 磊，彭志強，張琦兵，盛 福

（1. 國網(wǎng)江蘇省電力有限公司電力科學(xué)研究院，江蘇 南京 211103；2. 國網(wǎng)江蘇省電力有限公司，江蘇 南京 210024；3. 東方電子股份有限公司，山東 煙臺 264000）

0 引言

IEC 61850 是智能電網(wǎng)以及智能變電站的核心標(biāo)準(zhǔn)，在我國的智能輸變配電領(lǐng)域得到了廣泛的應(yīng)用［1-2］。IEC 61850標(biāo)準(zhǔn)中定義的抽象通信服務(wù)接口ACSI（Abstract Communication Service Interface）可以映射到許多的協(xié)議［3-4］，目前我國的變電站站控層通信協(xié)議映射到制造報文規(guī)范MMS（Manufacturing Message Specification），但是存在很多的問題［5-6］，例如：MMS 的開發(fā)包嚴重依賴國外收費的軟件包，導(dǎo)致核心技術(shù)受制于人；MMS 的設(shè)計復(fù)雜，導(dǎo)致傳輸以及開發(fā)效率低。針對上述問題，文獻［7］提出了變電站二次系統(tǒng)通信報文規(guī)范CMS（Communication Message Specification），實現(xiàn)了IEC 61850 通信協(xié)議棧的完全自主可控。在通信服務(wù)映射的實現(xiàn)方面，CMS 協(xié)議直接將ACSI 映射到傳輸控制協(xié)議／網(wǎng)際協(xié)議TCP／IP（Transmission Control Protocol／Internet Protocol）協(xié)議棧，以提升服務(wù)的性能；基于IEC 61850-7-2 標(biāo)準(zhǔn)化ACSI的語法定義［8］，增加了安全認證，保證了客戶端與服務(wù)端雙方通信的安全，彌補了服務(wù)端對主站的支撐服務(wù)。在編碼方面，CMS 協(xié)議采用抽象記法1 ASN.1（Abstract Syntax Notation dot one）的壓縮編碼規(guī)則PER（Packed Encoding Rule）方式，以增強編／解碼以及數(shù)據(jù)傳輸?shù)男剩?］。

CMS 與MMS 都是基于IEC 61850-10［10］進行一致性測試的。與MMS 軟件包類似，前期我國檢測機構(gòu)較依賴于國外的MMS一致性測試工具（如DNV公司的UniCA sim61850simulator），該工具的使用成本高，同時所有測試用例采用VB 編寫且完全開源，測試用例不包含硬件設(shè)備的調(diào)用接口，自動化程度不足，被測智能設(shè)備和測試軟件系統(tǒng)之間沒有形成完全閉環(huán)，測試過程中需要測試人員手動調(diào)整多種物理量，影響了測試的效率。據(jù)此，我國開展了基于MMS 的一致性測試系統(tǒng)的研究與開發(fā)［11-12］，基于Python 腳本開發(fā)，封裝了測試用例庫，實現(xiàn)了一致性軟硬件的閉環(huán)測試，所涉及的軟件框架主要包括模型解析、測試用例模塊、系統(tǒng)配置模塊等［13］。在已有關(guān)于MMS 一致性測試工具研究的基礎(chǔ)上，本文根據(jù)CMS 的報文編碼規(guī)則特點，研究基于協(xié)議插件的CMS一致性測試技術(shù)。

CMS 與MMS 是ACSI 在底層通信協(xié)議映射的不同實現(xiàn)，本文分析了CMS 與MMS 協(xié)議的重要區(qū)別；對于部分擴展服務(wù)進行測試用例設(shè)計；同時，復(fù)用已有MMS 基于Python 開發(fā)的測試用例腳本，設(shè)計了基于協(xié)議插件的CMS 一致性測試方法，減少二次代碼開發(fā)，該方法利用基于第三方開源庫的協(xié)議插件，更完整地對CMS 語法結(jié)構(gòu)進行校驗，實現(xiàn)了從用例邏輯到語法、語義的全面測試；最后，基于該軟件框架，研發(fā)了CMS 一致性測試工具，為變電站站控層CMS實用化提供技術(shù)保障。

1 MMS與CMS的區(qū)別

MMS 與CMS 都是基于IEC 61850 標(biāo)準(zhǔn)將ACSI信息模型和服務(wù)映射到底層的通信協(xié)議［14］。在實踐與應(yīng)用過程中，IEC 61850 映射到MMS 與映射到CMS有較大的不同。

1.1 特定通信服務(wù)映射與模型映射

ACSI 自身不具備通信功能，沒有特定的報文格式和編／解碼語法，不能直接用于信息交換，需通過特定通信服務(wù)映射SCSM（Specific Communication Service Mapping）映射到底層通信協(xié)議。CMS 對于MMS的替代，兩者之間的最大區(qū)別體現(xiàn)在如下方面。

MMS協(xié)議需要對IEC 61850原有的模型與服務(wù)分別進行映射，需要對多個ACSI 中的服務(wù)與IEC 61850 中的模型進行分解并分別映射到某幾個服務(wù)與模型上。CMS 則是實現(xiàn)ACSI服務(wù)一一映射，在底層通信協(xié)議上將ACSI 直接映射到TCP／IP，在信息模型上則是直接應(yīng)用IEC 61850信息模型，無需進行轉(zhuǎn)換。MMS需要通過服務(wù)+模型的方式區(qū)分ACSI服務(wù)，而CMS 則通過應(yīng)用協(xié)議控制頭APCH（Application Protocol Control Header）的服務(wù)碼SC（Service Code）進行服務(wù)區(qū)分。例如：MMS需要通過有名變量中的路徑形式（如邏輯節(jié)點LN（Logical Node）路徑或數(shù)據(jù)對象DO（Data Object）路徑）與MMS 自身的讀服務(wù)實現(xiàn)ACSI 的GetLogicNodeDirectory 與GetData-Directory 服務(wù)；在控制類的服務(wù)中，需要新增SBOw、Oper、Cancle 等DO，與MMS 的寫服務(wù)共同實現(xiàn)ACSI中的Select-WithValue、Operate、Cancel等服務(wù)。

CMS 將ACSI 直接映射到TCP／IP 傳輸協(xié)議子集，無需進行中間的協(xié)議轉(zhuǎn)換（如MMS），所有設(shè)備廠家均可按照ASN.1語法文件以及PER進行協(xié)議開發(fā)，無需依賴國外的MMS 軟件開發(fā)包。CMS 進行ACSI的直接映射，所有服務(wù)都與ACSI中的服務(wù)一一對應(yīng)，包括關(guān)聯(lián)、服務(wù)器／邏輯設(shè)備LD（Logical Device）／LN、數(shù)據(jù)、數(shù)據(jù)集、定值、報告等，同時為了提高通信效率并實現(xiàn)遠程調(diào)用，進行了部分服務(wù)的擴展。

將模型DO 共同映射到MMS 中的有名變量，在生成有名變量結(jié)構(gòu)體時，映射算法會根據(jù)功能約束FC（Functional Constraint），對LN 中所有相同的FC數(shù)據(jù)屬性進行重組，構(gòu)成結(jié)構(gòu)體成員，即在樹形結(jié)構(gòu)上FC 高于DO。關(guān)于CMS 沒有數(shù)據(jù)模型映射的問題，為了提高通信效率，擴展讀所有數(shù)據(jù)定義的服務(wù)，可以實現(xiàn)某個LD 或者LN 下全部數(shù)據(jù)定義的一次性上送，此時在樹形結(jié)構(gòu)上FC 低于DO。在線初始化的過程中，通過Wireshark 進行報文解析時，CMS 數(shù)據(jù)結(jié)構(gòu)更貼近ACSI 原始模型結(jié)構(gòu)。MMS 與CMS映射上的具體區(qū)別如圖1所示。

圖1 MMS與CMS映射上的具體區(qū)別Fig.1 Specific differences in mapping between MMS and CMS

1.2 控制服務(wù)

MMS 進行了控制FC 的擴展，通過write 服務(wù)+信息模型擴展（對Pos 進行擴展，增加了SDI SBOw）實現(xiàn)了ACSI中帶值選擇服務(wù)映射；而CMS無需進行控制FC 擴展，其自身具備SelectWithValue 等控制服務(wù)，而控制服務(wù)本身的控制對象為DO（如Pos），在執(zhí)行服務(wù)時無法確認Pos.ctlVal的數(shù)據(jù)類型，為此，需要通過讀數(shù)據(jù)定義GetDataDefinition 服務(wù)的response+中返回CDCType獲取ctlVal的數(shù)據(jù)類型。

1.3 心跳報文

在MMS 中，只有客戶端能夠監(jiān)視服務(wù)端的通信是否中斷，具體方式是通過某些讀服務(wù)（如讀數(shù)據(jù)值服務(wù)）實現(xiàn)的，客戶端每隔一段時間發(fā)送讀服務(wù)檢查服務(wù)端是否返回；而CMS 擴展了TEST 服務(wù)，該服務(wù)僅有APCH，不包含應(yīng)用服務(wù)數(shù)據(jù)單元ASDU（Application Service Data Unit），同時能夠供服務(wù)端進行客戶端當(dāng)前通信狀態(tài)的判斷。

1.4 遠程過程調(diào)用

CMS 定義了一組擴展服務(wù)用于實現(xiàn)遠程調(diào)用，該組服務(wù)是一種通用化、自描述的接口和方法調(diào)用機制，可由客戶動態(tài)獲取接口和方法定義，根據(jù)定義動態(tài)組織發(fā)送數(shù)據(jù)并對返回的結(jié)果進行自動解析。主要包括讀遠程調(diào)用接口目錄服務(wù)、讀遠程調(diào)用方法目錄、讀遠程調(diào)用接口定義等。

1.5 關(guān)聯(lián)協(xié)商

MMS 將ACSI 中的關(guān)聯(lián)服務(wù)直接映射到MMS 的Initiate 服務(wù)中，在Initiate 服務(wù)中進行PDU size 以及所支持服務(wù)的協(xié)商；而CMS 中拆分了關(guān)聯(lián)服務(wù)和關(guān)聯(lián)協(xié)商服務(wù)，關(guān)聯(lián)協(xié)商服務(wù)不返回所支持服務(wù)類型，僅進行客戶端與服務(wù)端之間APDUsize 與ASDUsize的協(xié)商。

1.6 其他區(qū)別

1）CMS 還擴展了其他少量服務(wù)，提高了交互效率，如：讀所有控制塊值服務(wù)GetAllCBValues，列文件目錄服務(wù)GetFileDirectory。

2）CMS 的Reference 采用LD／LN.DO.DA 形式，而非MMS的LD／LN$FC$DO$DA形式。

3）CMS無擴展的控制塊DO。

4）CMS 無擴展的控制FC、緩存報告FC、非緩存報告FC、日志FC、通用面向變電站事件對象控制FC、通用變電站狀態(tài)事件控制FC、采樣值FC、多播采樣值控制FC、單播采樣值控制FC。

5）CMS 中SeriveError、AddCause 等ENUMER ATED類型數(shù)據(jù)的取值不同。

2 CMS一致性測試

IEC 61850 服務(wù)器一致性測試是智能電網(wǎng)中產(chǎn)品檢測的必測項目，能否通過服務(wù)器一致性檢測也是所有廠家互操作的基本要求。我國廠家主要根據(jù)《電力自動化通信網(wǎng)絡(luò)和系統(tǒng) 第10 部分：一致性測試》開展一致性測試。

一致性測試面向不同通信服務(wù)（如關(guān)聯(lián)協(xié)商、關(guān)聯(lián)、服務(wù)器／LD／LN、數(shù)據(jù)、數(shù)據(jù)集等）中的業(yè)務(wù)邏輯（可以是服務(wù)參數(shù)，也可以是服務(wù)交互邏輯）開展測試。除了關(guān)聯(lián)協(xié)商等擴展服務(wù)，一致性測試主要是面向ACSI 的一致性測試，與具體的SCSM 是弱相關(guān)的，但CMS 通信協(xié)議還需要驗證傳輸應(yīng)用層協(xié)議語法、語義的正確性。

2.1 基于Python asn1tools的底層編碼／解碼調(diào)用

CMS 在遵循PER［15］的基礎(chǔ)上對ACSI 進行具體實現(xiàn)，ACSI 原生接口與PER 構(gòu)成了CMS 的語法，基于變電站的信息模型（包括全站系統(tǒng)配置SCD（Substation Configuration Description）文件、IED 實例配置CID（Configured IED Description）文件、IED 能力描述ICD（IED Capability Description）文件等）傳遞具體信息內(nèi)容以構(gòu)成CMS的語義。

CMS 無需考慮向其他協(xié)議進行映射，在實現(xiàn)方面主要考慮語法的編碼／解碼，據(jù)此可以應(yīng)用Python 中的第三方庫asn1tools 實現(xiàn)底層服務(wù)協(xié)議開發(fā)，應(yīng)用庫中返回的錯誤原因進行語法的一致性測試，具體步驟如下：

1）根據(jù)CMS組裝ASN.1文件模塊；

2）導(dǎo)入ASN.1文件；

3）調(diào)用asn1tools進行數(shù)據(jù)編碼／解碼。

將數(shù)據(jù)傳入Python，將其映射到Python 相應(yīng)的數(shù)據(jù)類型，最終實現(xiàn)數(shù)據(jù)的解析。在CMS 中存在大量的數(shù)據(jù)結(jié)構(gòu)，例如sequence、sequence of、bit string、octer string 等，將其映射到Python 相應(yīng)的數(shù)據(jù)結(jié)構(gòu)［16-17］，如表1所示。

asn1tools 能夠?qū)崿F(xiàn)語法、語義的測試，當(dāng)編碼／解碼失敗時，會返回Ecoderror／Decoderror以及失敗原因。在CMS 的語法一致性測試的基礎(chǔ)上，根據(jù)導(dǎo)入的信息模型，解析配置文件，并對模擬器與被測設(shè)備信息交互報文進行語義一致性測試，語義一致性測試ACSI傳遞參數(shù)是否與信息模型完全一致。

目前，CMS 還在不斷地更新迭代，通過ASN.1 語法文件導(dǎo)入+第三方庫asn1tools 這種方式可大幅減少底層代碼的重復(fù)開發(fā)。

2.2 CMS一致性測試用例

目前，MMS 一致性測試用例主要參照文獻［18］設(shè)計，CMS 一致性測試用例與MMS 的主要區(qū)別在于底層編碼，而上層業(yè)務(wù)邏輯與交互機制并未發(fā)生變化，因此可以復(fù)用多數(shù)公用事業(yè)通信架構(gòu)（UCA）測試用例，對于少量擴展的服務(wù)而言，需要重新設(shè)計測試用例。

對于讀所有數(shù)據(jù)定義服務(wù)、讀所有控制塊值服務(wù)、列文件目錄服務(wù)、遠程過程調(diào)用系列服務(wù)以及Test 服務(wù)，雖然均為擴展后的服務(wù)，但是根據(jù)一致性測試用例的設(shè)計思想，可以套用其他測試用例的設(shè)計思路進行測試用例設(shè)計。

對于關(guān)聯(lián)協(xié)商服務(wù)，其涉及應(yīng)用協(xié)議數(shù)據(jù)單元（APDU）與ASDU是否協(xié)商生效以及協(xié)商如何設(shè)計能使其進行分幀傳輸問題，需要對其測試用例進行設(shè)計。關(guān)聯(lián)協(xié)商服務(wù)測試用例的設(shè)計流程圖見圖2。圖中：條件①是為了保證最終的報文能夠分幀傳輸；條件②和條件③是為了保證客戶端去協(xié)商是有效的協(xié)商，是一個邊界條件。具體步驟如下：

圖2 關(guān)聯(lián)協(xié)商服務(wù)測試用例的設(shè)計流程圖Fig.2 Flowchart of designing association negotiation service test case

1）在線用APDU、ASDU 最大值在線協(xié)商方式獲取被測設(shè)備（DUT）所支持的APDU 與ASDU 大小APDU_DUT、ASDU_DUT；

2）通過不同大小的APDU（APDU_new1、APDU_new2）、ASDU 與DUT 進行協(xié)商，檢查協(xié)商結(jié)果是否正確；

3）通過讀所有數(shù)據(jù)定義服務(wù)，獲取某LD下的所有數(shù)據(jù)定義，并獲取當(dāng)前的ASDU_SUM大小；

4）應(yīng)用ASDU_new1、APDU_new3與DUT關(guān)聯(lián)協(xié)商，其中30＜APDU_new3＜ASDU_new1＜ASDU_SUM；

5）通過讀所有數(shù)據(jù)定義服務(wù)（當(dāng)APDU＜ASDU時，應(yīng)分幀傳輸），獲取該LD 下的所有數(shù)據(jù)定義，檢查DUT是否按要求進行分幀傳輸。

3 一致性測試工具

根據(jù)《電力自動化通信網(wǎng)絡(luò)和系統(tǒng)第10 部分：一致性測試》，一致性測試工具的最小功能配置包括：①客戶端模擬器，用于關(guān)聯(lián)和產(chǎn)生雙邊應(yīng)用關(guān)聯(lián)TPAA（Two Party Application Association）報文；②測試主機，用于啟動／停止測試用例、分析和記錄測試結(jié)果；③協(xié)議分析儀，用于存儲所有測試用例的通信網(wǎng)絡(luò)的信息；④信號發(fā)生器，用于由測試主機或測試工程師控制產(chǎn)生數(shù)字量和模擬量的事件。基于此，設(shè)計一致性測試工具。

目前已有基于Python 腳本實現(xiàn)MMS 的一致性測試工具的應(yīng)用與一致性檢測。測試用例腳本庫經(jīng)過IEC 61850的大量檢測，應(yīng)用已相對成熟。

3.1 支持協(xié)議插件的一致性測試工具設(shè)計

CMS 測試用例腳本應(yīng)用協(xié)議插件設(shè)計思路，可復(fù)用多數(shù)MMS 一致性測試用例腳本［12］，減少用例腳本的重復(fù)開發(fā)。

目前，MMS 一致性測試主要采用跨平臺語言QT、Python 腳本、動態(tài)鏈接庫實現(xiàn)，其中動態(tài)鏈接庫封裝了MMS，即對MMS 的映射以及基本編碼規(guī)則BER（Basic Encoding Rule）的解碼與編碼進行封裝［11-13］。通過協(xié)議插件的軟件框架復(fù)用了Python 腳本庫，可實現(xiàn)測試用例腳本的邏輯調(diào)用。軟件開發(fā)上重新應(yīng)用ACSI抽象服務(wù)設(shè)計思維，在底層通過協(xié)議選擇開關(guān)選擇不同的協(xié)議插件進行一致性測試?；趨f(xié)議插件的一致性測試切換過程見圖3。

圖3 基于協(xié)議插件的一致性測試切換過程Fig.3 Switching process of consistency testing based on protocol plugins

基于協(xié)議插件的形式對ACSI 與具體映射進行解耦，滿足支持不同版本產(chǎn)品同時測試的需要。支持協(xié)議插件的通信協(xié)議測試技術(shù)以測試用例為對象，采用面向?qū)ο蠹夹g(shù)開發(fā)的測試代碼，利用系統(tǒng)引擎控制測試流程完成自動測試。對于功能相同而協(xié)議版本不同的被測設(shè)備而言，只需開發(fā)1 次測試代碼，代碼的重復(fù)利用率高，當(dāng)通信協(xié)議進行升級時，只需針對新增功能進行代碼開發(fā)和系統(tǒng)引擎維護，可擴展性強。

3.2 一致性測試工具的架構(gòu)

一致性測試工具包括軟件平臺與硬件平臺。其中：軟件平臺面向測試用例進行軟件功能設(shè)計；硬件平臺提供模擬量與開關(guān)量輸出，也支持面向通用對象的變電站事件GOOSE（Generic Object Oriented Substation Event）等提供數(shù)字量輸出，并向軟件平臺提供調(diào)用接口。同時，軟件平臺接收外部對時，實現(xiàn)與被測設(shè)備的時間同步。軟件和硬件平臺架構(gòu)見圖4。

圖4 軟件和硬件平臺架構(gòu)Fig.4 Architecture of software and hardware platform

軟件平臺主要包括測試用例模塊、實時測試信息打印模塊、狀態(tài)序列模塊、模型文件解析模塊、測試日志模塊、報文解析模塊以及客戶端模塊，具體架構(gòu)如圖5所示。

圖5 軟件平臺架構(gòu)Fig.5 Architecture of software platform

測試用例模塊對測試用例庫與服務(wù)接口進行抽象，以供MMS與CMS復(fù)用，測試用例腳本開放共享，使用者基于高度抽象化函數(shù)接口根據(jù)需求進行測試用例二次開發(fā)設(shè)計，構(gòu)建良好的測試用例開發(fā)生態(tài)。測試用例庫基于IEC 61850 Ed 2.0 一致性測試用例進行擴展設(shè)計，同時復(fù)用同類型測試用例。實時測試信息打印模塊不再單純打印測試過程信息，而是將測試過程的報文與測試步驟緊密耦合，便于快速定位測試問題。狀態(tài)序列模塊與傳統(tǒng)測試儀中輸出序列化的電壓、電流信號不同，其將通信服務(wù)接口加入測試儀輸出序列中，基于此設(shè)計可靈活實現(xiàn)部分開環(huán)測試用例。模型文件解析模塊實現(xiàn)對CID 文件的解析與校驗，在生成模型樹的前提下，根據(jù)配置參數(shù)的需要對模型文件中的路徑、數(shù)據(jù)類型進行分類，實現(xiàn)配置參數(shù)的快速檢索。測試日志模塊將測試日志與測試錯誤信息自動插入測試報告模板，實現(xiàn)測試報告的自動生成。報文解析模塊包括MMS報文解析與CMS 報文解析功能模塊。客戶端模塊包括MMS客戶端與CMS客戶端，同時通過多線程設(shè)計實現(xiàn)至少16 個客戶端并發(fā)運行，根據(jù)測試用例的需要并發(fā)不同的服務(wù)。

CMS一致性測試工具根據(jù)被測設(shè)備廠家填寫的標(biāo)準(zhǔn)協(xié)議實現(xiàn)一致性陳述PICS（Protocol Implementation Conformance Statements）、測試用協(xié)議實現(xiàn)額外信息PIXIT（Protocol Implementation eXtra Information for Testing）、模型實現(xiàn)一致性陳述MICS（Model Implementation Conformance Statements）及技術(shù)情況一致性陳述TICS（Technology Implementation Conformance Statements）文件自動生成不同測試用例的測試參數(shù)，并將其導(dǎo)入軟件中，測試用例腳本庫根據(jù)被測設(shè)備選擇協(xié)議類型并調(diào)用相關(guān)協(xié)議庫進行測試，根據(jù)測試用例的需要調(diào)用相關(guān)硬件進行閉環(huán)測試，在測試過程中實時抓取報文，并進行測試問題跟蹤定位，最終生成標(biāo)準(zhǔn)模板測試報告。一致性測試的具體流程如圖6所示。

圖6 一致性測試的具體流程Fig.6 Specific process of consistency testing

3.3 現(xiàn)場應(yīng)用

目前，CMS 一致性測試工具已被應(yīng)用于完成我國首套全自主可控變電站監(jiān)控系統(tǒng)出廠驗收測試，搭建的變電站監(jiān)控系統(tǒng)出廠驗收測試環(huán)境如圖7 所示，被測設(shè)備包括測控裝置、保護裝置等間隔層設(shè)備。測試用例涵蓋了應(yīng)用關(guān)聯(lián)測試、服務(wù)器LD／LN的DO 測試、數(shù)據(jù)集測試、定值組測試、報告測試、日志測試、控制測試、文件測試、取代測試。

圖7 測試環(huán)境Fig.7 Test environment

應(yīng)用CMS 一致性測試工具開展100多項測試用例測試，通過標(biāo)準(zhǔn)化的測試來保證支持CMS 協(xié)議被測設(shè)備的一致性、規(guī)范性，排除測試的隨機性和盲目性，并降低冗余、減少遺漏；同時CMS 一致性測試工具能使測試用例多次運行，具有可重復(fù)性，能完成人工測試因時間、運行環(huán)境而無法進行的測試，大幅提升測試效率。

但是經(jīng)測試發(fā)現(xiàn)存在如下問題。

1）在進行應(yīng)用關(guān)聯(lián)測試時，客戶端釋放關(guān)聯(lián)后，還能正常響應(yīng)其他服務(wù)；客戶端關(guān)聯(lián)必須使用IEDname.S1進行；APDUsize與ASDUsize的協(xié)商邏輯有誤。

2）在進行服務(wù)器LD／LN 的DO 測試時，讀LD目錄服務(wù)未指定ldName 的情況下，返回的是LN 的名稱，而不是LN的引用。

3）在進行報告測試時，timeOfEntry 的格式錯誤沒有按標(biāo)準(zhǔn)要求進行編碼。

4 結(jié)論

目前，CMS協(xié)議在我國已被逐步推廣應(yīng)用，但是我國廠商在進行CMS 協(xié)議開發(fā)時仍會受MMS 通信協(xié)議的影響。為此，本文詳細介紹了CMS 協(xié)議與MMS 協(xié)議的區(qū)別，為設(shè)備廠商的開發(fā)提供參考，同時利用模塊化開發(fā)的設(shè)計思想，設(shè)計了支持協(xié)議插件的一致性測試工具，該測試工具復(fù)用了MMS 的測試用例，對于基于Python 的MMS 一致性測試工具開發(fā)者而言，可以大幅減少抽象測試用例的重復(fù)開發(fā)工作量，為一致性測試工具開發(fā)提供了良好的設(shè)計思路。