黃曉胤,劉童童,朱永利
(1.冀北電力有限公司檢修分公司,北京市 房山區 102488;2.嘉興供電公司,浙江省 嘉興市 314100;3.新能源電力系統國家重點實驗室(華北電力大學),河北省 保定市 071003)
近些年來,各國陸續開展了智能電網的研究工作[1-3]。智能電網提倡用信息技術徹底改造現有的能源利用體系,最大限度地開發電網體系的能源效率,現已經成為電力工業發展的方向和趨勢[4]。電力線路狀態檢測系統是智能電網的重要組成部分,建設電力線路狀態監測系統可以全面實施電力線路狀態檢修和全壽命周期管理,實現災害多發區的環境參數和運行狀態參數的集中實時監測和災害預警[5]。
以前國內不同廠家的電力線路監測裝置采用不同的標準,它們將采集到的信息發送給各自的后臺進行數據處理,沒有形成一個統一的平臺,這限制了對線路監測數據的利用。近10年來,國家電網公司認為建設堅強的智能電網必須有一個統一的數據處理平臺,陸續頒布了《輸變電設備狀態監測系統技術導則》、《輸變電狀態監測主站系統數據通信協議》和《輸電線路狀態監測代理技術規范》[6-8]。狀態監測代理匯集接入它的各類監測裝置的數據,實現對監測裝置的統一管理。
不同廠家的電力線路狀態監測數據很難同時高效地接入檢測中心,目前監測平臺采用 Web Service的方式實現這些數據的集成[9-10]。這樣的方式,雖然易于各廠家接入,但是嚴重降低了系統總體的性能。隨著智能電網建設的深入,電網所獲得的監測數據日益增多[11],這些海量監測數據傳輸到監測中心,尤其是在極端天氣的情況下,報警數據井噴式出現,對監測系統的性能提出了很高要求,現有的監測系統無法滿足[12]。另外,風電場的電力線路監測數據的快速傳輸也十分重要,也正在引起發電企業的重視。結構化數據是電力線路監測數據的重要組成部分,通過這些數據可以掌握電力線路大體運行情況,結構化數據是監測數據的基礎。本文結合電力線路狀態監測系統的需求,研究采用 Google公司的 Protocol Buffers[13-14]方法進行電力線路監測結構化數據的傳輸,試圖替代目前電力線路監測系統采用的傳輸效率低下的基于Web Service的監測數據傳輸方法。
Protocol Buffers是Google公司2008年7月公布的一套靈活、高效、自動化的數據描述語言,是一種輕便高效的結構化數據存儲格式,可以用于結構化數據串行化,目前用于谷歌公司的幾乎所有設備間的通信。由于采用了特殊設計的編解碼機制,Protocol Buffers可以高效地實現數據的序列化和反序列化操作,同時Protocol Buffers采用二進制編碼格式,能夠實現數據的高效壓縮。Protocol Buffers具有語言中立、平臺無關、可擴展的特性,只需使用Protocol Buffers對數據結構進行一次描述,便可以在不同的編程語言環境中使用。Protocol Buffers最新版的proto3已經開始支持 Java、C++、Python、Go、Ruby、Objective-C和 C#[15]。作為一種兼容性好、高效率的二進制數據傳輸格式,Protocol Buffers常常用在數據存儲和遠程過程調用(remote procedure call,RPC)方面。
Protocol Buffers采用了非常緊湊的數據編碼壓縮方法,序列化后所生成的二進制消息非常緊湊。對于整數型數據,Protocol Buffers采用Varint編碼方式。Varint是一種緊湊的表示數字的方法。傳統的整數型是以 32位來表示的,存儲需要 4個字節,當整數大小在128以內,Varint只需要用一個字節就可以表示這個整數,這樣就可以節省3個字節的存儲空間,當然Varint表示數值大的數字時需要耗費5個字節。統計發現,一般情況下工程實踐中大數字比較少,整體看來,采用Varint編碼后,可以用更少的字節數來表示數字信息[16]。
Varint中的每個字節的最高位為標志位,剩下的7位表示具體的數字。最高位為1,表示后續的7位也是該數字的一部分,如果該位為0,則表示數字的結束。例如整數 300,Varint用 2個字節來表示:1010 1100 0000 0010,其編碼如圖1所示。

圖1 Varint編碼示意圖Fig. 1 Varint coding diagram
Protocol Buffers字節序采用小端對齊的方式,計算前需將2個字節的位置相互交換。二進制1010101100轉化為十進制是整數300。
對于整數數值為負的數字,Protocol Buffers會先采用Zigzag編碼,再采用Varint編碼以實現充分的壓縮。ZigZag編碼如表1所示。其編碼原理就是按照絕對值大小來重新解析二進制,該編碼會將有符號整型映射為無符號整型,以便絕對值較小的負數仍然可以有較小的Varint編碼值。
其他的數據類型,采用標簽加長度(可選)加實際值的方式。例如對于字符串類型的數據,第1個Varint用來表示標簽,第2個Varint表示該字符串長度,然后將要表示的字符串緊跟其后。

表1 ZigZag編碼對照表Tab. 1 ZigZag coding table
消息經過序列化后生成二進制數據流,如圖 2所示。該流中的數據為一系列的鍵-值對。采用這種結構無需使用分隔符來分割不同的Field,有助于節約消息本身的大小。

圖2 二進制碼流Fig. 2 Binary stream
解碼過程是編碼過程的逆運算。Protocol Buffers反序列化(解碼)通常由自身的框架代碼和編譯器共同完成,只需要簡單的數學運算、位移等。而可擴展標記語言(extensible markup language,XML)序列化通常需要完成詞法文法分析等大量消耗CPU的復雜計算,Protocol Buffers方式在編解碼方面效率更高。
按照國家電網公司的規定,電力線路狀態監測系統總體架構圖如圖3所示。

圖3 電力線路狀態監測系統總體架構圖Fig. 3 Overall structure diagram of power line condition monitoring system
系統可分為3部分:主站系統、狀態監測代理(condition monitoring agent,CMA)和狀態監測裝置(condition monitoring device,CMD)。其中主站系統包含狀態接入網關機(condition acquisition gateway,CAG)。
主站系統通常接收前端系統傳輸來的各類狀態監測信息,并進行集中存儲、統一處理。CMA可接入不同類型、不同廠家的狀態監測裝置,實現數據的標準化接入。CMD安裝在電力線路附近或之上,能自動采集和處理被監測設備的狀態數據。
電力線路狀態監測主站系統中主站系統部署在國家電網公司總部和網省公司,各類狀態監測裝置、CMA部署在變電站和電力線路上。
電力線路狀態監測系統從分層角度來看,可分為裝置層、接入層和主站層。I1接口實現監測層與接入層之間的數據傳輸。I2接口實現接入層到主站層之間的數據傳輸。
隨著信息技術的發展,在未來電力線路監測系統中,監測裝置的數據處理和分析的大部分工作應當上移至監測中心,這樣一方面可降低監測裝置的資源配置,另一方面便于監測數據處理和分析軟件的更新[12]。
線路監測數據眾多,如環境溫度、濕度、風速、風向、雨量、氣壓、日照、風偏角、傾斜角、桿塔它身傾斜角度、拉力等等,按照功能劃分,可以分為電氣類、機械類和運行環境類。若要突出數據傳輸特點就必須將這些數據按照組織方式進行分類,進而按照其對應的特點做有針對性的研究和處理。按照監測數據的組織形式可以大致分類為結構化數據和非結構化數據。
結構化數據也稱作行數據,是由二維表結構來邏輯表達和實現的數據,主要通過關系型數據庫進行存儲和管理。在線路監測數據方面,除音、視頻數據屬于非結構化數據外,其他數據均屬于結構化數據。本文就結構化數據的高效傳輸方法進行研究。
數據傳輸模塊部署在CMA和監測主站中,實現I2接口功能。在監測主站,數據傳輸模塊位于系統底層,為上層應用程序提供數據服務,同時滿足服務程序對數據性能的要求。采用Protocol Buffers后,監測子站和監測主站內數據的傳輸與存儲都采用由Protocol Buffers編碼生成的二進制數據格式,因此系統架構應該做相應的調整,調整后的監測主站(監控中心)和監測子站(狀態監測代理)之間的通信連接示意圖如圖 4所示。從邏輯層面看,監測主站和監測子站均包含序列化和反序列化模塊以及數據傳輸模塊。數據在主站處理,存儲,因此主站還包含數據庫存儲模塊以及應用模塊[17]。Buffers的格式編碼,分別形成相應的.proto文件,如圖5所示。各個消息的簡要內容如表2所示。

圖4 電力線路狀態監測系統數據交換示意圖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消息的功能和主要內容Tab. 2 Functions and main contents of Protocol Buffers messages
從表2可見,uploadCACData消息用以上傳檢測數據。以數據上傳消息uploadCACData為例,采用Protocol Buffers結構描述語言可表示為:
message uploadCACData
{
required string cacid=1;//cac唯一標識;
required int32 datanodenum=2;//監測數組的數目
required string sensorid=3;//在線監測裝置的唯一標識;
由于基于Protocol Buffers產生的數據不具有自我描述功能,為了檢測子站以及檢測主站對數據形成統一一致的解析,子站和主站都需要關聯Protocolbuf庫。
從監測子站發往監測中心的數據按照以下的過程傳遞和處理:
1)從監測裝置收集到的數據,在數據編碼模塊,經Protocol Buffers庫進行序列化和反序列化操作,形成二進制數據,然后將數據送入數據庫存儲,并且送往數據傳輸模塊。
2)在監測子站,經數據傳輸模塊進行傳輸,傳輸至監測主站。
3)主站數據傳輸模塊收到數據后,經反序列化操作,解析出數據,然后把數據上交給上層應用程序,同時把數據存入數據庫。
從監控中心到監控子站的過程和上述過程類似,不再贅述。
通信過程是基于消息的,消息分為7類:上傳心跳信息,上傳監測數據,上傳配置信息,下發控制命令,獲取最新版本,獲取歷史版本,獲取更新文件。本文按照數據的作用,分別定義消息體。將通信過程中的 7種消息按照 Protocol
required string type=4;//監測類型6位
required string equipmentid=5;
required string date=6;
required string name=7;//名字構造required int32 value=8;//值
required bool alarm=9;//是否警告
}
Protocol Buffers規定每個屬性分別有3種規則:required、optional、repeated。required 表示該屬性在該消息中不能為空;optional表示該屬性在該消息中可以為空;repeated表示該屬性在該消息中可以有多個。每個屬性后面都有一個惟一的數字標簽,這個數字標簽用于在二進制流中定位各個屬性。標簽值不可重復。
電力線路狀態監測系統長期運行后,由于設備更新等原因,需要對部分數據結構進行更新以適應新系統的要求。Protocol Bufferrs架構具有良好的兼容性,只需簡單的修改,便可以完成向下兼容;不能改變任何已定義的字段的標簽值,不增加或刪除屬性為required的字段,刪除舊代碼中屬性為的optional字段或者屬性為repeated的字段,新增屬性為optional的字段和repeated的字段。這樣就可以在不破壞原有數據格式的前提下達到更新數據結構的效果。
根據2.2節所提方案,采用Java語言分別編寫各個.proto文件。例如上傳數據信息使用protoc--java_out=E:java UpMsg.proto命令生成對應的Java類。
經過protoc編譯器編譯后,主要生成3類函數:getXXX(),setXXX()用以設置變量;系統函數,如 isInitialized();檢查是否全部的 required數據域都被設置;序列化函數和反序列化函數。
使用Protocol Buffers編程實現數據交換,首先在項目中引入 protobuf-Java包,然后把編譯.proto生成的類拷貝到項目。這樣就可以在項目對其進行操作了。調用writeto()方法實現數據的序列化,并寫入輸出流,該過程的代碼如下所示。
UpMsg.Up xxg=upBuilder.build();
ByteArrayOutputStream output =
new ByteArrayOutputStream();
xxg.writeTo(output);
數據通過流傳輸到接收端,接收端通過調用parseFrom()方法實現數據的反序列化,該過程的代碼如下所示。
ByteArrayInputStream input =
new ByteArrayInputStream(byteArray);
UpMsg.Up xxg2 =
UpMsg.Up.parseFrom(input);
在CMA端,采用面向對象的Java語言來實現,數據以對象的形式組織,數據經 Protocol Buffers序列化后生成比特流文件,以上傳監測數據消息為例。序列化后生成比特流用ASCII碼表示如下:DC126m00090990000987DLESOHSUBD C126m00090990000987”ACK021005*DC126m00 0909900009972DC32017-04-2722:10:12SOOil Temperature@PHSOH。數據經過傳輸,在 CAG端接收并且反序列化,在控制臺調用get ()方法得到序列化后的數據信息,可以在服務器端顯示。
數據交換系統的功能主要在于實現數據的傳輸,所以測試應從序列化和反序列化用時以及序列化后所生成文件大小2方面進行測試。選作對比的是國家電網公司標準Web Service方式所采用的XML方法。
本測試使用的軟硬件環境如表3、表4所示。

表3 硬件配置Tab. 3 Hardware Configuration

表4 軟件配置Tab. 4 Software Configuration
用以實現數據上傳的 uploadCMAData消息的Protocol Buffers實現方式和XML實現方式實現方式對比如表5所示??梢悦黠@看到,在傳遞相同信息情況下,Protocol Buffers方式需要傳遞的數據比XML方式少。

表5 uploadCMAData消息實現方式對比Tab. 5 Contrast of uploadCMAData message implementation
3.2.1 序列化時耗
本測試將消息uploadCMAData,分別序列化以10、100、1000、10000次,測試用時。
序列化時耗對比測試結果如表6所示。從表可以看出,采用Protocol Buffers方式序列化數據有明顯的優勢,而且序列化數據量越大,優勢越明顯。

表6 序列化時耗對比Tab. 6 Comparison of serialization time consumption ms
3.2.2 反序列化時耗
XML反序列化采用 JAXB中 Unmarshaller接口實現,從XML序列中解碼為Java對象。
反序列化時耗對比測試結果如表7所示??梢钥闯觯翰捎肞rotocol Buffers方式反序列化數據有明顯的優勢,而且序列化數據量越大,優勢越明顯。反序列化是序列化的逆操作,他們在時耗趨勢上趨于相同。

表7 反序列化時耗對比Tab. 7 Deserialization time consumption comparison ms
3.2.3 序列化后文件大小
uploadCMAData 以XML方式序列號后文件大小為378byte ,而以Protocol Buffers方式序列化后文件大小僅108byte。
其余消息序列化數據量如圖6所示。從圖中可見,Protocol Buffer方式序列化后生成的數據量也比XML方式生成的數據量少很多。

圖6 數據量分析Fig. 6 Data volume analysis
3.2.4 實驗結果分析
經過上述測試可見,將Protocol Buffers應用到電力線路監測數據傳輸上,可以提高數據交換效率:在時間方面,Protocol Buffers將監控數據編碼為二進制格式。編解碼過程只需通過簡單的移位操作即可完成,速度非常快;在空間方面,Protocol Buffers設計的特殊的編碼機制,生成的二進制數據有更高的空間利用率,同時也降低了傳輸帶寬要求。
在整體效率方面,Protocol Buffers相比于國家電網公司采用的基于XML的Web Service方式有明顯的優勢,一般而言,采用Protocol Buffers方式文本比XML要小3~10倍,而解析效率卻提升了20~100倍。
另外,Protocol Buffers兼容性強、擴展性強。Protocol Buffers最早的版本只支持JAVA、C++和Python三種編程語言,最新版本proto3已經開始支持Go、Ruby、Objective-C以及C#。Protocol Buffers不僅支持Windows平臺,而且支持Linux平臺,為電力線路在線監測系統的跨平臺、跨語言建設提供了支持。基于Protocol Buffers的電力線路監測系統在需要改變數據結構進行升級時,不需要對原來定義的結構進行重新編寫,只需要在不更改字段標簽和required字段的前提下,在消息結構定義中增加或者刪除optional、repeated字段。這給系統的后期升級維護帶來極大的方便。
Protocol Buffers是Google公司較新的已廣泛使用的開源數據壓縮技術,在效率、兼容性和擴展性等方面有著明顯的優勢。論文圍繞 Protocol Buffers技術的原理,結合國家電網公司對數據傳輸的要求,深入分析了結構化數據的傳輸方法,提出了基于Protocol Buffers的電力線路監測數據傳輸方案,并采用Java語言編程實現了線路監測的結構化數據的傳輸,并通過數據傳輸實驗證明采用所提的Protocol Buffers實現結構化數據的傳輸,比采用基于XML的Web Service方式在時間和空間上更加高效,更適應智能電網建設的需要。