黃曉胤，劉童童，朱永利

（1.冀北電力有限公司檢修分公司，北京市 房山區(qū) 102488；2.嘉興供電公司，浙江省 嘉興市 314100；3.新能源電力系統(tǒng)國(guó)家重點(diǎn)實(shí)驗(yàn)室(華北電力大學(xué))，河北省 保定市 071003）

0 引言

近些年來(lái)，各國(guó)陸續(xù)開(kāi)展了智能電網(wǎng)的研究工作[1-3]。智能電網(wǎng)提倡用信息技術(shù)徹底改造現(xiàn)有的能源利用體系，最大限度地開(kāi)發(fā)電網(wǎng)體系的能源效率，現(xiàn)已經(jīng)成為電力工業(yè)發(fā)展的方向和趨勢(shì)[4]。電力線路狀態(tài)檢測(cè)系統(tǒng)是智能電網(wǎng)的重要組成部分，建設(shè)電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)可以全面實(shí)施電力線路狀態(tài)檢修和全壽命周期管理，實(shí)現(xiàn)災(zāi)害多發(fā)區(qū)的環(huán)境參數(shù)和運(yùn)行狀態(tài)參數(shù)的集中實(shí)時(shí)監(jiān)測(cè)和災(zāi)害預(yù)警[5]。

以前國(guó)內(nèi)不同廠家的電力線路監(jiān)測(cè)裝置采用不同的標(biāo)準(zhǔn)，它們將采集到的信息發(fā)送給各自的后臺(tái)進(jìn)行數(shù)據(jù)處理，沒(méi)有形成一個(gè)統(tǒng)一的平臺(tái)，這限制了對(duì)線路監(jiān)測(cè)數(shù)據(jù)的利用。近10年來(lái)，國(guó)家電網(wǎng)公司認(rèn)為建設(shè)堅(jiān)強(qiáng)的智能電網(wǎng)必須有一個(gè)統(tǒng)一的數(shù)據(jù)處理平臺(tái)，陸續(xù)頒布了《輸變電設(shè)備狀態(tài)監(jiān)測(cè)系統(tǒng)技術(shù)導(dǎo)則》、《輸變電狀態(tài)監(jiān)測(cè)主站系統(tǒng)數(shù)據(jù)通信協(xié)議》和《輸電線路狀態(tài)監(jiān)測(cè)代理技術(shù)規(guī)范》[6-8]。狀態(tài)監(jiān)測(cè)代理匯集接入它的各類監(jiān)測(cè)裝置的數(shù)據(jù)，實(shí)現(xiàn)對(duì)監(jiān)測(cè)裝置的統(tǒng)一管理。

不同廠家的電力線路狀態(tài)監(jiān)測(cè)數(shù)據(jù)很難同時(shí)高效地接入檢測(cè)中心，目前監(jiān)測(cè)平臺(tái)采用 Web Service的方式實(shí)現(xiàn)這些數(shù)據(jù)的集成[9-10]。這樣的方式，雖然易于各廠家接入，但是嚴(yán)重降低了系統(tǒng)總體的性能。隨著智能電網(wǎng)建設(shè)的深入，電網(wǎng)所獲得的監(jiān)測(cè)數(shù)據(jù)日益增多[11]，這些海量監(jiān)測(cè)數(shù)據(jù)傳輸?shù)奖O(jiān)測(cè)中心，尤其是在極端天氣的情況下，報(bào)警數(shù)據(jù)井噴式出現(xiàn)，對(duì)監(jiān)測(cè)系統(tǒng)的性能提出了很高要求，現(xiàn)有的監(jiān)測(cè)系統(tǒng)無(wú)法滿足[12]。另外，風(fēng)電場(chǎng)的電力線路監(jiān)測(cè)數(shù)據(jù)的快速傳輸也十分重要，也正在引起發(fā)電企業(yè)的重視。結(jié)構(gòu)化數(shù)據(jù)是電力線路監(jiān)測(cè)數(shù)據(jù)的重要組成部分，通過(guò)這些數(shù)據(jù)可以掌握電力線路大體運(yùn)行情況，結(jié)構(gòu)化數(shù)據(jù)是監(jiān)測(cè)數(shù)據(jù)的基礎(chǔ)。本文結(jié)合電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)的需求，研究采用 Google公司的 Protocol Buffers[13-14]方法進(jìn)行電力線路監(jiān)測(cè)結(jié)構(gòu)化數(shù)據(jù)的傳輸，試圖替代目前電力線路監(jiān)測(cè)系統(tǒng)采用的傳輸效率低下的基于Web Service的監(jiān)測(cè)數(shù)據(jù)傳輸方法。

1 Protocol Buffers

1.1 Protocol Buffers簡(jiǎn)介

Protocol Buffers是Google公司2008年7月公布的一套靈活、高效、自動(dòng)化的數(shù)據(jù)描述語(yǔ)言，是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式，可以用于結(jié)構(gòu)化數(shù)據(jù)串行化，目前用于谷歌公司的幾乎所有設(shè)備間的通信。由于采用了特殊設(shè)計(jì)的編解碼機(jī)制，Protocol Buffers可以高效地實(shí)現(xiàn)數(shù)據(jù)的序列化和反序列化操作，同時(shí)Protocol Buffers采用二進(jìn)制編碼格式，能夠?qū)崿F(xiàn)數(shù)據(jù)的高效壓縮。Protocol Buffers具有語(yǔ)言中立、平臺(tái)無(wú)關(guān)、可擴(kuò)展的特性，只需使用Protocol Buffers對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行一次描述，便可以在不同的編程語(yǔ)言環(huán)境中使用。Protocol Buffers最新版的proto3已經(jīng)開(kāi)始支持 Java、C++、Python、Go、Ruby、Objective-C和 C#[15]。作為一種兼容性好、高效率的二進(jìn)制數(shù)據(jù)傳輸格式，Protocol Buffers常常用在數(shù)據(jù)存儲(chǔ)和遠(yuǎn)程過(guò)程調(diào)用(remote procedure call，RPC)方面。

1.2 Protocol Buffers工作原理

Protocol Buffers采用了非常緊湊的數(shù)據(jù)編碼壓縮方法，序列化后所生成的二進(jìn)制消息非常緊湊。對(duì)于整數(shù)型數(shù)據(jù)，Protocol Buffers采用Varint編碼方式。Varint是一種緊湊的表示數(shù)字的方法。傳統(tǒng)的整數(shù)型是以 32位來(lái)表示的，存儲(chǔ)需要 4個(gè)字節(jié)，當(dāng)整數(shù)大小在128以內(nèi)，Varint只需要用一個(gè)字節(jié)就可以表示這個(gè)整數(shù)，這樣就可以節(jié)省3個(gè)字節(jié)的存儲(chǔ)空間，當(dāng)然Varint表示數(shù)值大的數(shù)字時(shí)需要耗費(fèi)5個(gè)字節(jié)。統(tǒng)計(jì)發(fā)現(xiàn)，一般情況下工程實(shí)踐中大數(shù)字比較少，整體看來(lái)，采用Varint編碼后，可以用更少的字節(jié)數(shù)來(lái)表示數(shù)字信息[16]。

Varint中的每個(gè)字節(jié)的最高位為標(biāo)志位，剩下的7位表示具體的數(shù)字。最高位為1，表示后續(xù)的7位也是該數(shù)字的一部分，如果該位為0，則表示數(shù)字的結(jié)束。例如整數(shù) 300，Varint用 2個(gè)字節(jié)來(lái)表示：1010 1100 0000 0010，其編碼如圖1所示。

圖1 Varint編碼示意圖Fig. 1 Varint coding diagram

Protocol Buffers字節(jié)序采用小端對(duì)齊的方式，計(jì)算前需將2個(gè)字節(jié)的位置相互交換。二進(jìn)制1010101100轉(zhuǎn)化為十進(jìn)制是整數(shù)300。

對(duì)于整數(shù)數(shù)值為負(fù)的數(shù)字，Protocol Buffers會(huì)先采用Zigzag編碼，再采用Varint編碼以實(shí)現(xiàn)充分的壓縮。ZigZag編碼如表1所示。其編碼原理就是按照絕對(duì)值大小來(lái)重新解析二進(jìn)制，該編碼會(huì)將有符號(hào)整型映射為無(wú)符號(hào)整型，以便絕對(duì)值較小的負(fù)數(shù)仍然可以有較小的Varint編碼值。

其他的數(shù)據(jù)類型，采用標(biāo)簽加長(zhǎng)度(可選)加實(shí)際值的方式。例如對(duì)于字符串類型的數(shù)據(jù)，第1個(gè)Varint用來(lái)表示標(biāo)簽，第2個(gè)Varint表示該字符串長(zhǎng)度，然后將要表示的字符串緊跟其后。

表1 ZigZag編碼對(duì)照表Tab. 1 ZigZag coding table

消息經(jīng)過(guò)序列化后生成二進(jìn)制數(shù)據(jù)流，如圖 2所示。該流中的數(shù)據(jù)為一系列的鍵-值對(duì)。采用這種結(jié)構(gòu)無(wú)需使用分隔符來(lái)分割不同的Field，有助于節(jié)約消息本身的大小。

圖2 二進(jìn)制碼流Fig. 2 Binary stream

解碼過(guò)程是編碼過(guò)程的逆運(yùn)算。Protocol Buffers反序列化(解碼)通常由自身的框架代碼和編譯器共同完成，只需要簡(jiǎn)單的數(shù)學(xué)運(yùn)算、位移等。而可擴(kuò)展標(biāo)記語(yǔ)言(extensible markup language，XML)序列化通常需要完成詞法文法分析等大量消耗CPU的復(fù)雜計(jì)算，Protocol Buffers方式在編解碼方面效率更高。

2 電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)數(shù)據(jù)交換系統(tǒng)總體設(shè)計(jì)與實(shí)現(xiàn)

2.1 電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)簡(jiǎn)介

按照國(guó)家電網(wǎng)公司的規(guī)定，電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)總體架構(gòu)圖如圖3所示。

圖3 電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)總體架構(gòu)圖Fig. 3 Overall structure diagram of power line condition monitoring system

系統(tǒng)可分為3部分：主站系統(tǒng)、狀態(tài)監(jiān)測(cè)代理(condition monitoring agent，CMA)和狀態(tài)監(jiān)測(cè)裝置(condition monitoring device，CMD)。其中主站系統(tǒng)包含狀態(tài)接入網(wǎng)關(guān)機(jī)(condition acquisition gateway，CAG)。

主站系統(tǒng)通常接收前端系統(tǒng)傳輸來(lái)的各類狀態(tài)監(jiān)測(cè)信息，并進(jìn)行集中存儲(chǔ)、統(tǒng)一處理。CMA可接入不同類型、不同廠家的狀態(tài)監(jiān)測(cè)裝置，實(shí)現(xiàn)數(shù)據(jù)的標(biāo)準(zhǔn)化接入。CMD安裝在電力線路附近或之上，能自動(dòng)采集和處理被監(jiān)測(cè)設(shè)備的狀態(tài)數(shù)據(jù)。

電力線路狀態(tài)監(jiān)測(cè)主站系統(tǒng)中主站系統(tǒng)部署在國(guó)家電網(wǎng)公司總部和網(wǎng)省公司，各類狀態(tài)監(jiān)測(cè)裝置、CMA部署在變電站和電力線路上。

電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)從分層角度來(lái)看，可分為裝置層、接入層和主站層。I1接口實(shí)現(xiàn)監(jiān)測(cè)層與接入層之間的數(shù)據(jù)傳輸。I2接口實(shí)現(xiàn)接入層到主站層之間的數(shù)據(jù)傳輸。

隨著信息技術(shù)的發(fā)展，在未來(lái)電力線路監(jiān)測(cè)系統(tǒng)中，監(jiān)測(cè)裝置的數(shù)據(jù)處理和分析的大部分工作應(yīng)當(dāng)上移至監(jiān)測(cè)中心，這樣一方面可降低監(jiān)測(cè)裝置的資源配置，另一方面便于監(jiān)測(cè)數(shù)據(jù)處理和分析軟件的更新[12]。

線路監(jiān)測(cè)數(shù)據(jù)眾多，如環(huán)境溫度、濕度、風(fēng)速、風(fēng)向、雨量、氣壓、日照、風(fēng)偏角、傾斜角、桿塔它身傾斜角度、拉力等等，按照功能劃分，可以分為電氣類、機(jī)械類和運(yùn)行環(huán)境類。若要突出數(shù)據(jù)傳輸特點(diǎn)就必須將這些數(shù)據(jù)按照組織方式進(jìn)行分類，進(jìn)而按照其對(duì)應(yīng)的特點(diǎn)做有針對(duì)性的研究和處理。按照監(jiān)測(cè)數(shù)據(jù)的組織形式可以大致分類為結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。

結(jié)構(gòu)化數(shù)據(jù)也稱作行數(shù)據(jù)，是由二維表結(jié)構(gòu)來(lái)邏輯表達(dá)和實(shí)現(xiàn)的數(shù)據(jù)，主要通過(guò)關(guān)系型數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)和管理。在線路監(jiān)測(cè)數(shù)據(jù)方面，除音、視頻數(shù)據(jù)屬于非結(jié)構(gòu)化數(shù)據(jù)外，其他數(shù)據(jù)均屬于結(jié)構(gòu)化數(shù)據(jù)。本文就結(jié)構(gòu)化數(shù)據(jù)的高效傳輸方法進(jìn)行研究。

2.2 基于Protocol Buffers電力線路監(jiān)測(cè)數(shù)據(jù)傳輸方法的設(shè)計(jì)

數(shù)據(jù)傳輸模塊部署在CMA和監(jiān)測(cè)主站中，實(shí)現(xiàn)I2接口功能。在監(jiān)測(cè)主站，數(shù)據(jù)傳輸模塊位于系統(tǒng)底層，為上層應(yīng)用程序提供數(shù)據(jù)服務(wù)，同時(shí)滿足服務(wù)程序?qū)?shù)據(jù)性能的要求。采用Protocol Buffers后，監(jiān)測(cè)子站和監(jiān)測(cè)主站內(nèi)數(shù)據(jù)的傳輸與存儲(chǔ)都采用由Protocol Buffers編碼生成的二進(jìn)制數(shù)據(jù)格式，因此系統(tǒng)架構(gòu)應(yīng)該做相應(yīng)的調(diào)整，調(diào)整后的監(jiān)測(cè)主站(監(jiān)控中心)和監(jiān)測(cè)子站(狀態(tài)監(jiān)測(cè)代理)之間的通信連接示意圖如圖 4所示。從邏輯層面看，監(jiān)測(cè)主站和監(jiān)測(cè)子站均包含序列化和反序列化模塊以及數(shù)據(jù)傳輸模塊。數(shù)據(jù)在主站處理，存儲(chǔ)，因此主站還包含數(shù)據(jù)庫(kù)存儲(chǔ)模塊以及應(yīng)用模塊[17]。Buffers的格式編碼，分別形成相應(yīng)的.proto文件，如圖5所示。各個(gè)消息的簡(jiǎn)要內(nèi)容如表2所示。

圖4 電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)數(shù)據(jù)交換示意圖Fig. 4 Data exchange diagram of transmission line condition monitoring system

圖5 Protocol Buffers通信過(guò)程依賴的消息Fig. 5 Message types used by Protocol Buffers

表2 Protocol Buffers消息的功能和主要內(nèi)容Tab. 2 Functions and main contents of Protocol Buffers messages

從表2可見(jiàn)，uploadCACData消息用以上傳檢測(cè)數(shù)據(jù)。以數(shù)據(jù)上傳消息uploadCACData為例，采用Protocol Buffers結(jié)構(gòu)描述語(yǔ)言可表示為：

message uploadCACData

{

required string cacid=1;//cac唯一標(biāo)識(shí);

required int32 datanodenum=2;//監(jiān)測(cè)數(shù)組的數(shù)目

required string sensorid=3;//在線監(jiān)測(cè)裝置的唯一標(biāo)識(shí);

由于基于Protocol Buffers產(chǎn)生的數(shù)據(jù)不具有自我描述功能，為了檢測(cè)子站以及檢測(cè)主站對(duì)數(shù)據(jù)形成統(tǒng)一一致的解析，子站和主站都需要關(guān)聯(lián)Protocolbuf庫(kù)。

從監(jiān)測(cè)子站發(fā)往監(jiān)測(cè)中心的數(shù)據(jù)按照以下的過(guò)程傳遞和處理：

1）從監(jiān)測(cè)裝置收集到的數(shù)據(jù)，在數(shù)據(jù)編碼模塊，經(jīng)Protocol Buffers庫(kù)進(jìn)行序列化和反序列化操作，形成二進(jìn)制數(shù)據(jù)，然后將數(shù)據(jù)送入數(shù)據(jù)庫(kù)存儲(chǔ)，并且送往數(shù)據(jù)傳輸模塊。

2）在監(jiān)測(cè)子站，經(jīng)數(shù)據(jù)傳輸模塊進(jìn)行傳輸，傳輸至監(jiān)測(cè)主站。

3）主站數(shù)據(jù)傳輸模塊收到數(shù)據(jù)后，經(jīng)反序列化操作，解析出數(shù)據(jù)，然后把數(shù)據(jù)上交給上層應(yīng)用程序，同時(shí)把數(shù)據(jù)存入數(shù)據(jù)庫(kù)。

從監(jiān)控中心到監(jiān)控子站的過(guò)程和上述過(guò)程類似，不再贅述。

通信過(guò)程是基于消息的，消息分為7類：上傳心跳信息，上傳監(jiān)測(cè)數(shù)據(jù)，上傳配置信息，下發(fā)控制命令，獲取最新版本，獲取歷史版本，獲取更新文件。本文按照數(shù)據(jù)的作用，分別定義消息體。將通信過(guò)程中的 7種消息按照 Protocol

required string type=4;//監(jiān)測(cè)類型6位

required string equipmentid=5;

required string date=6;

required string name=7;//名字構(gòu)造required int32 value=8;//值

required bool alarm=9;//是否警告

}

Protocol Buffers規(guī)定每個(gè)屬性分別有3種規(guī)則：required、optional、repeated。required 表示該屬性在該消息中不能為空；optional表示該屬性在該消息中可以為空；repeated表示該屬性在該消息中可以有多個(gè)。每個(gè)屬性后面都有一個(gè)惟一的數(shù)字標(biāo)簽，這個(gè)數(shù)字標(biāo)簽用于在二進(jìn)制流中定位各個(gè)屬性。標(biāo)簽值不可重復(fù)。

電力線路狀態(tài)監(jiān)測(cè)系統(tǒng)長(zhǎng)期運(yùn)行后，由于設(shè)備更新等原因，需要對(duì)部分?jǐn)?shù)據(jù)結(jié)構(gòu)進(jìn)行更新以適應(yīng)新系統(tǒng)的要求。Protocol Bufferrs架構(gòu)具有良好的兼容性，只需簡(jiǎn)單的修改，便可以完成向下兼容；不能改變?nèi)魏我讯x的字段的標(biāo)簽值，不增加或刪除屬性為required的字段，刪除舊代碼中屬性為的optional字段或者屬性為repeated的字段，新增屬性為optional的字段和repeated的字段。這樣就可以在不破壞原有數(shù)據(jù)格式的前提下達(dá)到更新數(shù)據(jù)結(jié)構(gòu)的效果。

2.3 編程實(shí)現(xiàn)

根據(jù)2.2節(jié)所提方案，采用Java語(yǔ)言分別編寫各個(gè).proto文件。例如上傳數(shù)據(jù)信息使用protoc--java_out=E:java UpMsg.proto命令生成對(duì)應(yīng)的Java類。

經(jīng)過(guò)protoc編譯器編譯后，主要生成3類函數(shù)：getXXX()，setXXX()用以設(shè)置變量；系統(tǒng)函數(shù)，如 isInitialized()；檢查是否全部的 required數(shù)據(jù)域都被設(shè)置；序列化函數(shù)和反序列化函數(shù)。

使用Protocol Buffers編程實(shí)現(xiàn)數(shù)據(jù)交換，首先在項(xiàng)目中引入 protobuf-Java包，然后把編譯.proto生成的類拷貝到項(xiàng)目。這樣就可以在項(xiàng)目對(duì)其進(jìn)行操作了。調(diào)用writeto()方法實(shí)現(xiàn)數(shù)據(jù)的序列化，并寫入輸出流，該過(guò)程的代碼如下所示。

UpMsg.Up xxg=upBuilder.build();

ByteArrayOutputStream output =

new ByteArrayOutputStream();

xxg.writeTo(output);

數(shù)據(jù)通過(guò)流傳輸?shù)浇邮斩?，接收端通過(guò)調(diào)用parseFrom()方法實(shí)現(xiàn)數(shù)據(jù)的反序列化，該過(guò)程的代碼如下所示。

ByteArrayInputStream input =

new ByteArrayInputStream(byteArray);

UpMsg.Up xxg2 =

UpMsg.Up.parseFrom(input);

在CMA端，采用面向?qū)ο蟮腏ava語(yǔ)言來(lái)實(shí)現(xiàn)，數(shù)據(jù)以對(duì)象的形式組織，數(shù)據(jù)經(jīng) Protocol Buffers序列化后生成比特流文件，以上傳監(jiān)測(cè)數(shù)據(jù)消息為例。序列化后生成比特流用ASCII碼表示如下：DC126m00090990000987DLESOHSUBD C126m00090990000987”ACK021005*DC126m00 0909900009972DC32017-04-2722:10:12SOOil Temperature@PHSOH。數(shù)據(jù)經(jīng)過(guò)傳輸，在 CAG端接收并且反序列化，在控制臺(tái)調(diào)用get ()方法得到序列化后的數(shù)據(jù)信息，可以在服務(wù)器端顯示。

3 基于Protocol Buffers的結(jié)構(gòu)化數(shù)據(jù)傳輸方案性能測(cè)試

數(shù)據(jù)交換系統(tǒng)的功能主要在于實(shí)現(xiàn)數(shù)據(jù)的傳輸，所以測(cè)試應(yīng)從序列化和反序列化用時(shí)以及序列化后所生成文件大小2方面進(jìn)行測(cè)試。選作對(duì)比的是國(guó)家電網(wǎng)公司標(biāo)準(zhǔn)Web Service方式所采用的XML方法。

3.1 測(cè)試環(huán)境

本測(cè)試使用的軟硬件環(huán)境如表3、表4所示。

表3 硬件配置Tab. 3 Hardware Configuration

表4 軟件配置Tab. 4 Software Configuration

3.2 性能測(cè)試

用以實(shí)現(xiàn)數(shù)據(jù)上傳的 uploadCMAData消息的Protocol Buffers實(shí)現(xiàn)方式和XML實(shí)現(xiàn)方式實(shí)現(xiàn)方式對(duì)比如表5所示?？梢悦黠@看到，在傳遞相同信息情況下，Protocol Buffers方式需要傳遞的數(shù)據(jù)比XML方式少。

表5 uploadCMAData消息實(shí)現(xiàn)方式對(duì)比Tab. 5 Contrast of uploadCMAData message implementation

3.2.1 序列化時(shí)耗

本測(cè)試將消息uploadCMAData，分別序列化以10、100、1000、10000次，測(cè)試用時(shí)。

序列化時(shí)耗對(duì)比測(cè)試結(jié)果如表6所示。從表可以看出，采用Protocol Buffers方式序列化數(shù)據(jù)有明顯的優(yōu)勢(shì)，而且序列化數(shù)據(jù)量越大，優(yōu)勢(shì)越明顯。

表6 序列化時(shí)耗對(duì)比Tab. 6 Comparison of serialization time consumption ms

3.2.2 反序列化時(shí)耗

XML反序列化采用 JAXB中 Unmarshaller接口實(shí)現(xiàn)，從XML序列中解碼為Java對(duì)象。

反序列化時(shí)耗對(duì)比測(cè)試結(jié)果如表7所示?？梢钥闯觯翰捎肞rotocol Buffers方式反序列化數(shù)據(jù)有明顯的優(yōu)勢(shì)，而且序列化數(shù)據(jù)量越大，優(yōu)勢(shì)越明顯。反序列化是序列化的逆操作，他們?cè)跁r(shí)耗趨勢(shì)上趨于相同。

表7 反序列化時(shí)耗對(duì)比Tab. 7 Deserialization time consumption comparison ms

3.2.3 序列化后文件大小

uploadCMAData 以XML方式序列號(hào)后文件大小為378byte ，而以Protocol Buffers方式序列化后文件大小僅108byte。

其余消息序列化數(shù)據(jù)量如圖6所示。從圖中可見(jiàn)，Protocol Buffer方式序列化后生成的數(shù)據(jù)量也比XML方式生成的數(shù)據(jù)量少很多。

圖6 數(shù)據(jù)量分析Fig. 6 Data volume analysis

3.2.4 實(shí)驗(yàn)結(jié)果分析

經(jīng)過(guò)上述測(cè)試可見(jiàn)，將Protocol Buffers應(yīng)用到電力線路監(jiān)測(cè)數(shù)據(jù)傳輸上，可以提高數(shù)據(jù)交換效率：在時(shí)間方面，Protocol Buffers將監(jiān)控?cái)?shù)據(jù)編碼為二進(jìn)制格式。編解碼過(guò)程只需通過(guò)簡(jiǎn)單的移位操作即可完成，速度非常快；在空間方面，Protocol Buffers設(shè)計(jì)的特殊的編碼機(jī)制，生成的二進(jìn)制數(shù)據(jù)有更高的空間利用率，同時(shí)也降低了傳輸帶寬要求。

在整體效率方面，Protocol Buffers相比于國(guó)家電網(wǎng)公司采用的基于XML的Web Service方式有明顯的優(yōu)勢(shì)，一般而言，采用Protocol Buffers方式文本比XML要小3～10倍，而解析效率卻提升了20～100倍。

另外，Protocol Buffers兼容性強(qiáng)、擴(kuò)展性強(qiáng)。Protocol Buffers最早的版本只支持JAVA、C++和Python三種編程語(yǔ)言，最新版本proto3已經(jīng)開(kāi)始支持Go、Ruby、Objective-C以及C＃。Protocol Buffers不僅支持Windows平臺(tái)，而且支持Linux平臺(tái)，為電力線路在線監(jiān)測(cè)系統(tǒng)的跨平臺(tái)、跨語(yǔ)言建設(shè)提供了支持?；赑rotocol Buffers的電力線路監(jiān)測(cè)系統(tǒng)在需要改變數(shù)據(jù)結(jié)構(gòu)進(jìn)行升級(jí)時(shí)，不需要對(duì)原來(lái)定義的結(jié)構(gòu)進(jìn)行重新編寫，只需要在不更改字段標(biāo)簽和required字段的前提下，在消息結(jié)構(gòu)定義中增加或者刪除optional、repeated字段。這給系統(tǒng)的后期升級(jí)維護(hù)帶來(lái)極大的方便。

4 結(jié)論

Protocol Buffers是Google公司較新的已廣泛使用的開(kāi)源數(shù)據(jù)壓縮技術(shù)，在效率、兼容性和擴(kuò)展性等方面有著明顯的優(yōu)勢(shì)。論文圍繞 Protocol Buffers技術(shù)的原理，結(jié)合國(guó)家電網(wǎng)公司對(duì)數(shù)據(jù)傳輸?shù)囊?，深入分析了結(jié)構(gòu)化數(shù)據(jù)的傳輸方法，提出了基于Protocol Buffers的電力線路監(jiān)測(cè)數(shù)據(jù)傳輸方案，并采用Java語(yǔ)言編程實(shí)現(xiàn)了線路監(jiān)測(cè)的結(jié)構(gòu)化數(shù)據(jù)的傳輸，并通過(guò)數(shù)據(jù)傳輸實(shí)驗(yàn)證明采用所提的Protocol Buffers實(shí)現(xiàn)結(jié)構(gòu)化數(shù)據(jù)的傳輸，比采用基于XML的Web Service方式在時(shí)間和空間上更加高效，更適應(yīng)智能電網(wǎng)建設(shè)的需要。