基于分布式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的支持。基于以上特点，本文平台选用了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