统一数据平台

2024-10-09

统一数据平台(共12篇)

统一数据平台 篇1

摘要:【目的】基于现有的业务信息系统数据, 建立医院数据统一应用平台, 提升业务数据的服务与再利用能力。【方法】通过建立医院数据统一应用平台改善业务系统数据获取能力、实现数据集中统一存储、提升医院数据综合应用利用与服务能力。【结果】通过门诊实时流量监控数据展示与医院综合运营数据展示作为医院数据统一应用平台的示范应用, 建立医院数据统一应用的示范原型, 实现了医院数据统一应用的综合展示、数据准实时监控的效果。【讨论】数据统一应用平台的建设过程涉及多个业务系统数据的整合, 解决好数据一致性、海量数据处理、如何规划好数据统一应用主题的问题是建设过程中的关键性问题。

关键词:数据统一应用,数据中心,医院信息平台,信息标准,大数据

1 背景与目的

广州医科大学附属第二医院信息化建设自1998年开始以来, 在his信息系统建设的基础上, 各类业务应用系统逐步完善并建立起来, 医院信息化程度日益提高。借助多个系统供应商参与了医院五十多个业务系统建设, 业务信息系统主要以满足业务人员日常业务处理的信息化, 大多都是按照业务执行科室的需求建立, 更多关注于面向业务环节的实现。借助大量业务信息系统的建立实现了各个业务中信息化的逐步深入与渗透。随之而来的不断积累的海量临床、管理、运营数据, 这些数据分散在各个业务系统中, 业务系统对数据进行了部门级业务所及范围内的种种数据利用, 而如何使数据之间进行协同并发挥更大的作用成为我们需要进一步思考的问题。

信息中心在日常信息系统维护的基础上, 为各个业务部门、职能管理部门、院领导决策需求提供大量的数据统计方面的服务。随着信息化建设的逐步深入各个管理部门对业务数据的综合应用需求日益凸显。从数据应用方式到数据分析方法等方面的需求也越来越高。加之上级管理部门针对医院整体考核开展的如三级综合医院评审标准, 医院三好一满意等活动, 也对信息系统的数据综合应用能力提出了新的更高的要求。业务信息数据逐渐演变成支撑医院、科室、个人、项目成本核算要求, 医保结算要求, 新医改下的新的结算支付体系建立, 管理监控、质量控制、经营决策、临床科研等发展的重要依据。

对业务数据进行更为深入的、综合的利用。将这些数据更为密切的关联起来, 形成以病人为基本单元的医院数据中心, 并根据经营、管理、临床业务和科研等不同需要, 对这些数据进行统一的、实时的应用, 对行政、财务和临床业务起到辅助决策支持的效果, 这将是未来很长一段时间我院信息化建设任务的重点。医院信息化建设的重点将进行由业务支撑信息系统建设为主的建设模式向业务支撑与数据综合利用信息系统并重的模式转变。

2 数据综合应用面临的问题

在医院快速发展和新医改政策的要求下, 临床科室和管理科室对数据的再利用需求越来越多, 各业务科室对系统的协同操作程度也越来越高, 暴露出来的问题也越来越明显, 主要表现在:

2.1 业务信息共享不充分

各个业务子系统之间缺乏信息共享的渠道, 绝大多数的业务数据交换时仅限于满足业务协同的数据交换, 导致各个业务系统之间信息共享不充分, 有机会成为信息孤岛。而在数据综合利用的需求下, 业务信息共享往往需要实现基于业务事件相关的完整的信息数据的共享。

2.2 数据来源多样交叉

目前院内多个业务信息系统围绕患者、工作人员、科室、临床事件不断的产生个海量的临床、运营数据, 不同数据按照业务维度分布在各个业务系统的数据库中。而医院未来业务的扩展, 以及新设备、新检查产生的将会继续扩展产生新类型数据。传统方式下的业务系统对数据的分析与展示局限在单个系统的数据库系统中。而医疗流程的复杂, 使得数据的应用需求将面向多个系统多数据源。

2.3 数据综合利用度难

由于大量的业务数据存在与各个不同的业务信息系统中, 不同业务系统之间通过自然方式进行了仅限与业务协同类的数据交换, 使业务信息系统数据难以以医院整体综合应用的方式进行数据利用。各个层级的用户对数据的应用已经不仅仅局限在业务信息系统内的数据, 用户迫切的需要以患者为中心将各个相关的临床运营数据进行按照临床事件、文档逻辑相关的方式进行数据的组织与利用, 有效的数据综合组织将给用户带来更好的业务辅助。

3 医院数据统一应用平台实现架构

在医院基础业务数据采集日臻完善的基础上, 通过建设基于医院信息平台的数据统一应用平台的建设, 加强医院各业务信息系统产生数据的获取能力, 提高业务信息系统数据的可利用性, 提升医院基于数据分析的辅助决策能力, 逐步实现业务数据完整采集、数据集中统一存储、信息利用有序高效。

(1) 通过数据统一适配器与面向服务的接口方式对提升业务系统将数据进行面向临床事件数据的共享与交换能力。

基于临床事件的业务信息系统改造:现有的各个业务系统在技术实现时, 只在系统内进行了数据的记录与存储, 而平台数据交换往往对事件信息的数据利用具备一定实时性要求, 所以需要建立基于临床事件的消息交换机制将帮助业务系统实现数据的及时有效的共享与交换。

(2) 通过数据统一协调层接入多个业务域的临床业务数据, 解决数据来源的多样性的统一。

基于临床事件信息交换平台的建立:建立医院信息平台通过SOA的平台交换技术架构, 帮助业务系统之间面向业务协同的消息交换, 同时也帮助平台面向数据中心的业务数据的集中统一存储, 帮助业务系统在完成信息数据交换共享的同时, 沉淀和积累业务数据。

(3) 建立临床数据中心运营数据中心。

建立临床数据中心与运营数据中心, 将平台中交换与共享的业务数据按照以患者为中心以及以医院参与者为中心的数据统一集中存储。通过不同维度的数据组织方式, 面向数据应用主题预置一些统计与数据加工模型, 为快速的数据应用夯实基础。

(4) 数据统一应用集成可视化的数据展现。

基于平台的业务应用数据应用建立:随着事件信息交换共享平台与数据中心统一集中存储的完成。跨业务系统的高端业务应用、对院外的数据交换与共享、数据统一与集中的应用与展示将可以建立起来。结合先进的软硬件技术, 实现分析数据的动态、精确、有效的展现。这些信息将按照提供者、使用者、使用场景等多种因素进行自动的调整, 展现在电脑终端、壁挂式大屏幕、手持信息终端等各种恰当的设备上, 供不同的信息使用者使用。

4 医院数据统一应用平台技术实现方法

卫生部2010年11月发布了《基于电子病历的医院信息平台建设技术解决方案》, 我院选取了门诊实时流量监控数据展示与医院综合运营数据展示作为数据统一应用的首个切入点, 参考《基于电子病历的医院信息平台建设技术解决方案》搭建了我院数据统一应用平台的应用原型。

4.1 医院数据统一应用平台采用的开发技术

数据统一应用平台采用跨平台的J2EE技术进行实现, 服务器采用Windows Server 2008系统, 数据存储采用了开源的MySQL数据库进行运营数据的临床事件数据与运营数据监测分析统计数据的存储。数据统一适配器 (DUA) 、数据统一协调层 (DUAC) 、运营数据分析存储引擎 (DUAC2ODS) 、运营数据展现服务均采用J2EE进行开发。数据统一协调层 (DUAC) 基于消息中间件技术构建, 借助JMS、消息队列实现用于预约挂号业务的数据整合, 并保证业务数据准实时协同。为满足在分布式计算环境下企业应用对性能、安全性、稳定性等方面的要求, 基于消息中间件 (Message-Oriented Middleware, MOM) 的数据通信系统能够异步传递消息, 将彼此独立的计算机连接起来组成松耦合的系统, 并且可以有效地屏蔽异构细节对外提供统一服务。

Java消息服务 (Java Message Service, JMS) 应用程序接口是一个Java平台中关于面向消息中间件 (MOM) 的API, 用于在两个应用程序之间, 或分布式系统中发送消息, 进行异步通信。Java消息服务是一个与具体平台无关的API, 绝大多数MOM提供商都对JMS提供支持。Java消息服务的规范包括两种消息模式, 点对点和发布者/订阅者。这些操作将具有不同面向消息中间件产品的可移植性。Java消息服务支持同步和异步的消息处理, 在某些场景下, 异步消息是必要的;在其他场景下, 异步消息比同步消息操作更加便利。在本次建设中我们选用了异步的消息处理模式。而具体实现JMS的消息中间件我们选择了基于开源协议的ActiveMQ。

在终端的数据综合战展现上我们借助Adobe Flex的强大的数据展现能力打造出数据集成可视化富客户端 (RIA) , 通过Flex的实时数据刷新能力实现终端数据的实时动态展示。

4.2 数据统一适配器实现临床事件准实时获取

借助数据统一应用平台的数据统一适配器实现了门急诊挂号数据、就诊数据、处方数据、门诊交费数据、门诊药房取药数据、入院登记数据、在院病人数据、出院登记数据、出院结算数据分布在门急诊挂号系统、门诊医生工作站系统、门诊交费系统、门诊药房发药系统、入出院登记系统、出院结算系统六大系统, 九类临床事件的准实时数据向临床事件的模型转换。通过9个临床事件所对应的九个数据统一适配器完成了各个临床事件的准实时获取, 实时获取的时间延迟不超过5秒。

数据统一适配器 (DUA Data Unifier Adaptor) 采用J2EE的JDBC以及Oracle数据库的物化视图技术实现对业务数据记录变更的实时获取, 通过业务数据的变化还原临床事件的发生过程。以患者基本信息数据整合适配器为例, 通过JDBC从数据库层面将his信息系统中的患者数据读取出来, 通过患者数据标准模型封装, 按照JMS规范将标准模型封装的患者对象按照数据产生的状态发送给ActiveMQ搭建的消息队列中。

4.3 运营数据基于临床事件与运营数据分析模型的集中存储

运营数据存储库 (Operation Data Storage ODS) 是一个面向主题的、集成的、可变的、当前的细节数据集合, 用于支持医院对于即时性的、操作性的、集成的全体运行于运营信息的需求。

在医院数据统一应用平台HDUAP中, ODS是医院运营数据的统一集中存储。ODS将医院的门急诊、住院、物资供应、设备等运行数据进行时间维度、物资设备类别、消耗、业务发生、财务资金维度的统一集中存储。

本次运营数据存储库根据门诊实时流量监控数据展示与医院综合运营数据展示需求, 后台生成15分钟、小时、日为维度的不同时间密度的运营统计数据支持前端的数据展现需求。

4.4 集成可视化运营数据展现

门诊实时流量监控数据展示分别展示了我院每日门诊流量的实时变化情况。动态展示了门诊各窗口的准实时流量分布情况。

医院综合运营数据展示反映了当日医院门急诊、住院的整体运营情况, 包括门诊就诊日次、费用情况;住院入出院人次、在院数据、危重患者人数、住院结算情况等。

5 项目建设总结与讨论

借助基于医院信息平台的医院数据统一应用两个应用主题建设过程中的经验积累, 我们发现进行医院数据统一应用平台建设时需要注意三大内容。一是要做好医院数据统一应用的主题分析, 做到分层分级应用, 满足各层级的数据综合应用的需求;二是要注意应用过程中的数据一致性保障过程, 使应用数据做到有效、准确、可靠;三是要使用好海量数据以及大数据分析的信息技术。

5.1 医院数据统一应用的主题分析

通过以病人为核心的数据统一应用。使平台服务于医生、护士、临床辅助人员, 以病人病例数据为中心, 围绕临床数据、运营数据、以及临床数据所涉及的知识库辅助数据、费用分析数据, 进行概要性的数据集中展示、详细的数据分析展示、指导、预警数据的及时展示。服务于患者, 以病人病例数据为中心, 提供在院门诊和住院期间的各项自助服务, 如:检验检查报告自助查询、自助分诊、自助排队、自助导医等。通过数据集中统一应用提升服务品质。

通过以部门应用为核心的数据统一应用。使平台服务于病房、临床科室、医技科室及其他辅助科室, 以部门的数据应用需求为中心, 围绕临床事务数据、运行数据、运营数据、科研数据、服务数据以及类似个案的组病例数据, 进行概要性的数据集中展示、详细的数据分析展示、实时指导、预警数据的有效展示。

通过以全院管理为核心的数据统一应用。使平台服务于全院级的管理部门, 如医务部、医保办、护理部、经营管理办公室、财务处等职能科室。以各个全院管理部门的数据应用需求为中心, 围绕临床事务数据、临床过程数据、运营数据、科研数据、服务数据, 进行概要性的数据集中展示、详细数据的分析展示、实时指标预警数据的有效展示。

通过以决策服务为核心的数据统一应用。使平台服务于院领导等决策层, 以决策层的数据统一应用需求为中心, 围绕临床事务数据、临床该过程数据、运营数据、科研数据、服务数据进行概要性的数据集中展示、详细数据的分析展示、实时指标预警数据的有效展示。

5.2 医院数据统一应用的数据一致性保障

患者的身份识别, 各个业务系统间患者的身份识别问题将成为完成医院业务信息系统数据统一共享的主要问题, 只有正确识别出各个临床事件的参与者, 才能将业务数据进行有效的组织, 并建立相互之间的有效联系。

信息交换标准问题, 平台所需交换信息的规范化和标准化, 是保障信息有效共享的前提。当前, 医疗信息的可用标准十分有限, 如何保证所涉及的厂商遵从通行的标准和规范是一大挑战。此外, 角色、事务和流程的标准化亦不可忽视。信息的交换与共享除了要有符合标准定义的文档内容、文档格式、传输通信协议和语义外, 还需要多个角色通过有序的多个事务配合才能完成。

5.3 海量数据以及大数据分析

数据中心构建和海量数据的分析处理, 各个业务信息数据的统一集中存储后, 所有数据集中将会带来数据中心构建以及海量数据分析处理的问题, 进行数据综合利用时, 患者个案数据的分析、临床智能质控、大样本的数据特征分析等等将实实在在的摆在我们面前, 应用和利用好现有的大数据存储与应用信息技术将是数据应用的新方向。

参考文献

[1]卫生部.基于电子病历的医院信息平台建设技术解决方案.2010-10

[2]翁盛鑫, 庄严, 陈祁.基于数据整合应用的预约挂号平台设计与实现.中国数字医学2012年07卷03期

[3]戴俊, 朱晓民.基于ActiveMQ的异步消息总线的设计与实现.计算机系统应用2010年第19卷第8期.

统一数据平台 篇2

增值应用前景广阔

“随着公司仓储面积的不断扩大,公司内部业务部门之间的沟通成本也开始相应攀升。现实的沟通需求与高昂的通信成本之间的矛盾开始凸显,内部统一通信问题已成为公司需要解决的首要任务之一。”北京西南物流中心信息中心经理任浩表示。

作为北京市规划局批准成立的专业性物流企业,北京西南物流中心也是全国最大的图书物流中心,专业从事图书仓储、分拣、配送服务。该中心的综合物流部作为第三方物流业务部门,目前已经承接了蒙牛、九牧王等大型企业的物流业务,配有专业运输车辆百台以上。

得益于良好的管理及经营,近年来北京西南物流中心的业务规模不断扩充,其新库区也随之一一落成。由于各个库房与办公楼之间都有一定距离,企业内部沟通必须借助通信工具实现,通信成本越涨越高,为企业经营带来的负担也越来越重。

由于此前各个库区及办公楼都具有无线Mesh 网络覆盖,西南物流中心确定了在现有无线网络基础上陆续开展企业信息化业务并实现统一通信平台管理的应用方案。经过前期的产品选型和内部测试,该中心最终选择了捷思锐科技公司的企业级IP PBX---SE150作为解决内部语音通信的核心设备,

任浩介绍了SE150 在其物流中心的实施情况:在现有Mesh 网络的基础上,通过在各个库房部署IP 话机、WiFi手机和IAD 等设备实现分机用户的接入,能够快速、低成本的满足中心内部免费语音通信的需求,并且WiFi手机还可以配合 Mesh 网络实现在无线覆盖区域内的移动通信。SE150 还具有可扩展的FXO 和E1 卡插槽,能够实现与PSTN 的互联。同时,SE150 还能够提供总机服务、电话会议、语音信箱、部门800 等增值业务。

在系统建设完成后,经过一段时间实际运行,该物流中心对实际效果非常满意。在任浩看来,该系统除了各种技术功能完全达到预先的承诺之外,对于其企业还带来了多个方面的应用价值:

首先是成本的降低。仅一期项目实施后,相比以前的通信方式,公司可节省48%的费用;

其次是改进了沟通效率。专网业务操作方面的简便性和内部沟通零成本所带来的效应,可以极大满足内部业务沟通的需求,释放内部潜能;

再次是资源合理利用。专网服务充分利用客户现有基础网络资源,基本没有改变用户的网络环境和使用习惯,实现了统一通信平台服务目标;

最后是提升了客户满意度。沟通效率的提高,直接改善了企业内部运营的效率,体现在最终用户方面,更多客户选择该物流公司的服务。

数字校园统一平台的建设 篇3

关键词:数字校园;框架;网络

中图分类号:TP393.18文献标识码:A文章编号:1006-8937(2011)22-0078-01

1数字校园建设的现状及问题

数字校园建设是高等学校建设的重要部分,是整体推进教育信息化的一个过程。当前教育信息化建设展现了良好的发展势头,但有些问题如果不解决,将可能对建设的持续性发展产生制约影响。而对于解决问题的新技术、新理念也应该从可扩展、可通用等多角度出发去进行选取,本项目便是基于上述的原则,针对目前数字校园建设中存在的信息无交互或交互过少而形成的若干信息孤岛,无统一信息平台而造成的管理和沟通的不便等问题,采用了扩展性、通用性都较强的基于J2EE的平台建设技术,尤其是有关数据交换的相关技术,对现有数字校园的建设进行进一步改进。

2如何改进数字校园建设

针对上述数字校园建设过程中缺乏发展规划、资源不能共享、应用难以集成、用户使用繁杂等问题,从以下四个方面提出改进方案:

①网络基础设施建设,对现有一定规模的网络基础设施进行改造和完善,包括网络带宽的升级,连网范围的扩大,网络设备的升级和优化,网络管理、安全的加强等。

②网络存储、计算资源的扩展,建立超级计算机系统,为科研中的大规模计算创造条件,建立网络海量存储系统,为校园网用户提供存储服务。

③应用平台和系统建设,建设统一、可伸展、安全、可互操作、数据共享的应用开发与运行环境,实施网络安全,建立身份认证系统,加强数字图书馆建设,丰富远程教育系统的功能,完善视频会议系统,完善电子化教学应用,建立统一的校务管理系统,实现完全意义上的办公自动化,建立先进的应用开发体系,形成一定的应用开发支持基础,以适应今后多种灵活的网络应用发展。

④门户服务的提供,建立校园社区服务架构并提供多方位服务,采取统一的门户服务方式扩大学校的宣传影响和对外服务。

校园门户网站主要向数字校园使用者提供个性化单点登陆的界面显示;Web连接逻辑主要用于连接应用程序和Internet/Web,以及生成基于Web的表示内容;可伸缩集成应用逻辑主要用于连接遗留应用程序,新应用程序及其他外部应用程序;而遗留应用程序是指已有数字校园中已开发好的管理系统,如办公、教务、财务等;新增及其他外部应用程序就是即将开发的数字校园的新业务系统;校园数据库则是校园内基本数据的汇总。

利用J2EE来搭建上述的数字校园软件平台,完全能够提供相应的技术支持,整个系统与操作系统无关,这正遵循了J2EE的规范,而且正如上面所言,所有的开发均可用Java语言来完成,比如校园门户网站的Web浏览及Java小程序可以用Java GUI技术建立,Web逻辑可用Java Servlet、JSP等来实现,可伸缩集成应用程序逻辑则由EJB、J2EE接头、J2EE管理、JMX、J2EE Deployment、JACC和JAAS w/EJB等来完成,而整个结构中的数据支持部分则运用JAXP及JDBC来操作,当然还有通信、安全等实施均有相应的较为成熟的技术支持。

3结 语

从上述对高校数字校园的现状分析可以看出,高校的管理是松散式管理,这必然导致数据格式的多样性。如果为每一种数据在要使用的模块中增加一个转换接口,这有点愚公移山的精神。为此我们不仅要保存已有的数据管理系统,还要让使用这些数据的应用程序保持稳定,即不能因为数据的任何变动而产生结构上的变动。因此一种可行的方案是把每个从应用中出来的数据进行规范,规范后的数据能在各个应用中被识别,接收方再根据自己的要求把这种数据转换成自己的使用或显示形式即可。这种方案对规范数据的要求较高,它既要能方便地转换成其他各种形式的数据,而且还要具有可扩展性,目前看来,用XML来表示数据是一种较为理想的选择,它从万维网产生,但在一般数据表示中也有广泛的应用,因此,可以用XML标准语法描述存储与交换的数据,而且Java和XML都具有跨平台的特性,因此它们可以毫不犹豫地完美地结合在一起,完成数据存储和转换的工作,J2EE中集成的JAXP便是这种模式的具体体现。当然要转换数据首先要获取数据,这需要连接已有的数据库管理系统并发出它们能识别的数据查询命令才可获取,同样是因为数据库管理系统的多样性,要找到一种一劳永逸的方法也确实不易,好在J2EE中集成的JDBC技术解决了这一难题。

参考文献:

统一数据平台 篇4

关键词:水务数据,统一交换,共享平台,管理平台

0 引言

近年来上海水务部门陆续开展了大量信息化建设工作,实现了与国家防总、水利部、全市水务系统、气象、海洋和海事等多个部门互联的水务专网;建成了涵盖供水,排水,水利3大行业,用于防汛抗旱指挥、水资源管理、水环境治理、水务工程管理等不同业务目标的近50余套信息系统;累积了从1998年以来超过1TB数据量的多比例尺、多时相的数字地形图和遥感影像资料。这些系统的建成,为开展“智能水网”建设提供了必备网络条件和大量数据资料。而“智能水网”的建设离不开跨单位、部门、系统的数据交换和信息共享。

结合上海水务信息化发展实际情况,运用满足水务一体化管理工作需求的多目标、任务和层次的统一数据交换与共享管理技术,设计了水务数据统一交换管理平台,支持水务数据在多源、异构的不同系统间实现数据交换、信息流转。对水务数据实现有机整合、共享共用进行了有益研究和实践。

1 问题的提出

上海水务现有各单位信息系统及数据库建设受当时信息技术限制和建设理念局限,各系统存在系统架构多样,数据库结构不同,数据格式不同等问题:各系统由于建设年代不同,存在C/S与B/S架构并存,Java,.Net与其他工业组态软件并存,各应用系统独立开发,很难有效整合;数据库同时存在SQL Server,Oracle,SyBase,DB2等多种类型;数据表设计不同、数据多源异构、技术路线差异极大,难以实行高效的数据交换及共享;各系统应用目标单一、缺乏信息共享与联动,难以满足行业管理决策的支持需求。

同时,在水务数据统一交换管理平台未建设之前,各单位信息系统及数据库之间所采用的数据交换主要是传统的“点对点交换模式”,即应用系统之间数据库直连的紧耦合交换模式。由于这种数据交换模式需要对2端系统进行源码级开发,在对原有系统稳定性产生一定影响的同时,随着交换单位需求越来越多样,其数据交换复杂度也会与日俱增,数据交换将由一对一变成一对多甚至是多对多,相应的数据交换规则和程序开发量将呈几何倍数增长,最后形成蛛网状。这种交换模式既难以开发也难以维护,改动一点,可能导致数据交换甚至业务系统的瘫痪,将很难适应水务发展需求。

因此建设1套行之有效的能够满足全市水务行业需求的水务数据统一交换管理平台,解决“信息孤岛”现象,实现水务行业内各部门之间,以及与其它行业之间的数据共享和联动,形成数据及时有效的更新机制,成为当前水务部门亟待解决的课题。

2 方案的设计

水务数据统一交换管理平台设计目的是满足市水务局层面政府决策、综合管理工作对数据集成、数据挖掘和综合业务分析应用的需求。在市水务局已完成水务数据中心框架构建的基础上,建立1个统一的数据交换平台,简化规范行业条线应用对数据交换共享和管理的操作,协调信息资源的共享共用,满足供水,排水,水利3大行业间对数据综合调用的块状应用需求,实现面向应用的数据监控,集中管理和运行维护,提供高灵活、稳定、可用和易扩展性的功能支持。

水务数据统一交换管理平台位置示意如图1所示,连接了水务数据中心和应用系统、各行业基础数据库等,主要提供数据库连接和中间层服务。水务数据交换系统通过对各行业基础数据库进行数据抽取,异构处理和数据归并等方式,将数据传输、汇聚和存储到水务数据中心,并提供相关单位之间的数据交换和共享;为水务数据中心中面向专题应用的数据仓库提供数据统一访问和交换接口,为各类应用系统提供数据支持和应用服务支持。

根据上海水务综合管理中存在静态,实时和资源目录3大类数据的情况,我们设计了能够实现统一汇聚、规范整合、规范发布的基于数据总线技术的数据交换平台。在这种模式下,所有应用系统或行业基础数据库不直接连接中心数据库进行数据交换,而是连向数据交换平台,由交换平台统一维护各个信息系统之间的接口、协调信息资源、对各个信息系统做数据交换共享。随着参与的系统增加和数据量的不断加大,其可扩展和稳定性等方面的表现就越来越突出,更能适应信息系统规模的扩大和业务工作的不断发展。

水务数据交换平台结构示意如图2所示,虚线框内所示的水务数据统一交换管理平台主要由数据交换和管理2大部分组成。

2.1 数据交换部分

主要基于数据总线技术来实现对水务数据中心的基础、实时、政务、业务和元数据类数据与各单位信息系统之间的统一数据交换。在上海水务数据交换应用中,我们基于IBM Message Broker中间件平台,根据数据更新的不同要求进行了数据交换的二次开发和定制,有针对性地设计了水务数据实时和静态交换方式,并设计了用于获取水务数据中心中存储数据的信息资源检索接口。

2.1.1 实时数据交换

主要针对由实时采集信息系统生成的数据及部分以数据记录形式存储在数据库中并及时更新的政务类数据,采用统一的数据交换中间件平台进行实时数据交换。在不改变原有系统的情况下,支持数据在多源异构的系统和数据库之间交换,实现各类水务实时数据的无缝流转,实现对实时数据的集中、发布、路由、交换与同步,将经过汇聚,整合,规范后的水务核心数据集中存储到水务数据中心,并能为将来构建其它信息系统提供数据规范接口。

2.1.2 静态数据交换

针对数据更新频率不高且以文件或图片形式(如基础数字地形图、遥感影像数据、行政许可的附件资料等)保存的基础类和部分政务类数据,通过数据总线采用统一的文件数据定期拷贝形式进行数据交换。

2.1.3 信息资源检索接口

基于XML设计,用于水务数据监控管理部分与水务数据中心、数据统一交换平台之间协调通信,实现对水务数据中心存储的数据的编目、审核、目录检索、统计分析等功能,为数据需求单位,数据管理单位及时掌握水务数据的供需需求提供了索引指南和资源目录。通过创新信息资源编目、资源公开属性审核、目录交换管理、目录检索及其统计分析,实现信息资源目录的共享。

2.2 水务数据监控与管理部分

主要用于满足不同层面水务从业人员对数据的管理和应用需求,分接入、交换和应用层3个层面进行应用设计,水务数据统一交换管理平台数据管理功能架构如图3所示。

2.2.1 接入层

主要针对市水务局各局属单位和行业管理部门的信息技术专业人员进行设计。设计能够满足信息技术专业人员对各自单位信息系统及其数据库运行维护管理需求的一系列实用便捷的功能,实现对数据库运行状态、连接情况、交换状态、异常报警等监控管理;提供交换监控、数据管理、故障报警、异常预警等应用服务,为信息技术专业人员及时掌握信息系统及其数据库运行状态提供有效、实时的监控和管理手段,减轻对系统及数据库的运维工作量,缓解人工检查信息系统及数据库状态的劳动强度。

2.2.2 交换层

主要针对市水务局信息化主管部门负责数据中心运行的专业管理人员进行设计。设计能够提供对全局供水,排水,水利3大行业相关信息系统与水务数据中心之间数据汇集、路由、订阅与发布、整合与质量管控等交换全过程的可视化监控,管理和配置等应用服务;提供无关计算机技术、简化、便捷、可视化的交换配置工具,实现随需随用、灵活调整的数据交换策略,有效降低对数据中心管理人员计算机专业技能水平的要求;此外还提供对数据交换过程中所发现的传输延时、交换中断、数据异常等情况进行在线监控和预警,一旦发现异常情况,通过短信等即时通讯手段及时告知数据中心管理人员。

2.2.3 应用层

主要面向市水务局机关和相关行业管理单位的领导和业务人员,基于面向水务专题应用的数据挖掘技术,提供能够满足各种行业管理应用和政府管理应用的数据报表、统计分析、趋势预测、评价评估等功能。该决策层面针对水务行业从业人员多而水务信息化从业人员少的特点,功能设计应实现与信息技术的无关性,力求降低水务行业从业人员运用本平台的门槛。

3 关键技术

3.1 基于消息中间件的统一数据交换技术

为了解决以往局属各单位之间网状数据交换带来的管理混乱和资源浪费,我们采用了基于消息中间件的统一数据交换技术进行数据交换,并以数据服务的形式提供了对JSON,XML和Web Service数据服务的标准接口支持,在上海水务行业中规范了同构、异构系统间进行信息共享、数据交换的方法,形成了系统之间数据交换的标准,规范并统一了数据交换中数据采集、发布、交换、路由、同步等各环节。

1)数据采集:各单位实时数据通过该平台经由数据抓取、甄别、汇聚、规范和整合等过程以统一规范的格式汇集到水务核心数据库。

2)数据发布:各单位可以根据各自需要定制所需业务数据,该平台按照数据属性、目的地、归属单位等条件,进行相关组合,并根据这些定制信息进行数据发布。

3)数据交换:通过统一消息中间件建立数据订阅和发布的单位之间的信息隧道,支持同步和异步交换2种方式,实现各单位之间多源异构数据的业务逻辑、数值转换、数据统计和规范整合,使各信息系统之间的信息能够更方便地共享和交互。

4)信息路由:水务业务流程复杂,会涉及多个单位的协同。这些流程对协同办公要求都比较高。在这些流程里,在不同环节调用不同来源的、存放在不同数据库中的数据,就需要交换系统具备信息路由功能,在具体业务流程的运行中,配合相应的1个或多个系统,在不同的环节采集、提供、处理并发布各类定制信息,实现数据的交互流转。

5)数据同步:由于数据源众多且分散布设,当某单位采集的某个信息发生变化时,相关单位都需要尽早根据这个信息更新自己数据库中的数据。数据同步可以根据不同的业务数据的实时性需求,设置同步参数,保证关键业务数据的实时性,不会让关键数据被淹没在海量的数据流中。为了减少网络故障对数据同步的影响,数据交换系统能够在网络恢复后自动恢复同步,保证数据同步的及时稳定。

3.2 基于J2EE框架的数据监控与进程管理技术

运用基于J2EE框架的跨平台开发技术,降低了对多源异构系统开发数据监控和管理模块的复杂性,实现了对XML,WCF,J S O N等标准数据接口的支持,提供了对现有系统的无缝集成。由于采用了MVC系统开发模式,把业务逻辑代码从表现层中清晰的分离出来,避免了表现层与业务逻辑层的代码混叠,实现了数据监控与管理平台功能扩充的易扩展和可持续性,简化了开发与后期维护的复杂度,拥有高性能、可靠及可扩展性的优势,能够满足未来不断增加的水务数据交换的监控和管理需求。

同时,为了减轻该平台后期运维中所需要投入的大量人力成本,我们基于J2EE框架开发了针对数据交换进程的智能管理程序。在该进程管理程序中模拟系统运维人员对数据交换关键环节的状态判断,对各种数据交换事件的状态情况进行智能研判,及时修正并恢复数据交换作业,最大限度减轻了系统运维人员在数据交换环节中的运维工作量。

4 系统功能的实现

4.1 统一数据交换与共享

基于统一消息中间件构成的数据总线,实现了市水务局及其局属单位、区县水务局、太湖局、国家防总、气象局等其他行业单位共27家单位52套应用系统与水务数据中心之间的数据交换与共享。

防汛数据交换方面实现了潮位预报、报汛水情、实时雨情、风速风向、积水监测、台风信息、闸泵工况、下立交积水、水务热线灾情、防洪工程数据、太湖水情、气象信息等数据的订阅和发布。

水资源数据交换方面实现了水资源取供用排多个环节相关的原水水厂、供水管网、供水测压点、供水水质、供水水量等数据的订阅和发布。

4.2 集中数据监管

为满足水务数据统一交换、集中数据监管的应用需要,基于B/S架构,设计了水务数据统一交换和共享管理平台,完成了交换平台、数据中心等功能模块。

在交换平台模块中,实现了对数据源端,交换端,目的端3个关键环节的数据采集、数据发布、交换效率、故障统计、数据交换情况统计、数据完整性、数据奇异性预警等功能。

数据中心模块中,实现对数据中心涉及的数据库运行状态、数据库配置、用户权限管理、数据交换节点注册等集中管理功能。

4.3 智能交换监控

为减轻数据中心管理人员的运行维护工作强度,专门设计了具有智能监控系统交换进程的守护程序,用于在线智能判断数据交换平台的运行情况,一旦发现数据交换平台中某一交换进程停止响应或出现其它问题,守护进程会采取相应措施,自动终止有问题的交换进程,并重新启动该交换进程程序,最大限度地保证相关数据交换的顺利进行。

4.4 面向应用的数据服务

以防汛、水资源应用为试点,针对防汛业务专题进行数据挖掘,实现了雨量、水位、风速风向、道路积水、水闸工况、泵站运行情况等相关数据的图表显示,单因子统计查询,多因子趋势分析等功能;针对水资源业务专题,实现了对水量日报、水质日报、水厂监测、供水泵站监测、管网监测、骨干河道水质评价、水功能区达标评价、河道综合指数评价等功能。面向水务业务应用提供了统一标准的数据服务和应用接口。

5 应用效果

水务数据交换和监控管理平台的建设,简化了市水务局与局属各单位之间、与区县水务局之间、与行业相关单位之间多源,异构的数据交换与共享;有效推动了信息资源的整合、共享、交换与应用;避免了由于规范标准不一、数据接口不一所带来的行业之间,部门之间的信息孤岛现象;辅助政府部门大大降低了信息化建设运维成本。

通过对水务数据交换和监控管理平台设计,对提炼出科学合理,行之有效的适合水务一体化管理需求的水务数据中心建设规范、水务行业基础数据库及其管理系统建设导则、水务公共信息平台运行维护规程等标准规范,具有促进的意义。

6 结语

本文提出的水务数据交换和监控管理平台的建设,在上海水务系统中探索了基于统一数据交换的数据总线模式实现资源整合和信息共享的新路子,对提升水务行业基础管理,提高各部门各单位的工作协同,提升政府公共服务水平起到很好的辅助作用。

参考文献

[1]潘大四.基于XML的异构数据库数据集成的关键技术研究[D].重庆:重庆大学,2004:1-74.

[2]曹成,舒坚,蔡轲,等.一种基于ebXML的数据交换系统架构[J].江西:江西师范大学学报(自然科学版),2007(3):316-320.

[3]徐俊杰.基于XML的数据交换模型研究[D].黑龙江:哈尔滨工程大学,2006:1-62.

[4]李冬睿.基于XML与Web Service的电子政务数据交换模型的设计与实现[D].广西:广西师范大学,2008:23-47.

[5]杨剑.基于XML的异构数据交换系统的研究与实现[D].四川:西南交通大学,2005:19-74.

统一数据平台 篇5

为切实加强全市畜牧水产系统网络信息化应用工作,提高我局信息化办公水平,构建完善畜牧水产网络管理系统,保障养殖业生产安全,维护人民群众身体健康,进一步加快我市养殖业经济又好又快发展,结合工作实际,制定本方案。

一、指导思想

以十七大精神为指导,紧紧围绕市局总体工作目标,以促进养殖业经济发展和重大动物疫病防控为重点,以确保畜水产品质量安全,维护人民群众身体健康为核心,按照“无纸化办公,网络化管理,信息化建设”的工作思路,解放思想,开拓创新,不断提高网络信息化工作水平。

二、工作目标

努力推进全局网络信息化应用工作,全力完善市局统一办公平台的建设,确保网络信息数据库的真实性和有效性,平台的使用与工作相结合,工作汇报在平台,工作处理在平台,工作完成在平台,工作考核在平台,真正实现办公无纸化,工作网络化,以高效的工作手段推进我市养殖业经济的又好又快发展。

三、主要任务

(一)加强网站建设,提高信息宣传工作效率。

1.强化网站信息更新工作。完善信息工作规程,明确网站工作任务,界定网站信息上传权限,确保网站栏目的更新工作。各级信息宣传部门明确专人负责媒体报道的信息收集、整理和上报工作,网站管理实行AB岗责任制,确保网站信息的日常更新。

2.规范网站信息管理。进一步规范网站信息的上传程序,抓好网站信息质量的把关和监督检查工作。积极做好信息更新和无效信息清理工作,规范网站信息宣传管理工作。

(二)强化电子政务,推进政风行风建设

1.提高平台使用率,强化网络意识。市政务统一平台的使用纳入政风行风评议工作进行考核,市局各处室要增强网络化办公意识,不断提升网络运用能力,将平台的使用纳入每日的正常工作范畴,保证平台登陆率和使用率,确保政务统一平台考核不扣分、不缺项。

2.提升平台工作水平,推进无纸化办公。局公文处理要全面实现网络平台流转,加大公文网络化管理力度,进一步提升平台公文处理水平,减少纸质公文的流转,严格按照公文流转程序办文办事,不断提高工作效率。

(三)加大市局统一办公平台应用,提高信息化工作水平

1.加强信息员队伍建设。不断提高信息员队伍的业务素质和水平。进一步完善市养殖业数据库的录入工作,统一办公平台的GIS地理信息系统启动应用,力争年底前完成国家级、省级养殖企业以及市级农贸市场、屠宰场的电子信息录入工作、积极推进电子地图的应用。

2.深入推进各类数据更新力度。各级各部门要继续做好日常工作留言和数据库各栏目的更新工作,确保在数据出现变化的一周内,将相关数据更新,保证各栏目数据更新的及时、准确和有效。

四、保障措施

(一)明确责任,狠抓落实。各级部门要加强对网络信息化工作的领导,分管领导要亲自抓,职能部门要具体抓,明确分工,加强配合,一级抓一级,层层抓落实。要结合工作实际,将各项工作任务层层分解、落实到具体职能部门,责任到人,做到有计划、有安排、有检查,常抓不懈。

(二)加强培训,提高技能。

对网站栏目信息的图片处理、稿件上传、文字排版,政务统一平台的应用能力,以及局统一办公平台的应用操作能力等适时进行培训,努力实现公文平台流转的高效率,推进GIS(地理信息系统)的有效应用。

(三)加大督查,推进考核。坚持把统一办公平台应用工作与信息宣传考核工作结合起来,定期、不定期地对其进行监督检查,发现问题,及时改进。严格考评,平台和网站的使用情况每月进行统计汇总,每季度对各部门网络运行情况进行通报。年底依据《市局宣传信息及统一办公平台应用工作目标考核意见》对当年办公自动化、信息化工作进行考核,对考核获得先进部门和单位给予表彰和奖励。

五、责任分工

探讨校园网统一验证平台的构建 篇6

【关键词】中职校 校园网 统一验证平台

【中图分类号】G71 【文献标识码】A 【文章编号】2095-3089(2013)01-0221-02

我校是2009年启动数字化校园建设的,目前在学校中运行着多个应用系统,如办公自动化系统,教务管理系统,财务管理系统,招生管理系统等等。但笔者在日常工作中经常遇到教师因忘记自己的各类密码而要求管理员帮其重设密码和教师反应在多个系统间要多次登录比较麻烦的问题。此次示范校建设,我们通过构建统一校园网验证平台,即单点登录SSO的方法成功解决了上述问题。

一、统一验证平台的构建思想

SSO英文全称Single Sign On,单点登录。SSO是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统。它包括可以将这次主要的登录映射到其他应用中用于同一个用户的登录的机制。它是目前比较流行的业务整合的解决方案之一。我们比较了多种方案后,最终采用了SSO方案,教师只需要登录一次系统平台,即通过一个应用中的安全验证后,再访问其他应用中受保护的资源时,不再需要重新登录验证。

二、统一验证平台的具体实现

以下是笔者所在学校各个系统间统一验证平台的构建的具体过程:

1.各应用系统介绍

笔者所在学校的校园网中布署的应用系统有:

(1)信息发布系统(学校网站);

(2)资源管理系统(资源库)用于管理学校内部的资源(教案、课件、试题、教育教学论文、图片等资源)。未登录用户不能下载和打开相应的资源,只有合法登录的用户才能下载和打开;

(3)学校网络办公系统(OA系统);

(4)教务管理系统(正方教务系统);

(5)财务管理系统(国子管理系统);

(6)招生管理系统(教师自己开发)。

2.配置表信息

在开发单点登录系统之前有些重要信息需要确定,然后写入配置信息表中。我校配置信息表中内容如下:

设置服务器的访问地址。主要是服务器的公共IP地址和站点域名。

设置可以访问的请求IP网段。主要记录该系统单点登录接口可以访问的IP来源。

设置系统模块标记。填写各个系统的编号,主要用于变节管理员查询到该请求来自哪个系统。

设置状态标记。填写True或False,主要方便管理员随时切断单点登录的功能。

3.配置表逻辑结构

4.系统单点登录原理

1)用户通过用户名和密码进入A系统;

2)A系统将配置表中状态为T标记的所有记录读取并打印到前台;

3)当用户点击任意系统后,A系统就会将该用户的编号,以及配置表中的A系统的参数一并通过http协议提交到目的系统中;

4)目的系统则会根据配置表中的REQIP来判断该请求IP是否合法,若合法则继续执行,否则返回错误信息;

5)目标系统只需要到用户表中去寻找该编号对应的用户,并取出其权限,根据相应的权限执行可操作模块;

6)如此反复循环。

5.SSO模式的前提条件

SSO模式需要满足如下条件后才能部署:(1)所有的用户ID要么统一,要么设置匹配规则,我校选择使用教师工号;(2)所有系统必须在配置表中登记真实的信息;(3)所有的系统必须提供接口,用来接收和处理配置表信息的WebServer接口。

6.SSO模式优缺点

SSO模式有很多优点:实施简单,只有短短几行代码执行效率高;安全性高;无需笛卡儿积模式的维护,只要一张配置表即可;扩展性、维护性高;采用即插即用设计原则。同时也存在一些缺点,如对服务器安全性要求较高;旧系统必须有源代码更改权才可加入;目前只限于B/S模式。如何扬长避短需要开发人员不断摸索、不断实践。

7.提高安全性

安全是每个系统最首要的责任,我们采取以下安全措施保证单点登录的安全。

用户在客户端触发,提交到服务器中处理,所有信息都在服务中,非法窥视不到;

服务器之间的跳转也限制了IP,只能由指定的IP才可以访问;

客户端只提供触发功能的Ajax异步执行方法,主要代码在后台服务器上用户无法得知,前端的JavaScript代码只提供了访问服务器接口的功能和仅有的目的系统编号参数;

JS代码与html代码分离在两个文件中,并且服务器过滤了请求IP,非本地IP禁止下载JS文件,而且本地IP还要密钥才能访问,大大提高了安全性;

每个用户的权限都在相应的系统中分别设置,避免其中一个系统的管理员被攻击从而使整个架构陷于危难之中;

所有的共用信息都通过加密算法处理后再传输、存储的,避免管理员有意识的获取;

从系统到模块甚至到用户都有很便捷的开关功能,可以及时的切断危险源。

三、统一验证平台构建的思考

随着网络信息化技术在我国职业学校校园网络中的高速发展及应用,学校门户平台需要及时整合各类信息资源。笔者根据目前学校中电子校务实际运用中存在的信息孤岛问题,研究了单点登录技术的原理及实现方法。由于水平和时间的限制,以及随着对相关理论和开发的深入,还有待于继续努力。

通过此次开发,笔者所在的学校切实解决了教师以往要记住各个系统间的帐号与密码和各个系统要多次登录的问题。方便教师日常的教育、教學工作,进一步提高了教师的工作效率。实现了学校各个系统间用户的统一管理,减轻了系统管理员的工作负担。

参考文献:

[1]Web环境下的SSO实现模式的研究 张挺; 耿继秀 计算机仿真 2005-08-30

[2]基于RBAC的SSO统一权限管理方法 张世龙; 沈玉利 计算机工程与设计 2009-05-16

统一数据平台 篇7

1 目前高校信息化过程中遇到的主要障碍

目前我国绝大多数高校都已建成了数字化校园,依托校园网络各职能部门、学院也基本上建成了适合本部门需求的软件系统。软件系统主要有高校门户网站、网络智能办公系统、教学管理系统、财务管理系统、科研管理系统、校园一卡通、邮件系统等软件系统。总的来说,目前高校信息化过程中遇到的主要障碍有以下几种。

1.1 硬件投资大,利用率低

高校信息化建设是一项投入大,参与部门多,实施难度大、风险大的系统工程,是学校管理模式、管理方式的重大变革。高校信息化建设是一个长期、连续的过程,绝大多数高校在此过程中,硬件设备投资巨大,而软件投资相对较少。缺少软件支撑,硬件无法充分发挥其功效,造成大量硬件设备闲置,资金浪费,高校信息化没能为高校教学、科研和管理发挥应有的作用。

1.2 院系、职能部门之间基础数据不一致

目前高校各部门的软件系统相对独立,相对孤立的软件系统要正常运行,基础数据就要多次重复录入,造成基础数据结构不一致,效率低下。数据标准不统一,是导致部门之间基础数据不一致的根本原因。信息孤岛是高校信息化建设过程中的必然阶段。存在这样的现状是有历史原因的,在相当长的一段时期内,各个院系、职能部门根据自己的需要,进行部门级的信息系统建设开发,开发平台和所采用的数据库也不可能完全一致,造成数据无法共享。

2 建设统一数据中心平台思路

高校信息化建设,就是要建设一个科学合理的符合高校实际需求的数字化校园。建设统一数据中心平台对于高校来说,既是技术上的挑战也是管理模式上的挑战。建设统一数据中心平台的目的是要打破由条块分割导致的部门之间的数据孤岛,在保证基础数据的有效性、权威性和准确性的基础上,使部门间最大限度的共享基础数据。

2.1 科学全面地做好高校信息化建设总体规划

做好总体规划是高校信息化建设的关键,目前在高校信息化建设过程中遇到的各种问题,大多与前期高校信息化建设缺少科学全面的总体规划有关。

2.1.1 确立明确的信息化建设目标

每引进一项软件系统,都应考虑其功能指标是否能满足信息化建设近期需要。其基本性能是否能满足今后若干年的发展需求,是否与信息化建设总体规划相一致,软件系统的技术支持和服务质量是否有保证。

2.1.2 统筹管理使用各类信息资源

统筹管理使用各类信息资源,减少重复投资、重复建设。

2.2 构建统一的数据标准

构建统一数据标准,共享基础数据就是把部门与部门之间、系统与系统之间交互的信息提取出来,部署到共享数据中心中,从而彻底解决不同软件系统之间的数据交换问题。

2.2.1 建立信息化管理规程

新上软件系统要有报批制度;新上软件系统要与学校的总体规划相一致;新上软件系统要符合学校的信息化标准规范。对于没有报批、与学校总体规划不一致或者不符合学校信息化标准规范的软件系统学校不予资金支持、软件系统不予验收、不允许在校园网上运行。逐步完善管理机制和必要的奖惩措施以推动高校信息化建设进程。

2.2.2 建立信息标准

没有标准就不存在规范。统一数据中心平台的建设涉及到高校多个部门的软件系统,由于各个软件系统是针对各个部门、院系的需求开发设计的,开发设计前期的需求调研阶段,缺少高校信息化建设科学统一的规划,软件系统间信息无法交换。因此建设统一数据中心平台首要的任务是要建立信息标准。建设统一数据中心平台主要包括有数据采集、数据存储、数据共享和数据更新四个方面。数据采集的数据源来源于现有的各个业务系统,是将现有的各个业务系统中的基础数据抽取出来,统一交由数据中心平台来管理。数据存储是将采集得来的数据统一交由数据中心平台的数据仓库来保存管理。数据共享是将统一数据中心中的基础数据按照权限共享给原有的和未来引进的软件系统来使用。数据更新这里主要指的是更新统一数据中心平台数据仓库中的基础数据,原则上是数据谁产生谁负责更新。无论是数据的采集、存储、共享还是更新,都需要一个明确的信息标准,需要确定哪些数据是基础数据。

2.2.3 建立共享数据库

在高校信息化建设过程中涉及到的应用系统体系结构大致可以分为三类,前置的门户表现层、中间的业务逻辑层和后台的数据仓库层。为了适应业务需求,前置的门户表现层可能是五花八门,中间的业务逻辑层与软件系统的应用紧密相关。由于当前安全、可靠、运行稳定的数据库种类不多,所以我们可以选用其中一种用来作为后台的数据仓库。

2.3 建立长效反馈机制

高校信息化建设人员大多不是各软件系统的最终使用者,所以要建立一套长效的反馈机制来收集各软件系统的使用反馈信息,来促进高校信息化建设发展。

3 结束语

高校信息化建设是一项艰巨、复杂而富有挑战的系统工程,建设统一数据中心平台是我们在推进高校信息化过程中的一些体会。建设统一数据中心平台在我校信息化建设过程中取得了一些成效。但是建设统一数据中心平台的思路还尚不完善成熟,希望得到同行专家的批评指正、补充和完善。

摘要:在高校信息化建设过程中,各学院、职能部门大都根据自己的业务需求已经建立了多个软件系统。由于前期缺少整体规划,各软件系统没有遵循统一的信息化建设标准及数据接口规范,造成学院、职能部门间信息交互、数据共享成为难题。本文为着力解决此问题,提出了在同一高校内建设统一数据中心平台的构想。

关键词:数字化校园网,数据中心,数据库,信息共享,统一数据平台

参考文献

[1]景运革.高校共享数据库平台设计与实现[J].山西大同大学学报:自然科学版,2008,2(5):82-84,87.

[2]沈锡臣,陈怀楚.高校信息化建设标准规范[J].清华大学学报:自然科学版,2003,43(4):529-531,536.

[3]汪益民,武咸春.建立数据中心-设计统一数据平台[J].计算机教育,2007(3)881-882.

[4]王磊,李林林,朱彦峰.浅析高校数据中心建设[J].黑龙江教育:高教研究与评估,2006(9):69-71.

[5]王磊,李林林,周学理.浅析高校数据中心建设的问题及对策[J].科技与管理,2006(6)144-146.

统一数据平台 篇8

由于各种原因现存的大多数调度中心都是同时运行着多套电力自动化系统, 比如说广域动态安全监测系统 (WAMS) 、能量管理系统 (EMS) 、能量采集与计费系统、故障信息管理系统等[1]。电力自动化系统过多, 那么在维护电力公用数据的时候就经常出现不完整或者不一致的情况[2]。另外, 由于各个系统之间是互相独立的, 为数据信息的共享等造成了很大的困难[3]。基于此, 本文充分结合实时公共对象请求代理体系结构 (CORBA) 技术以及IEC61970标准, 提出了在电力调度中心逐渐构建统一数据平台的设计方案, 这样便能够实现公用数据的统一应用与管理, 同时使得各个系统之间的数据信息共享性得到提升。

1 设计思路

本文中所设计的方案在技术层面上更侧重于实时COR-BA技术, 根据统一规划、分步实施的方式, 在调度中心能够真正达到电力图形、模型以及实时数据的在线统一的目的, 另外, 还支持库、模、图一体化的版本管理体系。

从实际工作层面而言, 本文中所建立的统一数据平台其最终的目标主要有三部分, 分别为电力公用数据访问服务、数据的管理以及系统之间互联。也就是说:实现电力公用数据的集中管理、统一建模, 注重数据的一致性维护、安全备份与版本管理;针对调度中心各个自动化系统提供对公用数据实施访问的快速、安全访问接口;系统之间的互联以通信中介者的身份来进行, 降低了系统间的两两通信, 从而降低了互联所要求的工作量。如图1所示为统一数据平台总体工作形式。

2 公用数据管理

其中, 电力系统公用数据涵括了设备铭牌、地理位置、连接关系、用电用户属性、组织归属等静态信息, 还涵括了设备物理状态、运行管理信息、运行质量信息、网络拓扑关系等动态信息。

统一数据平台中的公用数据管理功能主要有数据建模、版本管理、数据变更、安全管理、数据备份等内容。公用数据管理可以分为两个步骤来完成:首先完成静态信息统一管理, 再次完成动态信息统一管理。

静态信息管理是在大型商用数据库管理系统的基础上实现的, 支持双机磁盘阵列。而公用信息建模是在IEC6197IEC61968标准基础是实现, 另外还可以实现用户自定义扩展。

2.1 公用信息建模

推出IEC61970/EC61968标准之后, 为公用信息统一建模打下了坚实的基础。以一次设备为中心的思想在统一数据平台数据模型中得到了特别的关注, 其它的比如二次设备定值、参数、操作信息、动作记录、运行数据等全部以一次设备为中心实施管理, 这样就确保了整个数据信息的持久的可用性、可维护性以及稳定性。

统一数据平台可以实现以库、模、图一体化形式建立电网信息模型。利用平台提供的图形建模工具就可以在计算机中直接对一次接线图以及地理信息图进行绘制, 实现组织管理信息和电力设备参数的同步建立, 同时自动产生设备连接关系。通过维护计算机图形就能够对电力设备模型尽心维护, 包括电力模型变更以及模型完整性检查等等。通过图模一体化技术能够在很大程度上降低电力模型建立以及维护的工作难度以及工作量, 从而减小了出错的可能性。

由于电力系统的建设一直在进行, 而历史统计分析、调度员培训系统 (DTS) 教案、事故分析等应用功能都要求历史的电力模型还有对应的历史运行状态。所以在统一数据平台当中, 对电力模型进行更改的时候必须要特别强调版本管理, 应该支持版本回退和并行编辑, 这样能够实现对电力系统发展以及建设历史的完整记录。如图2所示, 在商用数据库管理系统中实施签出 (checkout) 操作就能够获得历史模型以及状态数据;实施签入 (Checkin) 操作就能够修改版本;在多个版本间实施归并 (merge) 操作就能够实现数据的并发编辑。最后, 将一致且完整的电力模型数据体现 (apply) 至电力应用中。另外再加上统一数据平台主持长事务, 有效的确保了调度中心多个自动化系统对于公用数据的并发修改。

2.2 公用信息维护

在统一数据平台当中, 通过商用数据库管理系统的备份以及恢复机制可以完成公用数据的备份以及恢复, 支持定期、自动地将一致和完整的静态数据以及动态数据备份至磁带机和光盘上, 基于磁盘阵列技术、双机冗余热备技术保证了数据的高可靠性。

根据相关的要求, 调度中心中全部自动化系统必须按照安全性原则分别放在4个安全区中。其中, EMS、WAMS、配电管理系统 (DMS) 等置于安全Ⅰ区;电能计量系统、水调自动化系统、故障信息管理系统、电力市场交易系统、DTS等置于安全Ⅱ区;雷电监测系统、DMIS等置于安全Ⅲ区;管理信息系统 (MIS) 、办公自动化 (OA) 系统等置于安全Ⅳ区。因为Ⅰ、Ⅱ区和Ⅲ、Ⅳ区之间无法直接进行网络联接, 必须利用物理隔离装置来完成间接通信。基于此, 可以在调度中心建造2套统一数据平台:一套放在安全Ⅱ区, 为准实时系统、实时系统、控制系统提供公用数据;另外一套放在安全Ⅳ区, 为办公管理系统、生产管理系统提供公用数据。本文讲述的统一数据平台指的主要是放在安全Ⅱ区的公用数据平台。

3 数据访问方式

IEC61968接口参考模型 (IRM) 以及IEC61970组件接口规范 (CIS) 就决定了电力应用模块之间信息交换以及公用数据获取的基础框架, 另外对于具体不同的应用规范了信息获取的标准数据访问接口以及消息格式、消息类型。所以说提出这些国际标准之后, 为建造调度中心统一数据平台打下了坚实的基础。

统一数据平台能够提供3种接口形式, 如图3所示, 以便为调度中心其它自动化系统提供相关的数据服务, 其中这3种访问接口可以分阶段来实现。首先是在通用信息模型 (CIM) 中可扩展置标语言 (XMIJ) 文件导入以及导出形式的基础上实现了结构化信息的交换, 其它自动化系统电力模型数据根据CIM标准导入到统一数据平台, 或者根据CIM标准将电力模型数据从统一数据平台中导出。其次是满足通用接口定义 (CIS) 的通用识别符 (GID) 规范的公用数据访问接口, 可以实现准实时、非实时的形式, 根据层次关系以及电网结构来查询、检索以及订购统一数据平台中包含的静态电力模型以及当前或者历史的运行状态信息。最后, 为了顺应IEC61970IEC61968标准不断发展, 慢慢实现针对具体应用的专用数据访问接口, 比如说负荷预测、网络拓扑、监控与数据采集 (SCADA) 等。

从低层具体实现形式层面看, 统一数据平台其数据访问接口可以基于Web Sevrice/简单对象访问协议 (SOAP) 技术、客户/服务器 (C/S) 结构、J2EE技术、实时CORBA技术等, 如图4所示。其中非实时的静态模型数据接口在Web Service技术的基础上来实现。实时、准实时数据的访问在实时CORBA技术的基础上来实现, 实时CORBA技术能够满足通用CORBA规范, 此外还结合了多线程服务管理、实时以太网技术、快慢数据通道技术以及持久连接管理技术。在统一数据平台的CORBA实现过程中, 提供了权限管理服务、名称服务、事件服务日志服务等四个基础服务组件。

对于其它的调度中心电力自动化应用系统而言, 利用统一数据平台的各类数据访问接口实现访问并修改本系统所需要的静态模型数据, 还可以获取本系统所需的或者由其它系统产生的动态数据, 同时把本系统产生的或者其它系统所需要的动态数据储存在统一平台的实时数据库当中。

4 系统间的互联

在建设完成调度中心统一数据平台之后, 各个调度中心电力自动化系统之间以及同一调度中心内部系统之间都可以实现互联以及互操作。

在所有的调度中心都建立统一数据平台, 那么本调度中心电力自动化应用系统就可以通过统一数据平台实现通信。而对于2个调度中心而言, 只有这2个统一数据平台之间才能够实现互联以及通信。但是, 针对具有特殊通信需求的系统间通信而言, 还是可以按照系统之间直接互联的方案进行设计以及实施。

调度中心内部中不同自动化系统之间可以分别实施组网, 并且经接入路由器或者交换机接入电力调度数据网 (SP Dent) 。处在安全Ⅰ区的自动化系统比如EMS和WAMS等, 可以通过网络防火墙实现和统一数据平台的互联;处在安全Ⅱ区的自动化系统比如DTS可以同交换机直接和统一数据平台实现互联。而2个调度中心统一数据平台则利用SPDnet专用网络来实现互联, 且利用选定的远方电力通信协议来实现通信。

5 结束语

对于不同的电力自动化系统而言, 怎样快捷方便的实现它们之间的系统互联以及信息共享, 是现阶段各个调度中心亟需解决的实际问题。已经有人开始着手建立调度中心统一数据平台, 想要实现对各种自动化系统的统一调度, 包括电力市场系统、EMS、WAMS、雷电系统、电量计费系统、水调系统等。从而实现系统数据和模型的共享, 使得自动化水平得到显著提升、开发厂家的技术优势得到充分发挥。本问所设计的统一数据平台旨在解决上述问题。

摘要:充分结合实时公共对象请求代理体系结构 (CORBA) 技术以及IEC61970标准, 提出了在电力调度中心逐渐构建统一数据平台的设计方案。在数据访问方式、公共数据管理以及系统之间互联这三个方面进行了深入的研究, 以便实现电力系统中公用数据的统一维护和建模, 确保了电网公用信息的可维护性、安全性以及一致性。

关键词:公用数据,统一数据平台,数据访问,电力调度中心,系统互联

参考文献

[1]杨旭东.分析电力调度中心统一数据平台的设计[J].电源技术应用, 2013 (9) :323, 327.

[2]柏望江.电力调度统一数据平台的设计[J].华东科技:学术版, 2015 (10) :212.

统一数据平台 篇9

随着电网企业坚强智能电网建设的逐步推进, 产生了大量的实时数据, 继而沉淀生成海量的历史数据, 这些海量实时/ 历史数据都是电网企业生产运行过程中的重要财富, 是实现精益化管理的重要信息基础。在这一背景下, 浙江省电力公司积极探索和尝试, 初步建立了以国产实时数据库为基础的实时/ 历史数据平台, 以满足各业务应用对实时/ 历史数据进行存储、整合、共享以及统一和标准访问的需求。但目前平台在应用层面仍缺少统一规划, 亟需形成一个统一的应用技术架构。

1 现状分析

实时/ 历史数据平台是对电网生产运行过程中各业务应用形成的实时/ 历史数据进行存储、集中、整合、共享和分析的场所, 同时提供标准统一的访问方式, 是为智能电网和SG-ERP各业务应用——特别是跨专业、跨部门的综合业务应用在实时/ 历史数据层面提供技术支撑的信息基础设施[1,2]。

《国家电网公司海量历史准实时数据管理平台典型设计》中对实时/ 历史数据平台进行了明确定位:一方面是SG-ERP的实时数据中心, 与结构化数据管理平台、空间数据管理平台和非结构化数据管理平台共同构成SG-ERP数据中心;另一方面, 也是各业务构建实时/ 历史数据计算分析应用的基础支撑平台。根据国家电网公司典设要求, 实时/ 历史数据平台在数据管理和应用管理上都要具备良好的可扩展性和可维护性, 以支撑各业务应用持续发展的需要。同时要求在实时/ 历史数据平台建设过程中, 确保业务应用规范化实施和统一化管理。

目前, 国内外针对实时/ 历史数据应用的技术框架主要偏重于数据管理方面, 如数据接入、存储、访问等方面的技术框架和技术标准较多[3,4,5]。对于应用技术框架, 则没有相关的规范和标准。

从国家电网公司内部来看, 华北、上海等实时/历史数据管理平台建设试点单位偏重于数据管理方面规范和技术的研究, 在应用规划和应用实现技术框架上, 都没有深入的研究和成型的成果。

浙江电力在2012 年开展了实时/ 历史数据平台验证性研究和建设工作, 制定了实时/ 历史数据平台技术规范, 初步在实时/ 历史数据的接入、存储和访问方面制定了相应的技术规范, 并在此基础上构建了浙江电网实时/ 历史数据平台。但在平台应用规范化管理方面, 尚未制订相关的标准和技术规范, 大多地市局个性化应用使用平台提供的二次开发工具实施, 少量全省标准化应用沿用相关厂商各自的技术框架, 并且按照各自的应用实施方案设计、开发和运维具体业务应用, 且独立部署。这与全省“统一平台”理念相背离, 也不符合国家电网公司典设方案中实时/ 历史数据及其应用的集中、统一管理要求。

因此, 从平台应用集中、统一和标准化管理要求出发, 综合考虑平台应用的可持续发展, 在“统一平台”应用规范化管理层面应对平台应用技术框架规范进行统一。

2 统一应用技术架构

2.1 总体架构

根据国家电网公司典设要求, 浙江电网实时/ 历史数据平台采用全省大集中的部署模式。为了促进平台上应用的规范化发展, 尤其是省级综合应用的统一规划和实施, 应采用统一的应用技术架构, 即参与平台上应用建设的开发单位必须遵循统一的应用技术框架实施平台标准化应用, 使得不同的业务功能模块将打包合并到一个运行环境中。应用平台总体架构如图1 所示。

该架构主要有以下特点。

1) J2EE架构。应用平台基于J2EE架构, 所有应用模块将运行在一个统一的Web APP中。

2) 数据库。业务应用基于实时数据库和关系型数据库, 实时/ 历史数据都存放在实时数据库中, 各业务应用通过实时数据库提供的API、SDK等实现对实时/ 历史数据的访问。应用平台中用户、组织结构、应用权限及元数据 (测点属性中与具体业务密切相关的元数据) 管理等采用关系型数据库进行存储和管理。

3) 系统鉴权服务。业务用户对应用系统的访问必须通过平台提供的鉴权服务, 只有合法的用户能够访问相应的业务模块。

4) 单点登录。系统实现与企业门户系统的集成, 并实现用户单点登录, 用户登录企业门户后, 无需输入用户名和口令, 可直接访问集成的各应用系统。

5) 基础业务应用。应用系统平台的基础应用主要包括组织人员管理、应用权限管理、系统管理、个人主页设置和测点管理等功能模块。1组织人员管理:主要用于提供覆盖全省的各业务单位的组织结构, 以及与之相对应的用户信息。2应用权限管理:提供对系统用户的角色分配功能, 并对所有业务模块相关功能进行权限的配置和绑定。3系统管理:为具体业务应用系统提供服务监控、日志记录、活动审计和系统参数配置等。4个人主页设置:主要提供用户个性化的主页设置, 包括一些用户个性化参数设置。5测点管理:是对实时/ 历史数据平台原测点管理功能的扩展, 在关系型数据库中维护测点的基本信息, 提供实时数据库测点与运检、营销、调控等专业平台中设备的对应关系, 同时提供测点关联关系的维护, 并可绑定相关权限。

6) 按专业分类业务应用。未来应用平台将广泛应用于运检、调控、营销、规划辅助以及信息资源监控等业务的信息化管理, 这些业务功能模块将基于实时/ 历史数据平台, 采用统一的基础架构, 包括组织、人员、权限、测点管理等, 为各专业定制功能。

7) 系统接口服务。应用平台中将提供统一的系统接口服务, 对外部业务系统 (如运检、营销、调控等系统) 提供实时/ 历史数据和相关业务功能的访问。同时提供对接口服务的监控和审计。

2.2 应用权限管理

在实时/ 历史数据应用平台中, 采用基于角色的访问控制 (Role-Based Access Control, RBAC) 方法进行应用权限控制。在RBAC中, 包含用户、角色、许可权等基本数据元素, 权限被赋予给角色, 而不是用户, 当某个角色被指定给某个用户时, 此用户就拥有了该角色所包含的权限[6,7,8]。会话Sessions是用户与激活的角色集合之间的映射。RBAC3 模型如图2 所示。

RBAC3 模型在传统的RBAC模型上引入了角色继承和责任分离2 种特性, 采用RBAC3 模型的权限控制具有以下特点。

1) 权限指派关系可以根据需求和临时情况动态调整和修改。由于权限与角色相关联, 用户通过成为适当角色的成员而得到这些角色的权限, 这极大地简化了权限的管理。在一个组织中, 角色可根据业务工作而被建立, 用户则依据相应的责任和资格来指派相应的角色, 用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而被赋予新的权限, 而权限也可根据需要而从某角色中回收。

2) 角色可继承。除了具有自身的属性与权限之外, 还可以继承其他角色, 从而自动拥有被继承角色的属性与权限。如付费用户可以继承普通用户的属性与权限, 超级管理员可以继承普通管理员的属性与权限。

3) 角色可约束。约束原则将在权限被赋予角色时, 或角色被赋予用户时, 以及当用户在某一时刻激活一个角色时被强制性遵循。约束原则包括角色的互斥关系, 即互斥角色不能同时处于活动状态, 以及角色的最大活动会话数量受限规则等。

4) 提供对实例级别对象控制权限。在RBAC模型中, 资源对象是权限控制的目标, 将资源与角色指派关系绑定后将决定用户对资源的操作权限[9,10], 因此在应用平台中资源的定义及划分的颗粒度决定了系统权限控制的精细程度。权限设置方法见表1 所列。

2.3 个人主页设置

实时/ 历史数据应用平台为用户提供灵活的页面展示方式, 除了默认的主页外, 用户还可以自定义个人主页, 并可选择登录后采用何种主页模式。

1) 缺省主页展示。系统默认为每个用户提供应用访问主页, 根据权限设置情况, 每个用户的主页中只展示允许该用户访问的业务功能模块, 每个应用模块提供一个入口链接, 用户通过入口可进入系统, 每个业务应用具有独立的页签展示导航菜单和数据视图。当管理员重新分配用户权限后, 用户默认主页中相应业务模块展示将进行调整。用户可在工作台页面上查看业务模块的属性, 主要包括业务模块相关的权限设置情况。如果该用户具有该模块的管理权限, 可进行角色添加和用户指派。

2) 个性化主页定制。用户可以对个性化主页的布局进行选择, 系统支持多种布局方式。用户选定的布局方式将作为用户的个性化参数之一, 可以自行进行维护。用户可以在选定的布局中, 设置需要展示的内容组件。每个业务应用都可以配置作为展示的资源 (可以在应用权限模块中由管理员进行配置) , 如果用户具有这些资源的访问权限, 即可选择并放置到个人主页中。用户可对个人主页中的内容组件进行维护, 包括增加或删除, 同时也可在页面中拖拽调整各内容组件的位置。用户设置完成个性化主页后, 登录系统时将默认打开该页面。

2.4 测点管理

应用平台中的测点管理主要是为了建立实时数据库测点与外部其他业务系统设备模型之间的对应关系, 并建立相关的设备对象元数据。设备模型对应关系如图3 所示。

目前外部业务系统主要有生产系统、营销系统和调度系统等, 这些系统均有自身独立的设备管理模型, 当实时/ 历史数据平台接口服务器接入设备测点数据时, 如果只建立设备和测点的对应关系, 则最终无法形成不同业务系统之间设备模型的对应, 而通过设备元数据 (包括设备类型、电压等级、所属单位、变电站、间隔、设备名称等) 的维护管理, 可以判定重要元数据一致的测点所采集的数据来自于同一台设备资源, 为将来跨业务系统进行业务功能设计提供基础。同时通过建立对象元数据, 可以更方便地对测点对象根据元数据 (如按电压等级、设备类型等) 进行分类统计和查询。

此部分的主要功能如下。

1) 自动建立测点对应关系。当系统从接口采集数据时, 根据预先建立的设备匹配原则, 对满足条件的设备自动创建测点和设备对应关系, 并提取设备元数据信息。设备元数据信息包括设备类型、电压等级、变电站、所属单位、数据所属业务系统、设备名称等。

2) 提供手动方式对测点关联信息和设备元数据进行维护, 包括信息的增加、删除、修改和查询。

3) 提供对测点数据的分类统计报表, 用于分析测点建设情况。

4) 提供对测点对应关系和元数据的导入和导出, 数据格式可采用CSV或XML。

2.5 系统接口服务

实时/ 历史数据平台需要为外部系统提供一系列数据访问服务, 涉及的数据范围包括电网数据、电量数据、设备监测数据、用电运行数据、电能质量数据、环境气象数据、雷电监测数据、发电运行数据以及其他历史/ 准实时数据等。

应用平台向外部业务系统提供Web Service服务, 采用标准的跨平台的方式提供数据访问服务[11,12], 具体功能如下。

1) 提供的Web Service服务支持用户验证, 通过验证的用户在访问相关数据时需要满足应用平台中数据访问权限设置, 用户无法访问未经授权的数据。

2) 提供各类历史/ 实时数据的查询服务, 包括最新数据查询、历史数据查询、历史数据统计、报警时间查询等。

3) 可以通过设置启用或禁用指定的数据访问服务。

4) 可以对服务的访问者进行启用或禁用管理。

5) 可以对数据访问情况进行统计分析, 对可能造成性能问题的服务进行分析并实施控制。

3 结语

实时/ 历史数据平台应用技术架构是实时/ 历史数据平台研究的一个重要领域, 与核心基础数据库产品以及数据规范化接入、存储、访问的研究有着同等重要的意义。通过对实时/ 历史数据平台上应用现状的分析, 研究满足各业务应用需求的统一技术构架, 一方面可以提升实时/ 历史数据平台应用的整体管控能力, 改变现有平台上业务应用缺少统一规划和规范化技术架构的现状, 改变现有应用技术支持厂商各自为政、存在技术壁垒的现状, 形成平台应用建设的良性生态链;另一方面可以提升实时/ 历史数据平台应用的信息化水平, 有效地沉淀和积累技术及业务能力, 提升应用的实用化水平, 有利于平台应用能力的可持续发展。

参考文献

[1]方明霞.PI数据库在浙江电网的应用现状与展望[J].浙江电力, 2010, 29 (4) :51–54.FANG Ming-xia.Application situation and prospect of PI in Zhejiang power grid[J].Zhejiang Electric Power, 2010, 29 (4) :51–54.

[2]王俏文, 陶文伟, 丁坚勇, 等.基于PI数据库的供电企业实时数据中心的设计与实现[J].电力系统自动化, 2009, 33 (6) :99–103.WANG Qiao-wen, TAO Wen-wei, DING Jian-yong, et al.Design and development of power supply enterprise real-time data center system based on PI database[J].Automation of Electric Power Systems, 2009, 33 (6) :99–103.

[3]樊勇, 徐孝忠, 严浩军, 等.电网企业实时数据管理方法和工具的探讨[J].华东电力, 2012, 40 (3) :485–487.FAN Yong, XU Xiao-zhong, YAN Hao-jun, et al.Real-time data management methods and tools for power grid enterprises[J].East China Electric Power, 2012, 40 (3) :485–487.

[4]张鹰, 汤磊.SCADA与PI间的数据接口及通信规约设计[C]//2006电力系统自动化学术交流研讨大会论文集, 2006:195–197.

[5]田家英, 赵舫.PI实时数据库在供电企业中的应用[J].电力系统保护与控制, 2006, 34 (15) :46–49.TIAN Jia-ying, ZHAO Fang.Application of PI real-time database in power supply enterprise[J].Power System Protection and Control, 2006, 34 (15) :46–49.

[6]张燕燕.基于角色访问控制的实现研究[J].网络安全技术与应用, 2006 (8) :53–54.ZHANG Yan-yan.Implement of role-based access control[J].Network Security Technology and Application, 2006 (8) :53–54.

[7]姜宇锋, 付钰, 吴晓平.基于RBAC的权限系统设计与实现[J].计算机与数字工程, 2009, 37 (6) :98–101.J I A N G Yu-f e n g, F U Yu, W U X i a o-p i n g.D e s i g n a n d implementation of authorization system based on RBAC[J].Computer and Digital Engineering, 2009, 37 (6) :98–101.

[8]董永峰, 陆军, 刘建波, 等.改进的RBAC模型在信息服务平台上的应用[J].计算机应用与软件, 2012, 29 (5) :99–103.DONG Yong-feng, LU Jun, LIU Jian-bo, et al.Application of improved RBAC model to information service platform[J].Computer Applications and Software, 2012, 29 (5) :99–103.

[9]吴江栋, 李伟华, 安喜锋.基于RBAC的细粒度访问控制方法[J].计算机工程, 2008, 34 (20) :52–54.WU Jiang-dong, LI Wei-hua, AN Xi-feng.Method of finely granular access control based on RBAC[J].Computer Engineering, 2008, 34 (20) :52–54.

[10]赵卫东, 毕晓清, 卢新明.基于角色的细粒度访问控制模型的设计与实现[J].计算机工程与设计, 2013, 34 (2) :474–479.ZHAO Wei-dong, BI Xiao-qing, LU Xin-ming.Design and implementation of fine-grained RBAC model[J].Computer Engineering and Design, 2013, 34 (2) :474–479.

[11]陶敏, 郭宁.PI实时/历史数据库系统平台架构优化[J].浙江电力, 2011, 30 (8) :1–4.TAO Min, GUO Ning.Optimization of platform architecture for plant information database[J].Zhejiang Electric Power, 2011, 30 (8) :1–4.

统一数据平台 篇10

随着通信行业竞争的不断加剧, 运营商如何有效地利用庞大的信令数据进一步实现深度运营和精确营销已经成为当务之急, 急需一种可控投入就可满足可控信令数据存储, 并能高效地对其分析、挖掘信令数据价值的数据平台。Big Data”大数据”是继云计算、物联网之后IT产业又一次颠覆性的技术变革, 对国家治理模式, 对企业决策、组织和业务流程, 对个人生活方式都将产生巨大的影响。在研究领域, 麦肯锡认为, 数据已成为流入全球经济每一个领域的洪流。大数据完全能够成为企业的新型资产, 形成竞争力的重要基础, 并发挥重要的经济作用。IDC认为, 大数据处理将在2012年成为一项必备能力。Gartner认为, 2015年超过85%的财富500强企业将在大数据竞争中失去优势。2012年3月, 奥巴马政府发布了“大数据发展计划”, 并将其定义为“未来的新石油”。这一系列事件使得大数据成为又一个炙手可热的名词。

电信运营商引入大数据技术, 通过可控的成本实现海量数据存储分层的同时, 通过缩短数据处理路径和提供超大数据处理带宽, 有效减少数据分析响应时间, 提升信令分析的业务价值, 增强运营商核心竞争力。

2 大数据时代面临的挑战

2.1 大数据概念

(1) 数据规模大:很难给出一个绝对的数字标准来确定大小, 可能用一些模糊的感觉来相对比较;

(2) 数据结构复杂度高:复杂的数据结构的数据能够传递更丰富的信息;

(3) 数据关联度高:数据关联度的高低关系到数据的可挖掘程度, 如果数据关联度低, 无论数据量如何大, 结构如何复杂, 也形成不了大数据。

2.2 大数据时代面临的问题

(1) 简单的脚本语言预处理, 无法解析过于复杂的数据结构;

(2) 关系型数据库在大数据面前面临尴尬;

(3) 商业数据库的优化空间有限;

(4) 数据质量无法做到有效监控;

(5) 越来越多的业务需求向数据运算能力妥协。

3 基于云计算的大数据方案研究与设计

3.1 大数据统一分析平台设计思路

(1) 在企业内构建统一的数据运算平台;

(2) 企业所有者可以直接控制其数据实例;

(3) 通过实体整合直接提供企业级的数据访问功能;

(4) 灵活的扩展和配置降低了投资的平均风险。

云时代的大数据平台不仅以高性价比、高扩展性的硬件体系支撑PB级别, 甚至ZB级别的海量结构化、半结构化、甚至非结构化的数据存储。同时还需要能够高速的挖掘这些数据的价值, 为企业创造利润, 真正实现大数据等于大价值。

基于云计算的大数据统一分析平台结合数据库存储和Map Reduce架构为企业构建高效处理的结构化、半结构化、甚至非结构化数据的大数据分析平台, 客户可以以此平台为基础实现数据资产从成本中心到利润中心的转变, 以数据驱动业务。

3.2 大数据统一分析平台软件架构

(1) 软件架构

通过Master主机和多节点的Segment主机和数据库通过互联网络连接。应用程序通过Master主机访问数据, 网络中的每一个存储节点都是独立的数据库, 相互之间没有共享。在多存储节点和Master主机之间进行数据交换。

各个节点的segment服务器通过互联网络进行连接, 完成相同的任务, 从用户的角度来看是一个服务器系统。其基本特征是由segment服务器 (每个segment服务器为节点) 通过互联网络连接而成, 每个节点只访问自己的本地资源包括内存、存储等, 是一种完全的无共享结构 (share-nothing) , 因而扩展能力最好, 理论上期扩展无限制, 目前的技术可实现512个节点的互联, 数千个CPU。每个节点可运行自己的数据库、操作系统, 但是每个节点不能访问其他节点的内存, 节点之间的信息交互是通过节点互联网实现的, 这一过程称为数据重分配。

(2) 高可用性方案设计

Master主机与备Master主机采用一主一备方式同步进程, Master主机与多节点的Segment主机通过GE网络进行连接, 每一节点Segment主机上包含了主网段和镜像网段两份数据, 保障整个系统架构的高可用性。

3.3 大数据统一分析平台网络架构

(1) 目前的共享架构方案

“完全共享”体系局限于单一服务器 (通常是价格比较昂贵的SMP服务器) 。

“磁盘共享”体系允许系统带有多个服务器, 这些服务器与SAN或其它共享存储设备相连。这种体系需要通过一个狭窄的数据管道将所有I/O信息过滤到昂贵的共享磁盘子系统。

从结构上分析, 采用“完全共享”或“磁盘共享”体系, 其扩展性和性能受到相应的限制。而且, 通用磁盘共享体系复杂、脆弱, 在处理万亿字节数据时难以胜任。

(2) share-nothing完全不共享架构方案

完全不共享架构的磁盘SAN/FC网络、网络主机SAN/共享磁盘、通用数据库等是针对OLTP处理功能设计的, 在运行大量小规模交易查询数据时效果最好。

在“完全不共享”体系下, 在主机上规划查询项目, 并将其分成若干部分在集群上并行执行, 所有通讯功能都在一个高宽带网络互连体系上实现。这种体系的一个重要优势就是每个节点都有一个通往本地磁盘的独立高速通道, 从而简化了体系, 并提供扩展性很好的并行扫描和

查询处理功能。

3.4 大数据统一分析平台方案特点

(1) 数据保护-节点镜像

在大数据统一分析平台中, 只有Master主机保存了系统的元数据, 每一节点的Segment主机保存了用户的部分数据, 通过镜像, Segment主机的镜像数据保存在不同的Segment主机上。

比如:Segment主机1的主要数据版本1在Segment主机1, 它的镜像数据保存在Segment主机n;Segment主机2的主要数据版本2在Segment主机2, 它的镜像数据保存在Segment主机1;Segment主机n的主要版本数据在Segment主机n, 它的镜像数据保存在Segment主机2;

根据这样的镜像配置, 如果有Segment主机down机了, 仍旧可以从其他节点的Segment主机恢复完整的可用数据到本Segment主机数据库系统。

(2) 基于外部表的高速数据加载

①并行数据流引擎, 可以直接用SQL操作外部表;

②加载完全并行, 加载速度可达4.5TB/小时。

(3) Map Reduce&SQL一体环境

与传统的RDBMS系统和编程环境不同, 大数据分析平台采用Map Reduce&SQL一体化的环境。

(4) 私有云计算平台

硬件采用X86开放架构的PC服务器, 数据分布式存储和采用大规模并行计算, 从根本上解决I/O问题, 性能线性扩展, 高可用保障, 资源按需定制。

3.5 大数据统一分析平台优势分析

(1) 允许根据业务优先级按需调配和再分配大量计算资源的敏捷性;

(2) 能够分析更细化、更多元化的低延迟数据集 (大数据) , 同时保留数据内的细微区别和关系, 以便得出有利于优化业务绩效的差异化洞见点;

(3) 围绕关键业务计划展开组织范围的协作, 快速传播最佳做法和组织发现的结果;

(4) 成本优势:可以利用商品化处理组件来分析大数据, 从而利用以前即便能利用也不能经济高效的利用的业务机会。

基于云计算的大数据统一分析平台将带来可大幅扩展的处理容量, 允许利用细粒度数据集, 实现低延迟数据访问以及紧密的数据仓库和分析集成, 为公司和企业提供有实际内容并有可操作性的洞见点。

4 结束语

根据Gartner的预测, 2012年大数据技术处于高速的发展时期, 不断取得技术上的突破, 产品密集发布或者其他能产生重大利益的项目快速大量出现。基于云计算的大数据统一分析平台将有效地支撑数据关联度高、数据结构复杂的数据, 有效支持PB级别数据、有效减少数据分析响应时间, 提升信令分析的业务价值。基于云计算的大数据统一分析平台对电信运营商未来业务和技术的发展有重要的战略意义和经济意义。

摘要:通过介绍大数据时代的业务特点以及目前大数据时代面临的挑战, 对基于云计算的大数据统一分析平台进行了详尽的研究与设计, 包括大数据分析平台的架构体系、大数据分析平台的软件架构、大数据分析平台的网络架构、大数据统一分析平台的方案特点等, 分析了基于云计算的大数据统一分析平台方案的竞争优势, 基于云计算的大数据统一分析平台将更有效支撑未来电信运营商业务的发展。

关键词:云计算,大数据,Master主机,Segment服务器,完全无共享 (share-nothing) 架构,数据保护,并行计算框架 (Map,Reduce) 高可用性

参考文献

[1]陈如明.大数据时代的挑战、价值与应对策略[J].移动通信.2012, (17) :14~15

[2]赵春雷, 乔治.纳汉.“大数据”时代的计算机信息处理技术[J].世界科学.2012, (2) :30~31

[3]易鲜成, 朱红.用Delphi5开发多层应用系统处理大数据集的方法研究[J].计算机应用研究, 2001 (12) :126~128

[4]黎宏剑, 刘恒, 黄广文, 卜立.基于Hadoop的海量电信数据云计算平台研究[J].电信科学, 2012, (8) :80-83

[5]成静静.基于Hadoop的云计算/云存储方案研究与设计[J].数据通信, 2012 (5) :14-18

[6]顾芳, 刘旭锋, 左超.大数据背景下运营商移动互联网发展策略研究[J].邮电设计技术, 2012, (8) :21~24

[7]覃雄派, 王会举, 杜小勇, 王珊.大数据分析——RDBMS与MapReduce的竞争与共生[J].软件学报.2012, (1) :32-36

[8]郑启龙, 房明, 汪胜.基于MapReduce模型的并行科学计算[J].微电子学与计算机, 2009, (08) :13~17

[9]王桂强, 陆朝俊.基于并行技术的大数据量统计分析探讨[J].计算机应用如软件, 2011 (3) :162~165

[10]王珊, 王会举, 覃雄派, 周烜.架构大数据:挑战、现状与展望[J].计算机学报.2011, (10) :1741~1752

广东农信社 数据大统一 篇11

广东省农村信用社联合社(下简称农信社)就是如此。该农信社这两年着力构建四大统一平台,包括全省统一的数据平台、金融产品创新平台、风险防控平台和形象平台。项目计划用两年左右的时间,基本建成覆盖全省营业机构,实现数据集中存放、集中处理,面向客户、业务交易和管理的智能化综合业务网络系统。

大集中的技术基础

“经过近两年的系统建设,统一的数据平台项目基本处于收尾阶段。”广东省农村信用社联合社银信金融服务中心信息技术部副总经理韦旦说,统一的系统采用以省联社为中心,市、县联社为纽带,营业网点为前沿的全集中网络运作模式,目标是把省联社建设成为全省的交易处理中心、数据加工中心和资金清算中心。大集中系统将进一步整合全省农信系统现有的科技资源,改变过去农信IT系统旧有状况,为全省农信社各项业务功能的实施提供数据平台支撑。

广东省农村信用社联合社成立于2005年,是由广东省内的4家地市级农村信用合作联社(农村商业银行)和近100家县(市、区)级农村信用合作联社(农村信用合作社联合社、农村商业银行、农村合作银行)自愿入股组成,是具有独立企业法人资格的地方性金融机构。广东省农村合作金融机构共有各类营业机构网点5622家,从业人员5.9万人,是广东省内营业网点最多、服务面最广的金融机构。

“为了稳定运行,我们不少系统采用了IBM的产品。”广东省农村信用社联合社银信金融服务中心信息技术部副总经理苏汉槟说,农信社从服务器、操作系统、数据库、中间件、分析应用等层面采用了IBM的不同产品线产品,从而保障了数据的一致性。经过多年的运行证明,统一系统的稳定性极强。

举例说,IBM的Power Blade刀片服务器部署在农信社中心和各个地市的柜面应用服务器和前置系统,以及业务监控、安全平台、信贷系统、票影系统、联网核查、支付系统、报表系统和开发测试培训等平台。利用IBM Power blade刀片服务器高密度、简洁、扩展方便、快速部署、统一管理等优点,结合IBM的System Director和VM control虚拟化管理软件,不但可以快速部署省中心和各个地市的上线工作,还节省了昂贵的机房空间、能源和冷却成本、IT管理成本。

提高服务能力

过去,广东省农信社计算机中心分散,只以市县为中心,没有全省统一集中;各联社综合业务系统版本众多,难以兼容;重复建设严重,效益不高;各中心系统功能、业务应用水平参差不齐。

此次广东农信社数据大集中项目是迄今为止全国最大的农村信用社数据大集中项目,其挑战性在于:从内部来说,广东省农村信用社是省内营业网点最多、服务面最广的金融机构,拥有99家联社(农村商业银行),近6000个营业机构。从外部用户需求角度看,广东省是全国经济最活跃的省份之一,广大农户和落户乡镇的中小企业更需要灵活和创新的金融服务,以支持当地的生产生活和经济发展。

“现在还剩下一些区域没有完成项目大集中。等项目结束之后,广东农村信用社将真正实现全省农村信用社数据大集中,全面提升我省农村信用社的核心竞争力。”韦旦说,广东省农村信用社数据大集中带来的最直接好处是通过整合客户数据,并标准化记录所有渠道与客户的交互,从而实现以客户为中心,并且基于客户分级(如黄金客户、高贡献度客户)制订不同类型的客户服务及响应要求,以便在全辖范围内能为客户提供个性化的、统一的服务体验。

统一数据平台 篇12

目前电力系统中的故障录波器在应用中还存在着很多不足之处[3,4]。故障录波器的生产厂家多,型号多样,有时候即便用的是同一个生产厂家的产品,也由于其生产年份和型号不同,导致了录波数据格式和通信协议不统一的状况,这给事故后的故障分析和故障过程模拟再现带来了极大不便;各录波器传输方式和协议的不同,给利用网络方式实现故障录波器统一管理造成不便。另外,数据结构、软件接口的不统一,使得故障录波器厂家每出一种新的产品,就需要提供一套新的后台分析软件,这在造成重复工作的同时,也大大减弱了对故障录波器进行联合管理的实用性和有效性。

针对上述现象,在对当前大量故障录波装置进行广泛深入研究的基础上,针对目前管理软件上的不足,开发了故障录波数据统一管理分析平台,将数据文件转换为标准COMTRADE数据格式,在客户端实现对全网故障录波器远程录波、实时监测、文件传输、故障分析、谐波分析等功能。

1 平台架构

1.1 平台的模式结构

目前国内多数录波数据管理系统采用单机版的模式,这在一定程度上给管理带来不便。本文设计的故障录波统一管理分析平台采用客户端/服务器(C/S)的结构模式,在客户端能够实现更方便的管理。平台的C/S模式结构如图1所示。

平台C/S模式结构主要由客户端主机、通信服务器、数据库服务器和录波器终端构成。通信服务器实现与录波装置的通信,信息和数据存储在数据库服务器中,和服务器连接的其他主机为客户端。客户端主机通过与通信服务器和数据库服务器通信来实现对全网故障录波装置和文件的各种管理分析功能。

1.2 平台的整体架构

统一管理分析平台按照C/S模式,其具体的模块化结构如图2所示。

由图2中可以看出,通信服务器主要包括通信模块、文件解析模块和文件转换模块;数据库服务器则负责数据接收、解析及后续处理;客户端主机根据需要来与服务器间通信,实现波形再现、故障分析、谐波分析、报表打印等功能。

2 功能组件

管理分析平台采用模块化设计,由多个模块之间协调合作来满足所有的功能需求,具有良好的扩展性和可移植性,并且大大降低了程序内部的耦合性。平台各功能组件的基本功能如下。

2.1 客户端管理系统

采用MFC编写的软件用户界面主要由录波器窗口、结果显示窗口和状态显示窗口组成。管理人员首先在主界面的目录树中选择一台故障录波器,然后可以进行状态查询、参数设置、录波文件检索等。检索的结果可以直接在结果显示窗口中以列表的形式显示出来,并且用不同的图标来表示文件是在本地硬盘或是在远处主机上。在检索结果中选择文件,可以进一步执行波形再现功能,进行故障分析、谐波分析、功率与频率分析等。分析结果会在弹出的新界面上显示。不同线路的波形以红、黄、蓝3种颜色交替显示,既美观又容易识别。状态显示窗口用来实时显示各个故障录波器的工作状态、管理人员操作日志等,并可以形成文件保存到硬盘上。平台中的各种故障分析模块都可以用来供客户端管理系统随时调用。

2.2 通信和文件转换模块

考虑到目前实际应用中的故障录波器所支持的通信方式有串口、拨号和网络通信3种,而本系统旨在实现在客户终端对各个录波器进行统一的管理分析,那么,就需要平台的通信模块能够满足各种型号故障录波器的需要,对每种通信方式都制定一套数据传输的通信规约。在实际应用时,平台根据录波器通信方式的选择来灵活调用,建立连接并根据命令类型进行文件传输、远程校时、远程录波、实时监测等功能。

为了能够对各种型号录波器的录波数据文件进行统一的分析,使得录波器管理工作更加便利快捷,平台采用IEEE于1999年修订的标准COMTRADE数据格式。平台通过通信模块接收到文件之后,立即根据该故障录波器的型号选择相应的文件解析模块进行文件解析,然后再按照COMTRADE数据格式的要求实现数据文件的格式转换。

2.3 数据管理模块

平台管理如此多的故障录波器会涉及大量的数据,如何对这些数据进行合理的管理,也是直接关系到整个平台的有效性和工作效率。数据管理模块主要实现对各个故障录波器运行信息、参数文件和录波文件的存储、读取、添加、删除等功能。

为了保证在进行数据分析时所参考的录波器的参数文件是相符合的,每次在进行数据文件传输时,都要传送一次最新的参数文件。数据管理模块将转换后的数据文件按照地区、变电站、录波器的三级文件夹顺序有序存放,为每台录波器建立一个以该录波器名称命名的文件夹,然后再根据其不同批次的录波文件建立新的文件夹,里面除了存放转换后的数据文件,还有一起接收到的该录波器的参数文件。另外,每个录波器的其他相关信息(比如其IP地址,是否上传,连接状态,工作日志等)对整个平台的管理工作来说是相当重要的,且实时性要求较高。为管理好这部分信息,又建立了Access数据库来进行管理,包括操作日志和录波器的工作状态,根据录波器运行状况实时更新。

3 关键技术

为了建立统一管理分析平台,对全网故障录波器进行有效管理,该平台采用的关键技术主要有统一数据结构的建立、数据的统一管理和统一分析等。

3.1 统一数据结构的建立

考虑到该平台所管理的故障录波器数目多,而每个故障录波器中涉及的数据量都非常大,因此,构建一个较好的数据结构模式是关系到整个系统开发质量的关键。

统观整个平台的功能,其中涉及大量数据处理的操作主要分为2类:(1)故障录波器参数文件的解析和参数设置;(2)对录波数据文件的操作,包括故障分析、波形再现、谐波分析等。每种型号录波器参数不同,可根据型号分别制定一套数据结构。由于录波数据文件已经是转换为标准COMTRADE格式后的数据文件,所以各个型号故障录波器的数据文件可以用统一的分析模块来分析。这样,再制定一套统一的数据结构,用来与统一分析模块相对应。图3为平台的数据结构图。

每台故障录波器都对应有2套数据结构,一套是该型号录波器特有的数据结构(简称小结构),另一套是统一数据结构(即包含所有型号录波器特征的数据结构,简称大结构)。录波器参数文件解析后直接与其小结构相对应,同时,小结构还与录波器参数设置对话框对应。而大结构对应于平台中统一的波形再现、波形分析、故障分析等模块。大小结构之间可以实现互相赋值。这样整个平台的数据分2个层面,只要做好中间的传值工作,就能够更方便地实现平台的开发。

3.2 数据的统一管理

将各种型号录波器的数据文件格式统一起来,才能够更好地利用统一分析模块,实现数据的统一管理[5,6,7]。

平台采用的COMTRADE标准数据格式[8]中共有4类文件:头文件、配置文件、数据文件和信息文件。考虑到实际应用的需要,本平台省略了头文件和信息文件,将同一批次的录波数据文件转换为配置文件(.CFG)和数据文件(.DAT),且根据不同的批次和录波时间定义新的文件名称,存放在该录波器的同一批次文件夹内。

在数据转换中,需要根据数据文件内容定义新的数据结构,便于信息的转换(适用于所有型号录波器)。在配置文件中,为模拟量和数据量采集通道信息分别定义一个结构体:模拟量采集通道结构体str_AnaInfo中包含有模拟量通道序号、通道名称、相别、单位、放大倍数、偏移量、最大最小值等信息;开关量采集通道结构体str_DigInfo中包含有开关量通道序号、通道名称、相别、对应的电网设备名称等信息。另外再为数据文件定义一个数组,用来表示采样点序号、时间和采样数据。这样,录波文件经解析后直接实现统一格式的转换。

3.2 数据的统一分析

数据的统一分析是平台中比较重要的一部分,能直观地反映出整个平台功能实现的效果如何。由于此前已经对数据文件进行了标准格式的转换,就可以用统一的数据接口函数实现。

平台中用到了电力系统中的多种算法,又利用了MFC中所封装的大量绘图类的函数,来设计一个友好的图形用户界面(GUI)。

各分析功能的结果有独立的界面显示,可以很直观地看到故障发生时各通道的波形。各波形以多种颜色来区分表示,还可以进行有选择的放大、缩小等操作。

通过数据分析可以实现波形再现、故障分析、谐波矢量分析、功率与频率分析、阻抗圆图分析、阻抗轨迹、报表生成和打印等功能。

4 结束语

随着电力系统自动化水平日益提高,对调度端的管理水平也是一个很大的挑战。本文研究的数据统一管理分析平台可和多种型号故障录波器进行通信,较好地实现对多台录波器在线监测、录波文件传输、维护管理、录波文件、参数文件格式转换,以及录波文件的分析、打印等功能。平台采用模块化设计,不仅利于开发的实现,更使得日后的升级和维护都变得极为便利。

在数字化变电站迅速发展的今天,采用模块化设计和开放的程序接口,为以后向IEC 61850标准的衔接做了很好的铺垫。

本文设计的统一管理分析平台包含了国内某公司生产的各种型号故障录波器的通信规约、参数文件格式和录波数据文件格式。如果要向平台中添加新型号的故障录波器,只需要在该平台中添加与新录波器参数文件、数据文件相配套的文件解析和COMTRADE格式转换函数即可。目前,该平台已经在江浙一带的部分电力调度中心使用,并且运行状况良好。

参考文献

[1]周玉兰,许勇,王俊永,等.2000年全国电力系统继电保护与安全自动装置运行情况[J].电网技术,2001,25(8):63-66,75.

[2]任建文,周明,李庚银.电网故障信息综合分析及管理系统的研究[J].电网技术,2002,26(4):38-41.

[3]李媛,刘涤尘,杜新伟,等.电力故障波形再现及分析系统的开发[J].电网技术,2006,30(5):106-110.

[4]陈长德,张保会,魏春轩.故障录波数据集中分析与专家系统[J].中国电力,1999,32(9):40-43.

[5]郑敏,黄华林,吕鹏,等.故障录波数据通用分析与管理软件的设计[J].电网技术,2001,25(2):75-77.

[6]杜新伟,李媛,刘涤尘.电力故障录波数据综合处理系统[J].电力系统自动化,2006,30(12):75-78.

[7]张杰,涂东明,张克元.基于COMTRADE标准的故障录波的分析与再现[J].继电器,2000,28(11):20-22.

上一篇:管道敷设设计下一篇:开发及影响