電力線路狀態(tài)監(jiān)測結(jié)構(gòu)化數(shù)據(jù)交換方法研究

黃曉胤，劉童童，朱永利

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

0 引言

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

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

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

1 Protocol Buffers

1.1 Protocol Buffers簡介

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

1.2 Protocol Buffers工作原理

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

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

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

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

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

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

表1 ZigZag編碼對照表Tab. 1 ZigZag coding table

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)構(gòu)化數(shù)據(jù)也稱作行數(shù)據(jù)，是由二維表結(jié)構(gòu)來邏輯表達(dá)和實現(xiàn)的數(shù)據(jù)，主要通過關(guān)系型數(shù)據(jù)庫進(jìn)行存儲和管理。在線路監(jiān)測數(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)測數(shù)據(jù)傳輸方法的設(shè)計

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

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

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

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

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

message uploadCACData

{

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

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

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

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

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

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

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

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

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

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

required string type=4;//監(jiān)測類型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ī)定每個屬性分別有3種規(guī)則：required、optional、repeated。required 表示該屬性在該消息中不能為空；optional表示該屬性在該消息中可以為空；repeated表示該屬性在該消息中可以有多個。每個屬性后面都有一個惟一的數(shù)字標(biāo)簽，這個數(shù)字標(biāo)簽用于在二進(jìn)制流中定位各個屬性。標(biāo)簽值不可重復(fù)。

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

2.3 編程實現(xiàn)

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

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

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

UpMsg.Up xxg=upBuilder.build();

ByteArrayOutputStream output =

new ByteArrayOutputStream();

xxg.writeTo(output);

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

ByteArrayInputStream input =

new ByteArrayInputStream(byteArray);

UpMsg.Up xxg2 =

UpMsg.Up.parseFrom(input);

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

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

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

3.1 測試環(huán)境

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

表3 硬件配置Tab. 3 Hardware Configuration

表4 軟件配置Tab. 4 Software Configuration

3.2 性能測試

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

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

3.2.1 序列化時耗

本測試將消息uploadCMAData，分別序列化以10、100、1000、10000次，測試用時。

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

表6 序列化時耗對比Tab. 6 Comparison of serialization time consumption ms

3.2.2 反序列化時耗

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

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

表7 反序列化時耗對比Tab. 7 Deserialization time consumption comparison ms

3.2.3 序列化后文件大小

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

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

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

3.2.4 實驗結(jié)果分析

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

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

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

4 結(jié)論

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