基于分布式OSGi的通用電力數據平臺

胡 平，王忠群，劉 濤，陳 穎，黃少偉

?

基于分布式OSGi的通用電力數據平臺

胡 平1，王忠群1，劉 濤1，陳 穎2，黃少偉2

(1. 安徽工程大學計算機與信息學院，安徽 蕪湖 241000；2. 清華大學電機工程與應用電子技術系電力系統國家重點實驗室，北京 100084)

提升智能電網中各種異構應用軟件間的數據共享和功能交互能力，是電力企業亟需解決的問題。而依靠標準化數據模型、SOA等技術的傳統交互方案對模塊運行期熱插拔、分布式編程模型低侵入性和電力數據持續變化的支持度不足。為此，以電力數據為中心，從軟件架構角度，將電力應用解耦為數據總線和數據插件，提出一種基于分布式開放式服務網關(OSGi)的通用電力數據平臺。闡述平臺拓撲架構、分布式OSGi的擴展方法及通用電力元數據模型，給出平臺在福建電網的實施方法，并對典型業務模塊的功能及并發性能進行測試，結果表明，該平臺能有效降低異構電力應用間的數據共享和功能交互難度。

智能電網；電力數據平臺；開放式服務網關；元數據；數據鏈；面向切面編程

1 概述

隨著電力自動化水平的提高以及智能電網[1]的興起，如何提升現有各種電力應用軟件間的數據共享和功能交互能力，以應對規模和復雜程度日趨增加的電力業務，是電力企業亟需解決的問題。然而，目前各類電力應用采用的數據模型通常互有差異，盡管工業界試圖通過推行IEC 61970/ CIM[2]等標準數據模型以規范不同電力應用的數據格式，但往往因地區實際差異較大而無法重用已有軟件模型。此外，對現有眾多電力數據模型進行標準化改造以及由此引發的業務代碼重構工作量也是無法忽視的。

除數據模型標準化外，一些研究[3]通過SOA技術將電力數據封裝為SOAP消息并公開服務接口，其在一定程度上解決了異構應用的交互問題，但在復雜業務模塊的透明分布化以及對電力數據持續變化的支持度等方面尚有不足。另一方面，受限于傳統的編程模型，目前的交互方案幾乎不具備在不間斷運行的前提下對部分功能模塊進行熱插拔和版本更新的特性，同時，企業也很難根據自身需求對功能模塊進行較細粒度的定制或二次開發，這些都嚴重降低了電力企業對需求變更的快速響應能力。

本文以電力數據為中心，從軟件架構的角度，通過將電力應用解耦為數據總線和數據插件，提出一種基于分布式開放式服務網關(Open Service Gateway initiative, OSGi)規范[4-5]的通用電力數據平臺。

2 平臺拓撲架構與分布式編程模型

2.1 平臺拓撲架構

通用電力數據平臺由數據總線(DataBus)和數據插件(DataPlug)構成，如圖1所示。

DataPlug代表部署于企業中的各種電力應用節點，它們是電力數據的來源，通過網絡彼此連接；DataBus負責管理各DataPlug間的數據交互，并向外公開統一的數據服務接口和展示框架，DataPlug可通過這些接口獲取其他Data Plug提供的服務。

圖1 通用電力數據平臺拓撲架構

DataBus定義的數據服務接口包括：(1)數據獲取：從各種數據源獲取數據，并解析成為通用的、中立的元數據； (2)數據處理：對元數據進行檢索、過濾、分解和轉換等操作；(3)數據管理：在分布式環境下管理數據的發布、同步，以及數據變化事件的訂閱和通知。

新增應用節點應實現上述部分接口并向DataBus注冊，以成為一個新的DataPlug。DataBus不僅解耦了各DataPlug間的依賴，且統一了它們的服務調用方式。不同DataPlug的實例可自由組合并通過DataBus提供的接口裝配為一個新的業務流程，從而有效提升了平臺的可定制和可擴展性。

2.2 OSGi概述

通用電力數據平臺工作于分布式環境下，而傳統的分布式編程模型在模塊級運行期熱插拔和職責劃分等方面尚有一些不足，而這正是OSGi規范所關注的問題。OSGi規范為軟件系統提供了一種基于構件的、面向服務的開發機制和運行環境，其核心思想是使軟件構件(在OSGi中稱為Bundle)的部署、啟停、更新及卸載等具備高度動態性。近年來，越來越多的應用開始采用OSGi作為底層架構來開發和部署，其中典型代表如Eclipse。

目前，兼容OSGi R4.2版本規范的參考實現主要有Eclipse Equinox、Apache D-OSGi及JBoss OSGi等，其中以Apache D-OSGi的發展最為活躍。D-OSGi源于Apache的CXF[6]項目，其核心是通過Web Service技術實現跨虛擬機的OSGi服務調用，相較于其他分布式OSGi的參考實現，D-OSGi具有以下特點：(1)保持OSGi的原有編程模型； (2)使用平臺中立的WSDL/SOAP等服務描述和訪問機制；(3)服務訪問請求和響應允許攜帶復雜的自定義數據類型；(4)提供了輕量級容器Felix的支持?；谝陨咸攸c，本文平臺選用了D-OSGi作為分布式編程模型，即各DataPlug以Bundle的形式將自身服務注冊到OSGi中心服務器，供其他遠程DataPlug訪問。

2.3 分布式OSGi的擴展方法

電力應用涉及的特殊業務決定了平臺包含的多個DataPlug間不僅僅是簡單的功能調用關系，例如，數據的每次變化都將觸發其所有監聽者執行某個操作、多個DataPlug實例在訪問共享資源時需要同步控制，任務調度器必須協調某一任務中多個并發線程的狀態以避免出現邏輯錯誤等。若遵循標準的分布式OSGi規范實現這些邏輯，不僅代碼分散、冗余度高，而且會因非功能性邏輯對業務邏輯的侵入而嚴重降低平臺的可擴展性。

借助面向切面編程(Aspect-oriented Programming, AOP)思想能較好地滿足上述特殊需求[7-8]，考慮到標準的D-OSGi交互模型缺乏對關注點分離和切面織入的支持能力，有必要對其進行面向切面擴展，如圖2所示。

圖2 D-OSGi的面向切面擴展

擴展方法基于典型的責任鏈設計模式，通過在服務消費者(Client)和服務提供者(Server)之間引入攔截器(Interceptor)，并由后者自動攔截和轉發所有由Client發起的遠程服務調用[9-10]。為獲取OSGi容器上下文，Interceptor本身也是以Bundle的形式出現，其提供的攔截方法(doIntercept)被封裝為OSGi服務并發布到注冊中心(Zoo Keeper Server)。

Interceptor通過2011年4月發布的OSGi R4.3規范中新增的服務事件監聽器鉤子(Service Event Listener Hook)實現調用攔截[11]，將目標方法與指定的織入配置(與Spring AOP的配置信息類似)進行匹配，通過編織鉤子(WeavingHook)將匹配到的橫切關注點邏輯(以AspectJ的語法定義)織入doIntercept方法的合適位置，最后將Client原來的調用請求轉發到目標方法。

3 電力元數據模型

3.1 元數據定義

作為通用電力數據平臺的數據總線，如何對各類異構電力數據進行同構化處理，并以一種與電力業務無關的結構加以描述是DataBus首先要解決的問題。本文設計了一種通用的電力元數據(metadata)模型，其將各種標準和格式的電力數據轉換為統一的3層Map結構，如圖3所示。

圖3 基于3層Map的電力元數據

元數據以最原始的鍵值對來描述電力數據，其優點是能表達和交換任何標準的電力數據。在3層Map中，頂層Key存儲數據的Tag；中層Key存儲Tag下數據行的唯一標識(可由用戶配置)；底層Key則存放數據的列名稱。此外，為區分同一OSGi容器中可能存在的多個元數據實例，每個實例都應向容器注冊一個唯一標識。若平臺需要支持某種新格式的電力數據，只需編寫負責解析相應格式文件的DataPlug并向平臺輸入層注冊即可。

具體到Java平臺，可繼承java.util.Map接口的實現類TreeMap(支持按Key排序，以滿足某些要求迭代順序與插入順序一致的業務)作為元數據的類型，如TreeMap>>，泛型中的各層Key及底層Value的類型可使用java.io.Serializable，以保證存放數值、邏輯值、文字和時間等類型數據的同時，盡量縮小范圍以提升類型安全。此外，考慮到多個線程可能對同一元數據做并發修改，元數據類還應實現java.util.concurrent. ConcurrentMap接口。

3.2 元數據/對象及關系映射

元數據模型弱化了數據的類型，其實質是一種結構化的數據，故無法對電力業務中的各種概念進行領域建模并確定對應實體類，這無疑與今天占絕對主導地位的面向對象軟件設計思想背道而馳。另一方面，元數據基于的Map接口僅支持get/put等簡單方法，在編寫需要對大量數據進行迭代和CRUD操作的DataPlug時，以具體的Tag、Id或Key作為參數頻繁調用get/put方法并造型為所需類型的方式，不僅會降低DataPlug開發人員對電力業務的關注度，而且所寫代碼的可讀性通常也較差，不利于業務的擴展。

本文提出一種將元數據模型分別映射為對象以及關系模型的方法。前者根據映射配置信息，利用虛擬機字節碼生成工具為元數據中各Tag生成對應POJO代理類及其對應DAO類(包含CRUD邏輯)；后者則提供了類SQL的元數據查詢語言(Metadata Query Language, MQL)語法支持，使得DataPlug的編寫者可以像以SQL訪問關系型數據庫那樣對元數據進行CRUD、排序和遍歷等操作。

具體到Java EE平臺，可借助javassist和antlr等第三方Jar實現上述映射。此外，在對元數據進行寫操作時，為保證完整性，攔截器Bundle應自動為這些操作織入相關的事務提交和回滾邏輯。

3.3 電力數據持續變化探測

電力應用相較于其他領域業務系統的一個重要區別是電力數據的持續變化將多次觸發某些業務邏輯，換句話說，電力系統中的事件源往往是系統內部的數據，而非位于系統外部的使用者或其他系統。因此，通用電力數據平臺必須具備探測元數據變化并執行相應業務操作的能力，具體包含以下2種方式：

(1)定時檢查：在任務調度器中為每個DataPlug實例啟動一個專門的監聽線程，該線程以固定時間間隔主動拉取(Pull)與DataPlug實例關聯的元數據，并檢查其是否與之前一致，若有變化，則由任務管調度器回調相應的接口方法。

(2)變化通知：通過主題/觀察者設計模式以及GUI編程中的事件驅動模型，以配置的方式為元數據實例指定一個或多個DataPlug實例作為數據變化事件的訂閱者。當發生寫數據操作時，元數據實例首先將變化的數據封裝為事件對象，然后推送(Push)該事件對象到各訂閱者的事件隊列。為觸發作為事件訂閱者的DataPlug實例，任務調度器需要啟動一個全局監聽線程以掃描各訂閱者的事件隊列，并回調相應DataPlug的接口方法。

因平臺數據全部來自于第三方的電力應用(變化時機無法預期)，故定時檢查無法捕獲發生在相鄰2個檢查點之間的連續變化。另一方面，因定時檢查含有元數據比較邏輯，且各DataPlug實例都對應一個監聽線程，故其性能明顯不及變化通知方式。

4 平臺在福建電網的實施

4.1 平臺邏輯層劃分與數據鏈

本文平臺一期已于2012年底在福建電網上線，共計 61個Bundle，其中24個構成DataBus，其余為DataPlug，涉及業務包括電網解列、薄弱環節識別、狀態估計、模擬數據產生等。平臺的邏輯層劃分如圖4所示。以上各層均有相應的管理邏輯，用于控制本層Bundle實例的生命周期及任務調度。管理邏輯涉及的細節對數據平臺的使用者呈透明，各層Bundle的編寫者只需配置本Bundle的觸發條件和必要的映射信息。各層Bundle的一個或多個實例可通過指定關聯端實例名稱的方式彼此連接以形成數據鏈，并通過RIA技術以可視化的方式呈現給用戶。在觸發條件被滿足時，由任務調度邏輯通過反射機制自動回調Bundle的特定方法，從而實現跨層的Bundle交互并最終完成一次完整的業務操作。

圖4 通用電力數據平臺的邏輯層劃分

4.2 平臺功能與并發性能測試

本文數據平臺基于JDK 6.0+IDEA 12開發，并以Maven作為模塊版本管理插件；OSGi服務框架采用Apache CXF D-OSGi 1.4，OSGi容器為Felix 4.2，Web容器為Jetty 9.0.1。

在功能正確性方面，選取了位于平臺處理層的State Estimator(電網狀態估計)作為測試目標，其數據鏈如圖5(a)所示：(1)讀入網架和量測數據并分別解析為元數據；(2)執行開關估計，找出可疑開關并修正；(3)執行拓撲分析，分析電網拓撲結構，得到拓撲島數據；(4)執行狀態估計，計算得到電網狀態估計值；(5)查看修正后的元數據。圖5(b)為結果元數據界面，經程序比較，與原本地C++應用的計算結果一致。此外，當輸入層的網架和量測數據變化時，將自動觸發位于處理層的3個DataPlug重新計算，驗證了平臺可行性。

圖5 平臺功能性測試

在并發性能方面，選取位于平臺輸出層的Meta2DB(將元數據導出到關系數據庫的DataPlug，包含自動建庫/表邏輯)的多個并發實例，分別導出本地和遠程元數據作為測試目標，測試數據源為福建電網2011年12月QS格式數據 (14個Tag，數據總量為22 157條，元數據序列化文件大小為5.35 MB)。具體測試結果如圖6所示。

圖6 數據平臺并發性能測試結果

為降低硬件瓶頸對測試準確性的影響，并發性能測試使用了5臺高性能PC機，每個均啟動了數量不等的并發實例；數據庫服務器(Oracle 10g企業版)部署于IBM System x3650 M4，并通過千兆以太網與各PC機連接。不同并發實例數下的測試結果表明：(1)無論是本地還是遠程電力數據，數據平臺均提供了較好的時間響應；(2)受元數據變化頻率、虛擬機線程調度時機以及DataPlug所在節點的繁忙程度影響，單節點上的并發實例較多(12個以上)時，單次任務的耗時將顯著增加，但仍可接受。

5 結束語

如何提升不同電力應用系統間的異構數據共享和功能交互能力是構建智能電網必須解決的問題。本文從電力數據和軟件架構的角度，通過將電力應用解耦為數據總線和數據插件，提出了一種基于分布式OSGi的通用電力數據平臺，并設計了一種能表達和交換任意格式的電力數據，同時具備探測數據變化并觸發相應業務能力的電力元數據模型。通過對典型電力業務的功能及并發性能測試，驗證了該平臺在分布式編程模型的低侵入性、電力業務模塊的動態熱插拔以及對數據變化事件的支持能力等方面均能較好地滿足異構電力應用間的數據共享和交互需求。下一步將繼續完善數據平臺，并對計算密集型電力業務的計算任務分派、并行計算以及集群環境下的負載均衡、失效DataPlug主動遷移策略[12]等方面做進一步的研究。

[1] Farhangi H. The Path of the Smart Grid[J]. IEEE Power and Energy Magazine, 2010, 8(1): 18-28.

[2] 丁 明, 張征凱, 畢 銳. 面向分布式發電系統的CIM擴展[J]. 電力系統自動化, 2008, 32(20): 83-87.

[3] 唐躍中, 曹晉彰, 郭創新, 等. 電網企業基于面向服務架構的應用集成研究與實現[J]. 電力系統自動化, 2008, (14): 50-54.

[4] OSGi Alliance. OSGi Service Platform Release 4.3[EB/OL]. (2011-06-17). http://www.osgi.org/Release4.

[5] Redondo R, Vilas A, Cabrer M. Enhancing Residential Gateways: OSGi Service Composition[J]. IEEE Transactions on Consumer Electronics, 2007, 53(1): 87-95.

[6] Apache Software Foundation. The CXF Project[EB/OL]. (2013-05-24). http://cxf.apache.org/distributed-osgi.html.

[7] The AspectJ Project. AspectJ 5 Developer’s Notebook[EB/OL]. (2012-03-26). http://www.eclipse.org/aspectj.

[8] Alexanderson R. Aspect Oriented Software Implemented Node Level Fault Tolerance[C]//Proc. of the 9th International Conference on Software Engineering and Applications. [S. l.]: ACM Press, 2007: 57-74.

[9] 張 仕, 黃林鵬. 基于OSGi的服務動態演化[J]. 軟件學報, 2008, 19(5): 1201-1211.

[10] 馮志宇, 黃林鵬. 基于OSGi的兩層服務模型[J]. 計算機應用研究, 2009, 26(7): 2590-2592.

[11] 史殿習, 吳元立, 丁 博, 等. StarOSGi: 一種OSGi分布式擴展中間件[J]. 計算機科學, 2011, 38(1): 162-165.

[12] 李長云, 李 瑩, 吳 建, 等. 一個面向服務的支持動態演化的軟件模型[J]. 計算機學報, 2006, 29(7): 1020-1028.

編輯 顧逸斐

General Electric Data Platform Based on Distributed OSGi

HU Ping1, WANG Zhong-qun1, LIU Tao1, CHEN Ying2, HUANG Shao-wei2

(1. School of Computer and Information, Anhui Polytechnic University, Wuhu 241000, China; 2. State Key Lab of Power Systems, Department of Electrical Engineering, Tsinghua University, Beijing 100084, China)

Power companies need to solve the problem that how to improve the capabilities of data sharing and interoperation between heterogeneous applications in smart grid. Some solutions based on data model standardization or SOA are inadequate in terms of runtime modules hotplug, invasion of distributed programming model and continuous data change supporting. This paper decouples a power application software into data bus and data plugs from the perspective of electric data and software architecture, proposes a general electric data platform based on distributed Open Service Gateway initiative(OSGi), and then discusses the topological structure of data platform, distributed OSGi extension model and electric metadata model. The implementation approach of data platform in Fujian power grid is presented, and some tests are done for typical modules’ functionality and concurrent performance. The results show that the platform can reduce the difficulty of data sharing and interoperation between heterogeneous applications effectively.

smart grid; electric power data platform; Open Service Gateway initiative(OSGi); metadata; data chain; Aspect-oriented Programming(AOP)

1000-3428(2014)03-0071-05

A

TP393

國家自然科學基金資助項目(61300170)；安徽省教育廳自然科學基金資助項目(KJ2013A040)；清華大學盧強院士安徽省工作站基金資助項目。

胡 平(1979－)，男，講師、碩士，主研方向：分布式計算，軟件體系結構；王忠群，教授；劉 濤，副教授、碩士； 陳 穎，副教授、博士；黃少偉，講師、博士。

2013-11-20

2013-12-16 E-mail：JavaFounder@gmail.com

10.3969/j.issn.1000-3428.2014.03.015