Web调度系统（共6篇）
Web调度系统 篇1
0 引言
计算机网络为电网调度自动化系统提供了方便快捷的手段,同时也是当前电网调度自动化的发展方向。为了确保电网运行的安全和稳定,电力部门需要及时了解电网的运行状况,掌握当前电力负荷分布,发现潜在的安全隐患,加快故障信息的获取和分析。目前,电力调度部门需要一种通过办公网络就能直接监测电网运行状况的系统,但同时该系统必须不能影响到电力系统的安全性。以Web浏览方式获取电网运行数据,通过浏览器直接呈现厂站等画面的运行状况,这样的方案比较好地满足了快捷性和安全性两大要求[1]。由此,一种将传统工作站环境下运行的调度自动化系统移植到Web环境的方案应运而生。
在结合广东备调Web子系统的设计开发基础上,本文概述了一个Web电网调度自动化系统的设计方案,介绍了实现时采用的主要技术,重点论述了实践过程中遇到的有关SVG性能的优化、用户交互的处理和动画效果的实现等关键问题,并给出了解决方案。
1 调度系统Web化的必要性
能量管理系统(EMS)在电网调度自动化方面发挥了重要作用。调度员登录实时控制区(即安全区Ⅰ)的工作站就能全面了解电网的运行情况。为确保安全性,Ⅰ区与办公网所处的生产管理区(即安全区Ⅲ)之间设置了隔离装置。这样做一方面保证了Ⅰ区不会遭受来自外部环境的非法侵入,另一方面也极大地限制了办公网用户及时掌握电网运行信息。另外,即使一般用户能够访问Ⅰ区,由于EMS系统功能过于复杂,操作时难免存在误操作,影响电网的正常运行。除此之外,虽然EMS系统能够在多种操作系统平台上运行,但是为办公网内多台机器部署EMS系统的工作量比较大,实践中不可行。
由于EMS系统存在上述固有问题,因此本文提出了一种基于B/S架构的设计方案,借助目前比较成熟的可缩放矢量图形[2](Scalable Vector Graphics,SVG)和AJAX[3](Asynchronous Java Script and XML)技术,实现了一个画面呈现与EMS系统保持一致、通过浏览器即可访问、无需开放额外网络端口的Web子系统,从而将EMS系统中的画面浏览、离线潮流计算等功能移植到Web环境。
Web调度子系统是对原有EMS系统的一个有力补充,并非完全替代原有系统。针对当前电力系统办公环境的多元化,实现电网调度自动化系统的Web化是必要的。
2 系统设计
Web电网调度自动化系统采用B/S架构,避免在客户端安装额外的软件。用户通过浏览器即可访问厂站图、曲线图和潮流图等画面。浏览器中所呈现的画面效果与EMS系统中保持一致。系统的基本架构设计如图1。
系统由两部分组成:Web客户端和Web服务端。客户端只能通过服务器提供的Web页面和服务端口访问Web服务,其余有可能威胁到系统安全的网络端口一律不向外开放,杜绝了系统安全隐患,但这也使传统的Java Applet[4]和Active X[5]方式不能适应这种应用前提。
Web客户端采用SVG/AJAX方式,SVG负责画面渲染,AJAX负责数据更新、画面刷新和交互事件处理。借助AJAX技术,客户端发送HTTP请求即可访问Web服务器所提供的服务。根据服务器反馈的XML格式数据,客户端就能实现数据更新和SVG画面的渲染。
Web服务器采用多进程方式为客户端提供一对一的服务,这样实现的优点是:某一服务进程出现异常不会影响其他用户的正常访问。图1中虚线框表示服务进程管理器,它负责服务进程的启动和终止。服务进程正常启动后加载画面,在客户端的驱动下定时刷新画面,并将画面上产生更新的设备或前景状态反馈给客户端。
3 主要技术
本文的设计方案采用了SVG+AJAX技术,充分发挥了浏览器的优势,在保证系统安全的前提下,为使用者提供与EMS一致的用户体验。
3.1 SVG
可缩放矢量图形(Scalable Vector Graphics,SVG)是基于可扩展标记语言(Extensible Markup Language,XML),用于描述二维矢量图形的一种图形格式。SVG是由W3C制定的开放标准。在过去几年里,已经有很多研究者致力于将SVG用于EMS/SCADA系统间的系统图和一次接线图的图形交互,以及EMS/SCADA系统与GIS系统等其它应用系统的图形交互。Web子系统在设计之初参考了CIM-SVG图形交换格式[6],分析了该格式与现有图形监控系统的不完全匹配性,结合项目的实际需求,对生成SVG画面的方案进行了重新设计。新方案着重考虑了以下几个因素:
a)Web子系统需要一个能够呈现厂站运行状况的画面,而不是图形和数据的交换中介。换句话说,服务程序所导出的SVG画面仅用于Web画面的实时显示和交互,而非用于与其它系统的数据交换。因此,相对冗余的电力系统方面的信息并没有导出到SVG中。
b)CIM-SVG格式定义中大量使用了
c)虽然CIM-SVG交换格式定义了一套电力系统中的相关图元,但是现有EMS系统中有很多图元却不是电力系统所特有的(比如二维表、Tab页、柱状图等),并且CIM-SVG中也没有定义。因此完全采用CIM-SVG格式进行实现是不完备的。
鉴于以上因素,结合现有EMS系统在图形表示上的特点,本文给出以下几点在设计实现中遵循的方向。
a)画面中任意一个图元,大到复杂控件、变压器图元和开关图元,小到线段、矩形和圆,都有呈现自己的接口实现。每一个图元都拥有唯一标识ID。
b)图元的位置、旋转和缩放参数以包含该图元的父图元所建立的坐标系为参照。
c)图元在导出成SVG节点时只导出当前的显示样式,而不需要导出所有状态下的样式。例如:开关有分合状态,如果当前开关为分状态,那么只导出分状态下的样式。
d)对于电力设备图元,需要能够提供自身实时运行参数用于实现用户交互和离线潮流计算等功能。
e)导出图元要考虑浏览器渲染的效率,尽量简化导出方案,在保证显示效果可以接受的情况下减少复杂效果(如渐变、裁减等)的使用。
3.2 AJAX
AJAX已经成为Web富客户端应用的首选技术(其它技术如Java Applet、Active X等)。传统Web应用在发生数据更新时页面需要完全重刷,而AJAX的出现从根本上改变了Web应用模式。AJAX只向Web服务器发送并获取必需的数据。它使用SOAP或其它基于XML的服务接口,并在客户端采用Java Script处理来自服务器的反馈。由于服务器和浏览器之间交换的数据大量减少(大约只有原来的5%),从而Web端的反应时间大大缩短,并且很多处理工作都可以在浏览器中完成。通过AJAX技术,用户在查看画面时无需强制画面全部重刷。浏览器中的JS脚本会定期向Web服务器发送HTTP请求,获取画面上的更新数据,并在客户端做增量更新,这样得到的用户体验与现有的EMS系统基本保持一致。采用AJAX技术对于传统的Java Applet和Active X方式有如下一些优点:
a)无需建立额外的Socket连接。HTTP请求通过Web服务端口(如80或8080)即可获得更新数据,服务器无需开放其它端口,在一定程度上保证了服务器的安全性。客户端也不需要做额外的端口设置。
b)HTTP请求是异步的,数据刷新在后台运行,减少了对用户操作的干扰。用户可以在客户端修改刷新周期,从而调整浏览器的资源占用率。
c)Java Script在处理SVG的加载、更新和用户交互方面拥有与生俱来的优势。SVG技术本身基于XML标准,因此在更新画面时比较方便快捷,避免了节点和属性的映射、转换等操作。
4 关键问题及解决方案
Web子系统在实现过程中碰到了许多问题,其中有三个属于比较关键的问题。本文就这三个关键问题在项目中的实现进行了深入的分析和研究,并给出了相对简洁的解决方案。
4.1 SVG性能
虽然SVG技术在图形的显示效果,尤其是图形在经过放大之后的效果要明显优于传统的图像技术,但是目前它在应用中普遍存在性能上的问题。造成该问题的原因主要有三个方面:1)XML解析和SVG渲染的速度;2)画面规模;3)数据刷新和画面渲染频率。
采用SVG技术展示的画面在浏览器上呈现要经过XML解析和SVG渲染两个过程。由于解析XML需要依赖浏览器的Java Script实现。Java Script实现效率越高、运行速度越快,XML解析速度也就越快。目前几大浏览器阵营正日趋重视对Java Script的支持,并大幅度革新脚本引擎的实现,所以尽量使用最新版本的浏览器(如IE8、Firefox3等)可以获得比较大的性能提升。IE本身不支持SVG的渲染,在IE环境下渲染SVG需要Adobe公司的SVG Viewer组件。在项目的实践过程中我们发现Adobe SVG Viewer在渲染中小规模(SVG文件大小<600KB左右)的SVG画面时比较顺畅。如果画面的SVG文件进一步增大,那么在浏览器中的渲染和以后的用户交互将变得异常困难。
虽然在实现过程中我们极力避免生成过大的SVG文件,也想尽办法减少SVG文件中DOM节点的数量,但是画面规模却是一个无法躲避的障碍。在电网调度自动化系统中,各种规模的画面都存在,小到一张普通的画面索引图,大到系统潮流图。SVG技术在呈现中小规模的画面时绰绰有余,但在渲染大规模的画面(如潮流图等)时往往显得力不从心。一张500 k V的厂站图中包含数值量约为150个,刀闸约为200个。但是,一张系统潮流图上包含的数值量却有约1 500个,联络线约700个。如此大规模的画面渲染和更新会直接导致浏览器的僵死,用户基本无法操作。如何在性能和效果之间取得一个平衡点成为实现该Web子系统所面临的重要问题。本系统设计了两套SVG更新方案:整体更新和局部更新。中小规模的画面采用整体更新,而大规模的画面则采用(整体+局部)更新。整体更新不对图元做取舍,所有图元在打开画面时做全面刷新和渲染,后续过程只做增量刷新和渲染;局部更新会选取画面中跨度范围小、数量众多并且更新频繁的图元(比如数值前景)作为目标,并仅在用户观察区域内做刷新和渲染。潮流图上数值前景和状态前景数量众多,更新频繁;联络线跨度范围较大,更新不频繁,数量可以承受。因此,Web子系统采用了局部渲染数值前景和状态前景的策略。经过这样处理,潮流图的渲染性能和用户操作性已基本可以接受。
电网数据是实时更新的。若要在Web上看到最新数据,周期性刷新数据是必要的。但是,如果刷新周期过长,更新就不会很及时;如果刷新周期过短,浏览器的CPU占用率又会很高,服务器的压力也会很大。Web子系统在客户端提供了可调节的刷新周期,满足用户的不同需求。默认情况下,刷新周期在性能和效果上做了折中。
4.2 用户交互
SVG标准支持用户交互特性。原有EMS系统在用户交互方面主要表现为鼠标的左击和右击。为了与现有系统保持操作上的一致性,Web端对鼠标事件进行分别处理。左击主要触发复杂控件的状态变化,如二维表树形结构的展开与恢复,光敏点的切换画面,Tab页的切换等;右击则需要根据点击的对象动态生成操作菜单项,并且菜单项都对应各自的事件处理函数。通过对原有EMS系统的分析研究,从中提取生成操作菜单的逻辑,并根据动态获取的设备对象参数,在Web子系统的画面上呈现经过过滤后得到的操作菜单。
SVG渲染控件ASV具有特殊的右键菜单配置方式,配置菜单通过一个XML文件实现。该文件基本格式如下。
通过将默认的右键菜单配置文件动态替换成根据设备对象的运行时参数过滤得到XML文件,即可动态生成对应的操作菜单。用户在点击菜单项后,将会触发func事件处理函数,根据输入参数param_list执行已定义的处理逻辑,从而实现用户交互。
4.3 离线潮流计算的动态分配
Web系统提供在浏览器画面中执行离线潮流计算功能。但是由于受到三区Web服务器数量、系统配置的离线潮流应用数目的限制,以及考虑到系统维护和用户访问的方便性,离线潮流计算需要能够实现动态分配。本系统实现该功能的基本流程如下:
a)用户通过公共虚拟IP访问Web系统的登录页面,激活离线潮流计算功能并成功登录。
b)Web服务器根据用户登录情况、服务器的离线潮流配置情况和离线潮流的分配情况决定是否需要进行服务迁移。
c)如果该Web服务器未配置离线潮流,则将用户请求直接迁移到另外一台配置了离线潮流的Web服务器。
d)如果该用户已在该服务器上登录了离线潮流计算,则该服务器继续为用户提供服务;如果用户在其它服务器上登录了离线潮流,则迁移到目标服务器。
e)如果该Web服务器虽配置了离线潮流,但均已被其他用户占用,则迁移到尚有离线潮流应用空余的Web服务器。
f)如果该Web服务器配置了离线潮流,并且仍有应用空余,则将随机分配一个给该用户。
g)如果经过动态分配的调整之后,用户仍然没有分配到离线潮流应用,则跳转到登录页面,并提示用户离线潮流应用已无空余可用。
通过离线潮流的动态分配,Web系统在为用户提供服务时就无需设置用户与具体应用的绑定,免除了后期由于人员变动而引起的额外维护工作,同时也减少了服务器配置过多应用而导致不必要的负荷。
5 系统运行展示
目前,本文所介绍的Web调度系统已经完成编码实现,并在广东备调项目中投入运行。图2和图3分别为系统运行截图。
6 总结
本文介绍了一个基于SVG/AJAX技术实现的Web电网调度系统,提出了系统的整体架构,分析了核心技术的优点和如何合理使用这些技术,着重讲述了在实际开发过程中遇到的三个关键性问题,并为这三个问题给出了相对简便的解决方案。目前该系统已经在广东备调项目中投入运行。由于SVG标准的开放性以及Web应用的日渐流行,相信在以后的电网调度系统中SVG/AJAX技术能够发挥更大的作用。
摘要：介绍了一个Web电网调度系统的设计和实现,对实践中存在的若干关键问题进行了深入研究,并且针对这些问题给出了相应的解决方案。描述了Web系统的架构设计,概述了系统实现中采用的关键技术(SVG和AJAX)。针对技术的特性和画面的特征,剖析了如何更加合理和有效地使用这些技术,指出了实现中应该遵循的方向。重点对Web系统在画面渲染和数据刷新时存在的性能问题、如何实现用户交互性和如何动态分配离线潮流计算这三个关键问题进行了研究。实践表明,基于上述研究和给出的解决方案,对改善Web调度系统的使用性和用户友好性都有明显的效果。
关键词：Web调度系统,SVG优化,AJAX,SVG用户交互,动态分配
参考文献
[1]李友军,徐广辉,王文龙,等.Web Service和MMS技术在IEC61850标准体系中的应用分析[J].电力系统保护与控制,2009,37(14):101-104.LI You-jun,XU Guang-hui,WANG Wen-long,et al.Comparison between the application of web service and MMS in IEC61850[J].Power System Protection and Control,2009,37(14):101-104.
[2]石东源,卢炎生,王星华,等.SVG及其在电力系统软件图形化中的应用初探[J].继电器,2004,32(16):37-40.SHI Dong-yuan,LU Yan-sheng,WANG Xing-hua,et al.Study of the application of SVG in power system graphicalized software[J].Power System Protection and Control,2004,32(16):37-40.
[3]游丽贞,郭宇春,李纯喜.Ajax引擎的原理和应用[J].微计算机信息,2006,22(6):205-207.YOU Li-zhen,GUO Yu-chun,LI Chun-xi.The principle and application of Ajax engine[J].Control&Automation,2006,22(6):205-207.
[4]李捷,杨志宏.Web技术在EMS系统中的应用[J].中国电力,2000,33(3):60-63.LI Jie,YANG Zhi-hong.Application of world wide web in energy management system[J].Electric Power,2000,33(3):60-63.
[5]杨飞虎,丁明,李生虎.基于B/S结构和ActiveX技术的电力系统可靠性信息发布[J].电力系统保护与控制,2006,34(6):57-59,74.YANG Fei-hu,DING Ming,LI Sheng-hu.Information publicizing of reliability of power system based on B/S mode and ActiveX technique[J].Power System Protection and Control,2006,34(6):57-59,74.
[6]董朝霞,戴琦,杨峰.基于CIM和SVG的电网建模技术[J].电力系统及其自动化学报,2006,18(5):58-61.DONG Zhao-xia,DAI Qi,YANG Feng.Power network modeling method based on CIM and SVG[J].Proceedings of the Electric Power System and Automation,2006,18(5):58-61.
Web调度系统 篇2
随着国家电网大运行体系的发展,电网调度现有的运行模式、管理模式和业务流程将会发生一系列的变化,面对这种变化的需求,用户对基于Web的调度日报系统提出了日益严格的要求。在传统的调度日报系统中,页面只支持数据的简单查询与汇总功能,不具备复杂环境下的动态计算能力。同时,大运行体系的构建也必然会带来一体化运作,面对能量管理系统(EMS)、电能量计量系统(TMR)、广域测量系统(WAMS)、水调自动化系统、调度运行管理系统(OMS)等诸多系统[1],虽然可以通过Web服务或数据交换等方式实现数据共享,但是如何解决多个应用系统的协同计算是一个迫切的问题。
面对这种以协同为目标的动态计算问题,特别是对电力企业系统之间的集成计算需求,传统的解决办法以面向服务的计算(SOC)为主,它是以标准化为支持的系统,倡导以服务及其组合为基础,可以看出这种计算模式需要按照固有的标准来实现,必然对遗留系统带来新的不确定性[2]。因此,如何构造一个轻量级的Web计算框架,并解决与用户的交互也是一个迫切的问题。
针对Web页面交互的需求,最有效的解决方案是利用成熟的具有异步传输特征的Ajax框架,但是当前大多数Ajax框架不具备多事件的动态调用,尤其是调度日报系统可能根据业务变化来调整计算时序或者流程的逻辑控制,这种动态维护也会给应用系统带来极大的不稳定性。本文设计的调度日报系统,在结合Ajax引擎和工作流引擎的基础上,解决了复杂环境下的Web计算问题。
1 系统主要功能与设计
OMS作为调度管理的基础系统,其功能涉及调度运行、调度计划、运行方式、继电保护、自动化等专业,同时要求具备网省数据考核的功能。作为OMS的基础模块之一,调度日报系统目前主要包含以下功能。
1)E文件解析[3]。
根据《电力系统数据标记语言——E语言规范》和电力系统二次安全防护要求,网省调度中心与国家电网调度中心在OMS互联系统上通过E文件实现数据交换,E文件解析模块实现根据配置条件自动解析E文件,记录E文件解析结果、解析错误原因和上报延迟等相关日志。除此之外,通过电力二次系统安全Ⅱ/Ⅲ区数据交换平台,调度日报系统利用E文件从EMS或TMR提取数据。
2)数据计算与考核。
除了网省上报文件的解析,调度日报系统还需对燃料日报数据、重点水电厂水情数据、网省上报数据和直调数据进行提取,最后系统对数据进行汇总。为提高网省上报数据的准确性,系统实现报送考核、数据考核、逻辑校核等多种考核方式。数据考核是对上报文件的空数据、零数据情况进行考核;逻辑校核主要是网内校核、网省校核和周期校核。网内校核是以网调数据与归属省调上报汇总数据为对比对象;网省校核是网省电量相关属性值与子属性值的比较,例如调度机端电量与调度火电机端电量、调度水电机端电量、调度核电机端电量等的比较。
3)报表生成。
调度日报系统以PI3000平台[4]报表服务为基础,根据用户提供的模板配置各种形式的调度日报报表,这些相关报表大多以快照形式展现给用户,这样既可以提高速度,而且在系统异常的情况下,能够正常展示调度日报的历史报表。除此之外,系统还提供应急报表机制,使得数据异常情况下可以正常制作调度日报。
4)异常处理。
调度日报系统进一步引入异常处理机制,使得在计算过程出现异常时,系统能够根据异常处理的相关配置决定下一步操作,同时分析服务端返回的数据包,并在用户界面上实时显示相关信息。此外,系统还可以根据匹配异常信息以及人工维护等方法,提供异常处理的有效方案,提高用户的工作效率。
根据上述功能要求,调度日报系统以Web计算框架为服务总线,实现计算模块的动态调用。调度日报系统的架构如图1所示。
应用系统的3层架构模式将原有系统中的业务功能封装成可复用、互操作的服务,并利用服务组合及业务流程建模等技术构建新的应用模块,从而使集成后的应用架构可以快速适应业务的变更以满足新业务开展的信息化需求。
2Web计算框架的设计与实现
为增强Web计算框架中各功能模块的可扩展性和复用性,降低模块间的耦合程度,系统提出了一种基于模型-视图-控制器(MVC)架构的设计方案。这种结构化模型可以清晰地分离用户界面与业务逻辑,提高框架的性能、可维护性以及构件重用性。
MVC架构的核心思想是将程序分成相对独立而又能协同工作的3个部分:模型、视图、控制器[5],采用分治的思想将表示和数据相互分离。在Web计算框架中:与工作流对应的计算容器扮演模型的角色;基于Ajax引擎的计算链处理框架扮演控制器的角色;对于视图,系统可以采用Adobe Flash,XML/XSL和XHTML等多种表现形式。模型、视图和控制器的独立性使得系统一部分的改变不会影响其他部分,从而构造出良好的松耦合系统。可见,一个模型可以对应一个或多个视图;控制器是模型与视图的联系纽带,用于解释用户的操作意图,并把它交给模型去执行。基于MVC的Web计算框架的系统结构如图2所示。
2.1 基于工作流的Web计算框架
本文设计的Web计算框架采用计算元的概念,计算元是对电力信息系统中已存在的业务逻辑组件的一种抽象,存储了计算路径、角色权限等相关信息。计算元与工作流活动模板绑定实现计算的动态配置,工作流引擎依据电力数据流程和业务逻辑进行任务调度,实现计算过程的自动执行。用户可以根据实际需求抽象出各种计算元,并把计算元注册到系统数据库中,最后通过工作流平台来配置计算参与者、执行顺序和路径,将计算流程的逻辑计算机化,最终实现复杂的Web计算[6]。
在工作流引擎中,对于每一个活动模板绑定一个计算元,如果计算元的注册信息包含了角色信息,这就要求计算的启动对象必须满足这种角色权限,否则,当计算流程执行到当前活动模块,计算模块将自动跳过当前计算元的执行。在有些情况下,计算元之间并非是独立的,而是具有关联的数据信息,在Web计算框架中,这种关联信息是通过Ajax引擎返回的JSON(JavaScript object notation,一种轻量级的数据交换格式)对象进行传递的,从而实现计算元之间的交互功能。由于基于工作流的Web计算框架具有灵活配置的优点,当业务逻辑发生变化时,只要求更改相应的活动模板关联的计算元,从而提高了系统的灵活性,能够适应电力数据统计分析需求的频繁变化。
图3所示为调度日报业务流程片段与Web计算框架之间的处理模型,业务逻辑与计算容器存在着一一对应关系,其中通过安全Ⅱ区数据平台,④的数据从TMR系统获取,⑤的数据从EMS获取。
从图3可以看出,计算代理对象以时序为标准,依次注册计算对象①→(②③)→④→⑤,即②和③同时注册到计算容器中,代表①→②和①→③是一种并行调用,②和③都执行完成后,到④,⑤转换为串行调用。根据处理模型中的计算容器,基于时序逻辑的计算链处理框架能够实现串行或并行调用。
2.2 基于时序逻辑的计算链处理框架
目前大多数Ajax框架只限于对单一事件模式的支持,即请求/应答的回调模式,这种模式显然不能满足复杂环境下的多事件响应需求,甚至在一些特殊情况下,Web应用程序的复杂计算存在着逻辑顺序的问题,这就需要实现基于时序逻辑的计算链处理框架。
一般来说,复杂事件处理要解决的关键问题就是如何对简单事件进行处理和通知给最终用户,可以说,事件模型和订阅模型作为一个整体,共同决定了事件处理的表达能力[7,8]。通常事件调用模式采用基于调用的请求/应答方式或基于事件的发布/订阅方式,其中:前者客户端发起对服务端单对单的调用;后者多个客户端可以注册到同一个服务端,这就提供了一对多的调用机制,并且当事件的触发条件得到满足时,服务端能够自动发起对客户端的回调[9]。将这种支持了自发的、多对多的事件驱动架构整合到Ajax的回调机制中,这种模式对于在现有Ajax框架的基础上实现基于时序逻辑的计算链处理提供了架构性的解决方案,系统框架的订阅/发布结构如图4所示。
本文的事件模型是以计算容器为基础,根据前文所述,计算容器是以计算链为基础的队列结构,当计算元注册到计算容器中的同时,也作为一个事件的订阅者存在。用户在执行Web计算过程时,实时检测计算容器中是否存在订阅者,当订阅者进入计算队列,系统自动触发Ajax调用机制,实现了基于时序的计算功能,在多个订阅者同时进入计算容器的情况下,系统判断当前计算处于并行状态,自动多次触发Ajax调用,实现了一对多的事件触发机制。事件可以作为通信消息的语义载体,其所携带的信息能够用来进行智能化处理。正如前文所述,Ajax引擎返回的JSON对象作为事件的参数在计算元之间进行传递,根据JSON对象判断是否满足目标计算元的前提条件从而决定计算元的执行状态,这种逻辑上的智能判断扩展了Web计算框架的功能。
2.3Web计算框架的异常处理机制
Web计算框架作为一种分布式计算的方法,面对的计算环境复杂多变,异常情况不可避免。对于计算元的执行异常情况必须给用户提供一种合理的处理途径,否则在一些特殊情况下会严重影响用户的工作效率。如何及时、有效地处理计算元中的异常并为客户端提供友好的异常信息,增强与客户端异常处理的交互能力就变得尤为重要[10]。
当用户执行一个计算元的过程中出现异常情况,系统提供了2种处理方法:继续机制和退出机制。继续机制能够保证在计算元的执行出现异常的情况下计算步骤的完整执行,而退出机制是为了防止错误数据对于系统造成不可预料的后果。构造一个同时具备健壮性和可靠性的计算框架,不仅要保证在异常情况下系统的正常运行,还要能够为用户或开发人员提供对于异常情况的解决方案。
异常处理的另一个关键点是对异常信息的匹配方法,当客户端接收到服务端执行异常的返回信息,其信息主要包含计算元编码、系统异常提示信息等,系统会根据计算元编码和异常信息从异常数据库中匹配解决方案,这样就为用户提供了一个基于日志的异常解决方案。当系统不能提供完全匹配的解决方案,用户可以自行维护异常数据库,使得系统后期对于同种异常能够提供正确的解决方案。
附录A图A1展示了国家电力调度通信中心OMS中调度日报的数据计算过程,界面上展现了计算步骤与其隶属步骤的执行关系。可以看出在计算过程中,当计算元出现操作失败的情况时,系统会提示异常的错误原因,并给出当前匹配的解决方案。
3 结语
本文设计了基于MVC架构的Web计算框架。在解决动态计算问题的基础上,无论操作成功与否,均能实时显示计算操作状态,有效改善与用户的交互体验。同时实现了Web计算步骤的串行和并行方案,提高了计算效率,能满足复杂多变的业务需求。基于日志的异常处理模式,为用户提供异常解决方案,提高处理任务的效率。下一步可考虑事件处理的主动机制和计算流程中的用户权限动态控制,从而增强计算元的交互能力和框架的安全性。
附录见本刊网络版(http://aeps.sgepri.sgcc.com.cn/aeps/ch/index.aspx)。
参考文献
[1]林峰,胡牧,蒋元晨,等.电力调度综合数据平台体系结构及相关技术[J].电力系统自动化,2007,31(1):61-64.LIN Feng,HU Mu,JIANG Yuanchen,et al.Architecture andrelated techniques of a power dispatching data platform[J].Automation of Electric Power Systems,2007,31(1):61-64.
[2]周宇辰,刘昕鹏,王夕宁,等.面向服务的计算(SOC):技术、规范与标准[M].北京:电子工业出版社,2010.
[3]霍雪松,李晋,吴玉林,等.基于E语言的统一电能量计量系统互联方案[J].电力系统自动化,2006,30(24):73-76.HUO Xuesong,LI Jin,WU Yulin,et al.Interconnectedscheme of unified telemeter reading system based on E language[J].Automation of Electric Power Systems,2006,30(24):73-76.
[4]胡斌,张晓帆,孔震.基于PI3000平台的电力企业模型可视化研究[J].计算机应用,2009,29(12):250-252.HU Bin,ZHANG Xiaofan,KONG Zhen.Visualization ofpower enterprise model based on PI3000platform[J].Journal ofComputer Applications,2009,29(12):250-252.
[5]李熙春,郭王勇,熊纬,等.基于MVC模式实现新型通信管理单元设计[J].电力系统自动化,2008,32(9):61-64.LI Xichun,GUO Wangyong,XIONG Wei,et al.Newcommunication management module design based on MVC mode[J].Automation of Electric Power Systems,2008,32(9):61-64.
[6]孔震,林峰,俞俊.PI2000工作流引擎的设计与实现[J].电力系统自动化,2003,27(21):75-78.KONG Zhen,LIN Feng,YU Jun.Design and implementationof a PI2000workflow engine[J].Automation of Electric PowerSystems,2003,27(21):75-78.
[7]吴凡,丁岳伟,曹健.Web服务环境中的复杂事件处理[J].计算机应用研究,2009,26(7):2550-2553.WU Fan,DING Yuewei,CAO Jian.Complex event process inWeb service[J].Application Research of Computers,2009,26(7):2550-2553.
[8]马建刚,黄涛,汪锦岭,等.面向大规模分布式计算发布订阅系统核心技术[J].软件学报,2006,17(1):134-147.MA Jiangang,HUANG Tao,WANG Jinling,et al.Underlyingtechniques for large-scale distributed computing orientedpublish/subscribe system[J].Journal of Software,2006,17(1):134-147.
[9]郑震坤,张闶,王小鸽.支持复合事件的模型及其在中间件中的应用[J].计算机工程,2006,32(12):52-55.ZHENG Zhenkun,ZHANG Kuo,WANG Xiaoge.Model ofsupporting composite event and its implementation inmiddleware[J].Computer Engineering,2006,32(12):52-55.
Web调度系统 篇3
县级电网调度自动化是电网调度自动化系统在县调一级的应用, 是电网调度自动化的一类特例, 它具有一般调度自动化系统的构成和功能, 也有县调本身所约定的一些特点。
1.1 与国家调度、大区调度和省级调度等相比, 无论电网规模还是管辖范围县调都要小的多。小则灵活, 要求功能简单实用, 还可根据地方需要加入一些特殊功能, 万一发生故障, 影响不大。
1.2 由于县调规模小, 资金有限, 故而要求系统成本不得过高。
1.3 县级电网大多向农村地区供电, 干扰少, 适宜于采用无线通讯。目前许多地方正在筹划县调自动化系统, 为了统一功能规范、设备配置和通信规约, 避免自动化建设上出现混乱和浪费, 国家已经制定了“县级电网电力调度自动化规范”。
2 县级电网调度自动化系统一般组成
县级电网调度自动化系统主要由上位机局域网、通道控制机、电台、远程终端机 (RTU) 、模拟屏及有关接口组成。除远程终端机在各厂站现场外, 系统其余设备均集中于供电局调度中心。上位机局域网采用客户/服务器方式, 由调度机、管理机、前置机、局长室、生计处等各工作站和一台服务器通过一个HUB组成一个星形局域网。
2.1 服务器
服务器作为网络的核心, 存放采集来的数据和系统的一些配置信息, 同时也作为各工作站沟通的一个渠道。本系统配置如下:服务器采用IBM-Netfinity5500服务器。
2.2 调度机 (MS, Master Station)
调度机是电网调度自动化系统的人——机界面部分。调度机本身就是一个完整的微型计算机系统, 它主要由配有软、硬磁盘的IBM PC或其兼容机的主机、标准键盘、高分辨率彩色显示器 (CRT) 等组成。
主要功能:实现人——机对话, 形成命令与下发命令到RTU, 收集整理与处理RTU上送数据, 显示有关数据与曲线, 打印用户各种报表, 发送有关数据到模拟屏, 实现模拟屏不下位操作。在调度机上运行软件系统监控模块部分。
2.3 管理机
主要功能:实现动态图形配置 (接线图) 、参数配置、表格的生成和打印、数据输入和数据的查询等。在管理机上运行软件系统的管理模块。管理机配置同调度机。
2.4 前置机
前置机通过串行口RS-232与各RTU通信, 其中COM1口以RTS-100通信规约与符合RTS-100的旧的RTU通信, COM2口以SCI1801通信规约与符合SCI1801规约的RTU通信, 每隔一定周期即将各站呼叫一遍, 采集到遥测量和遥信量送往服务器数据库的同时也通过点一点通信直接送往调度主机的内存中, 显示在调度机界面上的主接线图中;每当接到调度机通过点一点通信发来的遥控、遥调、校时或其它命令时立即放下数据采集工作, 先将命令下发出去然后再转入正常的数据采集工作。前置机在做这些工作的同时, 也在时刻监视着各RTU的状态, 一旦有报警信号送上来, 前置机将停下所有的工作来处理报警信号, 将报警信号解码后送到通过点一点通信调度机然后再做其它工作。调度主机接到报警信号, 立即调出报警站的主接线图, 并在模拟屏上对位闪烁, 同时启动语音报警, 网络打印机打印出报警信息。
2.5 通道控制机 (CC, Channel Control)
通道控制机 (又称信道控制机) 位于调度机与终端机之间。它收到调度机下发命令后, 进行校验并经电台或载波、或有线信道发送到终端机;当收到终端机回送的数据, 进行校验并上送到调度机。前置机与通道机通过串口RS-232 (9针) 相连通信。通道机起到调制和解调的作用。由于本系统中部分RTU不是RTS-100型, 其通信规约为SCI1801, 对于此类厂站, 我们不再采用通道机, 而是用MODEM进行调制和解调, 厂站端也是RTU通过MODEM接电台。
2.6 远程终端机 (RTU)
远程终端机 (RTU) 位于变电站现场, 在无人介入下完成三大任务。一是定时采集厂站端模拟量值、开关量与脉冲量个数;二是接收调度机经信道由通道控制下发的命令, 并根据接收到各种命令回送有关数据、或执行遥控、遥调、校时等操作;三是实时上送各类报警信号。
2.7 模拟屏和控制机
调度机接收到厂站模拟量和开关状态信息 (包括实时报警信号) 按约定格式经RS-232标准口 (25针) 发送给模拟屏控制机。模拟屏控制机接收来自调度机的各种数据, 经过整理后经端口地址FSOOH, F580H, F540H发送给数显表和灯光驱动板, 再由驱动板电路送到模拟屏上使数显表和灯光按照要求的方式显示。
3 WEB条件下县级电网调度自动化系统整体设计方案
3.1 系统功能需求
县级电网调度中心的主要职责有:实现数据采集和安全监视职责;断路器的遥控操作及电力电容器的投切;实现负荷控制职责;向地调传送必要的实时信息。
县调相对于地调、省调职责相对简单。其职责决定了系统的功能需求。完整的调度系统主要功能包括SCADA功能、PAS功能、DTS功能三大部分。
SCADA要实现功能主要有:数据采集功能、数据库管理功能、数据处理功能、人机会话功能、遥控遥调操作功能、事故处理及追忆功能、报表处理功能与模拟屏、大屏幕投影接口功能、动态着色、支持异地值班打印功能、计算机数据通信子系统;
PAS功能根据县供电局的情况可适当选用其部分功能, 其主要功能有网络拓扑分析功能、状态估计、调度员潮流计算、负荷预测、静态安全分析、短路电流计算、无功电压优化/控制等;
DTS功能一般包括调度员培训和运行方式研究和反事故演习。根据县供电局的具体情况, 要完全实现SCADA功能, PA S功能可适当选择实现其部分功能, 如果有足够经济能力也可以实现DTS功能。考虑未来系统功能扩展的需求, 系统总体设计时应尽量按照实现全部功能的需求设计, 暂时没能实现的功能模块也要提供接口, 以便以后的系统功能扩展和系统升级用, 并提供相应的说明文档, 保证系统的开放性。
3.2 系统整体结构方案
信息采集和命令执行子系统主要完成微机保护、原始数据采集、事故记录及故障录波、控制与操作闭锁、数据处理与记录、与远方调度中心通信和人机联系等功能。它的功能相对独立和集中, 主要在变电站端完成。信息传输子系统在变电站与调度中心之间建立通信质量可靠的通道, 并按照规范的远动传输协议进行调度中心与变电站之间的双向信息传输。信息的收集处理和控制子系统将由各个变电站通过前置机子系统传输上来的信息进行处理, 完成实时信息处理、历史信息统计、事故处理、人机界面和上级调度网之间的数据通信。信息传输子系统和信息的收集处理和控制子系统在调度端完成。
主站系统由数据库服务器、Web服务器、调度平台和维护平台组成。上位机子系统、前置机子系统和企业MIS系统通过全交换式快速100M以太网构成Intranet, 实现了企业内部的数据和信息共享。为了实现和外部网络的连接, 可以通过电信部门提供的数字专线, 连接到Intranet和公共信息网, 以便向外界发布电力信息和获取外部的资源, 为了保证Intranet内部的信息保密和网络安全, 所有与外部的联接通过防火墙软件 (代理服务器) 进行。基于Intranet的电网调度自动化系统结构见图1所示。
在数据传输时, 各个变电站子系统和前置机子系统之间的数据传输通过Modem、载波机或者光端机进行, 数据的中间通道可以利用电力载波通、或扩频通信、光纤通信等。光纤通信是目前认为最有前途的一种通信方式, 其技术上已达到了实用化阶段。前置机通过多串口卡实现数据的采集和发送。系统具良好的可扩充性, 子站扩充比较容易。
摘要：电网调度自动化系统是监控电网运行不可缺少的手段, 县级电网调度自动化系统目在我国电力部门得到广泛应用。介绍了县级电网调度自动化系统的特点, 分析县级电网调度自动化系统一般组成, 并结合新的Intranet/Internet技术提出了基于Web的县级电网调度自动化系统构建方案。
关键词：电网调度,县级,自动化系统
参考文献
[1]王斌.刘浙基于的电力调度自动化系统的实现[J].计算机与现代化, 2004.
[2]王晓梅.电力系统县级电网调度自动化系统的研究[J].华北电力技术, 2005.
Web调度系统 篇4
电力企业电网调度自动化系统是其网络管理的核心部分, 其采集的数据是进行电力管理和生产管理的基础数据。同时, 通信网络的建设耗资巨大且周期长, 因此电力系统调度自动化系统的通信网络必须是企业管理网络的通信干线网[3]。因此, 需要综合考虑以上问题, 采用最新的科技手段, 设计最佳方案, 在利用已有通信网络的前提下, 建设电力企业调度自动化系统的各项功能, 为实现功能强大、性能完善的电力企业管理网络提供保障[4]。
1 县级电网调度自动化系统的发展现状及存在的问题
随着电网调度自动化技术的不断进步, 县级电网调度自动化系统在实际应用中取得的显著的效果。通过对县级电网调度自动化系统的现状及发展趋势的研究, 总结了电网调度自动化系统存在的几个问题。
1.1 主站系统
电网调度系统的主站系统的开放性不够。电网调度系统的主站系统应该能满足上级局SCADA系统、本局管理信息系统、负荷管理和预测系统等部分的实时信息共享。目前的网调度自动化主站系统功能单一、开放性差, 不能与其他系统进行数据共享。
其次, 在县级电网调度自动化系统应以实现“四遥”为目标。随着电力系统自动化水平的提高和变电站无人值守的需要, “遥视”功能变的越来越重要。但现阶段变电站远动系统还不能满足这一要求, 无法实现“遥视”功能。在县级电网调度自动化系统的建设过程中, 应该考虑这一功能的实现。
此外, 主站系统的设备应采用双网络结构, 这样可以有效提高系统的可靠性, 减轻网络符合。主站系统应该设置专用的高性能服务器, 提高整个系统的数据处理能力和速度。在各网络节点处应采用工控机或工作站, 从而提高系统的安全性和可靠性。
1.2 电网通信
目前可以满足电网调度自动化系统的“四遥”功能的通道类型主要有微波、载波、无线扩频和光纤等。其中, 光纤和微波不仅可以实现“四遥”功能, 还可以实现“遥视”功能。但使用光纤和微波通信的缺点是造价高, 维护量大。
目前, 在县级电网调度自动化中的通信系统通常综合多种通道, 以光纤为主, 载波和无线扩频为辅, 这种通道配置将大大制约电网调度自动化系统的整体性能。从电网调度自动化系统的发展来看, 建立地区光纤环网将是必然趋势。因此, 需要选择高性能设备, 配备专业技术人员, 综合各方面因素制定科学的方案, 保证电网调度自动化系统中通信系统的安全、稳定运行。
1.3 厂站端RTU
在变电站改造过程中, 应装设远动屏, 用来完成对远动信息的接收和发送, 测量系统应采用交流采样方式, 从而提高采样的精度和速度, 减小采样环节造成的误差;在新建变电站过程中, 选择微机综合自动化系统的产品时, 应采用具有接收和发送功能的独立远动信息单元, 使其不受后台监控机的控制, 防止在后台监控机运行时无法接收和发送远动信息。
在现有的变电站自动化子系统中, 有些变电站的主变不具备自动调压功能, 应选择有载调压主变;有些电容器不具备调容功能, 无法充分利用系统调节容量, 实现对电网的无功补偿, 应选择可调容式电容器;有些变电站综合自动化功能不完善, 不具备远动修改功能, 无法完成对主变有载调压和调容的远动操作。应详细考察, 选择功能完备的变电所综合自动化系统。
2 Web技术在电网调度自动化系统中的应用
目前, 计算机技术的快速发展促进了电网调度自动化系统的进步, 使其在结构上发生了本质的变化。系统结构从集中式发展为分布式, 又从分布式发展为开方式。从电网调度自动化系统的发展来看, 今后将朝着以下几个方向发展。
(1) 应用集成。平台的整合主要包括一体化设计, 资源共享;数据整合主要采用了面向设备对象设计;应用构件指“即插即用”, 第三方软件集成。 (2) 信息集成。主要是指采用统一数据交换模式和访问接口。 (3) 企业模式。主要是有管理模式向服务模式转变, 以及面向电力市场的设计。
Internet/Intranet主要是由一系列的国际标准和技术构成, 扩展了Client/Server的结构, 从而形成了由浏览器、Web服务器和数据服务器组成的结构。与传统的Client/Server相比, 在结构上存在着以下优势。
(1) 具有良好的开放性。I n t e r n e t/Intranet所采用的标准具有很强的开放性, 有利于上级局SCADA系统、本局管理信息系统、负荷管理和预测系统等部分的实时信息共享。此外, 不受应用平台的限制, 可以利用现有的系统和设备, 完成各系统之间的移植。
(2) 具有很强的可维护性。In ter net/Intranet在生成新程序后, 可以通过Web服务器对其进行系统的维护, 同时系统的正常运行不会受到影响。这与Client/Server中需要不断更新终端用户系统相比, 其维护性更强。
(3) 具有应用程序开发周期短的特点。Web应用程序的设计主要采用Internet和OOP (ObjectOrientedProgramming) 技术, 采用以上方法可以使用户界面的设计变的更加简单, 开发人员可以将主要精力集中在系统的数据结构、处理方式以及应用模型中, 从而节约县级电网调度自动化系统的设计、开发成本。
(4) 具有良好的扩展性。Intranet的设计可以根据具体需要确定规模, 从而保证投资的收益。
B/S结构是We b技术应用于C li e n t/Server的产物, 而Intranet的核心是Web技术。在Client/Server三层结构中, Web服务器同时为客户的“代理”和数据库的客户机, 从而将不同来源和格式的信息通过统一的界面提供给终端浏览器。采用Web技术的Intranet主要以TCP/IP协议为基础, 这种技术在以Web为核心的企业内部网中采用的越来越多。其终端浏览器具有成本低、操作简单的特点, 可以方便的应用于企业的Web站点中, 查阅所需数据。由于终端操作界面具有一致性, 从而解决了在两层结构的C/S模式中, 终端客户采用多种程序造成企业资料的不一致性。服务器端的开放连接设计, 可以增强企业与外部的联系。此外, 动态互交式的信息发布可以提高企业对客户的服务质量, 带来更多的商业机遇。在三层结构的Web技术中, 数据库直接与Web服务器通信, 具有动态性、实时性和交互性, 它主要是通过CGI, ISAPI, NSAPI以及Java创建的服务器应用程序实现的。Web技术的优点是采用了多媒体信息和超链接技术, 服务器可以使用HTML语言描述网络资源以及创建网页, 并通过HTML数据文件保存, 供Web浏览器使用。HTML文件的主要特点是具有交互性, 超链接使文档中的文本和图形可以连接到服务器的其他文档中, 使资料的搜索变的更加快速、简单。此外, HTML网页可以将用户需要通过表单的形式提交到数据库, 这种数据库通常支持多媒体数据类型。Web浏览器主要用于检索和显示的终端应用程序, 通过超文本HTTP协议与Web服务器连接, 通用型的Web浏览器可以解决两层结构的C/S模式中, 终端客户采用多种软件的开发和维护费用。
目前, Web技术在调度生产管理和办公系统自动化等方面得到了广泛的应用, 取得了显著的效果。但在对实时性要求更高的工业控制领域的应用还有待于进一步的研究。
3 结语
县级电网调度自动化系统具有投资巨大、建设周期长的特点, 其科技含量较高主要涉及计算机、网络通信、电力系统等多个学科。县级电网调度自动化系统在电网的实时监控、故障处理等方面都发挥着重要的作用, 并为科研、管理和生产部分提供重要依据。县级电网调度自动化系统的应用为县级电网调度提供了先进的调度技术, 保障了县级电网的安全、稳定运行。
参考文献
[1]彭丰, 王为国, 周想凌.电网自动化系统的现状与发展[J].湖北电力, 2004, 28 (6) :41～44.
[2]王晓梅.电力系统县级电网调度自动化系统的研究[J].华北电力技术, 2005, 8 (10) :28～32.
[3]王斌, 刘浙.基于Web的电力调度自动化系统的实现[J].计算机与现代化, 2004, 11 (111) :99～103.
Web调度系统 篇5
随着计算机技术的发展、互联网应用的普及,面对竞争日益激烈的市场,企业不同的部门建立了应用和管理信息系统,但是这些应用系统一般都是独立子系统,未形成企业内部完整的ERP,而且这些功能子系统可能来自不同的软件开发商、供应商,或者是自主开发形成,有着各不相同的数据格式与实现架构。随着业务的扩展,竞争的加剧,企业提高核心竞争力要求子系统协调工作。这些系统管理不同对象,它们由于功能重叠和数据冗余交叉,系统相对独立运行,企业内部形成“信息孤岛”,相互之间很难实现信息交流与共享。各系统在企业信息和数据的更新不同步、不一致,会引起部门之间的矛盾。C/S应用模式的系统没有向外界提供接口,不便于企业信息发布管理。随着公司业务部门的业务复杂化,许多公司不得不重新设计他们的应用系统或者花费巨款并收集大量的数据以维护他们的遗留系统。因此,对于公司来说,找到一个快速而高效的方式来保留和重复利用这些遗留系统,而不是把它们扔到一边是非常重要的。传统上,为提供跨各种不同应用程序和操作系统的通信和集成,公司会求助于企业应用程序集成(EAI)。
然而,传统的EAI解决方案具有以下缺点:a.采用的技术单一,在自由性和多样性上有很大的限制。b.采用的是专用的标准,开放性不够。c.体系结构的动态可扩展性差。所以许多公司正在寻找一种更加简易、灵活的方式来巩固和现代化他们的应用程序。为了提供服务和与业务合作伙伴、顾客及其他信息系统共享数据,企业必须以当前的技术更新他们的遗留系统。一个解决方案便是利用WebServices和业务流程执行语言(BusinessProcess ExecutionLanguage,BPEL)[1]。这些技术提供开放的、基于标准的集成,该集成通过组合消息传递技术和XML及各种WebServices标准来提供互操作性。一旦开发了Web Service接口,就可以使用BPEL来定义和编排业务事务,最终使遗留系统转变成全新的现代信息系统。本文将主要对BPEL进行介绍,并对服务组合中的合理调度问题进行重点分析和解决。
1问题的提出
WebService的业务流程执行语言BPEL是专为整合WebService而制定的一项规范标准。它是一种基于XML的工作流语言,是IBM的WSFL和微软的XLANG融合的产物[2]。BPEL可以整合现有的WebServices,将现有的WebServices按照要求的业务流程整理成为一个新的WebServices,再在这个基础上,形成一个从外界看来和单个Service一样的Service。例如,可以创建一个订货业务流程编排,它可以首先调用一些自己的内部服务,然后调用一些贸易伙伴的外部服务。一旦已经获得了所有的响应,经过整理和协调之后,编制的最后一步将完成的结果返回给源服务。这个编排确保了事务中的每一步都依照规则执行。可以说,每个可执行的BPEL流程是作为一个WebService展示给世界的。虽然WebService技术(比如WSDL和XML)被设计为平台中立的,但是包括一些关键WebService概念的集成语言可使公司节省大量的时间和资源。此外,BPEL还严重依赖于WSDL,并把由WSDL提供的关键抽象作为它自己的关键抽象[3]。这使得BPEL成为一种操纵WebServices的自然语言。所以,对应用程序集成来说,企业中可用的WebServices越多,BPEL就越重要。
虽然BPEL在企业的实现自动化的过程中最大程度地降低了成本,而且增加了企业在快速变化的市场环境下的敏捷性,并且可以以一种自动化实际业务流程的方式扩充,不断增加WebServices。但是,Web服务组合过程中所组合的服务一般具有两个特点:一方面,这些Web服务可能是以不同的方式创建、用不同的语言实现、由不同的供应商提供的。另一方面,所要组合的服务单元不可能很复杂。所以,在组合复杂的Web服务过程中就存在这样的问题:如何定义这些基本服务单元之间的逻辑和时序关系,以保证复杂Web服务执行的自动化和有序性[4]。
2解决合理调度的框架
因为复杂服务的执行实际上是由基本的通信、协调和执行来完成的。所以提出如下方案来解决组合服务执行过程中基本服务的合理调度问题。
2.1合理调度框架的设计
图1架构主要由4部分组成:业务流程层、组合状态控制层、服务调用层、Web服务层。其中业务流程层是由业务流程执行语言BPEL来定义和编排业务事务,形成企业运行的业务流程。组合状态控制层是组合服务合理调度的核心,主要控制何时结束当前的服务,继而调用业务流程中的下一个服务,后面将详细介绍组合状态控制器。服务调用层的主要功能是根据组合状态控制器提供的消息来调用Web服务层中相应的服务。Web服务层主要提供本行业所有可能用到的Web服务。
2.2 组合状态控制器的设计
组合状态控制器的设计是通过定义这些基本服务单元之间的逻辑和时序关系,以保证复杂Web服务执行的自动化和有序性。为此提出一种思想:在组合状态控制器中提前设定某业务部门甚至某单位所有可能用到的服务单元的初始状态、执行后的状态。在组合服务的流程中组合状态控制器通过检测业务流程中服务单元的执行状态,来决定何时结束当前的服务单元,进而启动业务流程中的下一个服务。
设定服务单元的状态属性表StatusAttributeTable为:
现对其中各字段说明如下:
(1)Web ServiceNO主要存储每个Web Service的编号,这一点主要是为了防止Web服务层中出现相同Name的Web服务,或者新生成的Web服务和已存在的服务名字冲突。Web ServiceNO的设置可以在把遗留系统功能组合新的Web Service的时候进行。
(2)Web ServiceName主要存储Web Service的Name。
(3)Initial Status存储的是Web Service运行的初始状态,在该服务单元未被执行过一次之前Initial Status记录为“0”,如果该服务被调用过一次之后则修改为“1”,这样根据业务流程进行服务查找调用的时候,可以先查找记录为“0”的服务单元(因为对某个业务流程来说,基本不会出现重复的服务调用),然后再查找记录为“1”的服务单元,这样在一定程度上提高了查询服务的效率。
(4)End Status主要存储服务单元执行后的状态。主要通过组合状态控制器监测当前正在执行的服务单元,一旦正在执行的服务单元和组合状态控制器中存储的该服务单元的结束状态相匹配时,则结束该服务单元,继而调用业务流程中的下一个服务单元。
2.3 工作过程
首先对正在执行的服务单元进行监测:
equals(executingWebService.EndStatus, StatusAttributeTable.WebServiceNO.EndStatus)
如果比较的结果为假,则继续对当前执行的服务单元进行监测,如果比较的结果为真则结束该服务单元,同时将结束的该服务单元的Initial Status设置为“1”。
然后查找、调用业务流程中的下一个服务单元。
从StatusAttributeTable中选出还未被调用过的Web Service:
SELECT *
FROM StatusAttributeTable
WHERE Initial Status=0
从未被调用过的服务单元集中通过快速查找算法查找所要调用的服务单元的Web ServiceNO,最后执行该服务单元。
3 结语
组合控制器的设计,对有效的解决基本服务单元之间的逻辑和时序关系,保证复杂Web服务执行的自动化和有序性,实现组合服务过程中的服务单元合理调度具有重要意义。对基于Web Service企业应用集成的服务自动组合具有较大的参考价值。
摘要：介绍了当前企业信息系统存在的问题,指出了EAI的缺点,对BPEL进行了简单的概述。在Web Service和BPEL技术基础之上,给出了在一个组合服务过程中如何解决服务单元合理调度问题的框架,并分析了框架的结构,对服务单元的状态属性表进行了设计。
关键词：组合,Web服务,调度,BPEL
参考文献
[1] Kolawa A.BPEL in a serrice-oriented architecture.http://www.ft-ponline.com/ea/magazine/spring2005/features/akolawa.June 2006
[2]莫小军.Web Services在企业应用中的研究.重庆大学,硕士论文,2004
[3]吴军,邓超,邵新宇,等.基于Web Services的企业应用集成方法研究.计算机应用研究,2006;(8):64—66
Web调度系统 篇6
构建Web服务器集群是提高Web服务器性能的有效方法。典型的Web服务器集群由一个负载分配器(dispatcher,又称前端服务器)和若干个后端服务器组成。前端服务器接收外部发来的访问请求,并通过某种负载分担技术,将客户请求分配到某一台后端服务器上。
Web服务器集群系统中的请求分配算法用于将服务请求转发到某个目标服务器上去处理。一个好的请求分配算法应能适应异构系统,并能够依据各节点资源及负载情况进行动态分配和调整。请求分配算法按照其分配请求时所依据的信息可以分为两类:非基于内容的和基于内容的算法。基于内容的请求分配算法根据请求URL等应用层信息进行服务器选择,其优点是:(1) 易于获得较高的缓存命中率;(2) 可将服务内容在服务器之间合理划分,使每台服务器只储存部分服务内容,从而大大提高整个集群服务扩充能力;(3) 可令某些服务器提供特定的网络服务,以满足客户对持久连接(如SSL服务)、服务质量、IP安全等方面的特殊需要;(4) 可以区分静态请求内容和动态请求内容,从而提高集群的总体性能[4]。
1 研究现状
近几年,基于内容的请求分配算法研究比较热,已经提出了若干种算法。典型算法的分类见文献[1,3]。
其中综合考虑Cache划分和负载均衡的算法是基于内容的请求分配算法的主流。算法主要存在两方面不足:一是对服务器负载度量不够准确;二是不能很好地对后端服务器内容进行划分。为解决这些不足,本文提出一种部分复制的基于内容调度算法。
2 PRLARD算法
2.1 算法思想
(1) 将Web集群的后端服务器内容进行划分,使每台服务器只贮存部分服务内容,从而提高集群服务的扩充能力,同时提高访问的Cache命中率。
(2) 为了实现负载均衡,算法采用有限复制思想[2]。这样既提高服务扩充能力,也实现了负载均衡调度。
(3) 只有当部分服务器负载过高或过载,而别的服务器负载较低时,才进行均衡调度。
(4) 服务器的负载计算采用动态加权方法。即根据各后端结点的CPU利用率、可用内存以及磁盘I/O、进程总数状况进行负载计算。具体方法是:为每一个参数设定一个系数Ri(可根据实际情况动态调整),以表示该负载参数的重要程度,其中∑Ri=1,结点Ni的负载水平为:
LOAD(Ni)=R1*Lcpu(Ni)+R2*Lmemory(Ni)+
R3*Lio(Ni)+R4*Lprocess(Ni)
其中Lf(Ni)表示结点Ni当前某一项参数的负载值,上述公式中依次表示:CPU使用率、内存使用率、磁盘I/O访问率、进程总数。在Web服务器集群中,采用系数{0.2,0.4,0.2,0.2},内存权值为0.4,即认为内存较其他参数重要一些。
2.2 算法内容
算法流程如下:
while (true) {
fetch next request r;
n←SOOP(r);
m←mirror(n);
if(n.load is overload &&m.load < Thigh)
migrate part of n.load to m;
elseif (n.load > Thigh && m.load < n.load)
r.target←m;
else
r.target←n;
send r to r.target;
}
2.2.1 后端服务器内容的划分及镜像点的设置
本文采用一种基于URL字符串排序的划分方法SOOP(String-Oriented Ordering Partition)对服务器内容进行划分,其优点是:(1)可以将连续的URL分配到同一个后端服务器上,从而适应人们对Web服务器进行设置和管理;(2) 该算法将Web的内容等分,可以适用于对服务器内容进行划分和部分复制,并有利于集群的负载均衡性。
首先把Web集群的全部URL按照字母升序排列,并将全部URL分为k*n个集合(n为后端服务器个数,k为对URL划分的粒度系数),每个集合(称为URL子集)中包含的URL数目相等。然后根据历史访问记录统计出对各子集的访问流量,依据流量大小将k*n个子集顺序排列,并采用分段互补方法,将Web内容平均分配到n个后端服务器上。这样,每个后端服务器上分配k个子集,即每个服务器上的内容是全部Web内容的1/n。我们称每个服务器是其所分配内容的目标服务器。
为了进行负载均衡调度,还要对各个子集的内容在除目标服务器之外的后端上设置有限数目的镜像。当集群运行过程中出现负载不均衡时,根据分配算法将负载在目标服务器和镜像服务器之间进行调度。
2.2.2 负载的收集和负载均衡调度
本文将服务器按负载情况分成6个状态,从状态1→状态6依次表示空闲、较低、正常、较高、甚高、过载。如果负载没有发生状态变化,后端服务器每隔10秒用UDP包(包含一个时间戳和负载状态)向前端服务器报告一次;当负载从一个状态跃变为另一个状态时,则立即向前端报告。
当所有服务器状态都处于状态1、状态2、状态3以下时,由于所有后端服务器的负载都较低,不进行负载均衡调度,新来的客户URL请求直接分配到目标服务器。
如果一个URL的目标服务器为状态4以上,则比较其目标服务器和镜像服务器的负载,将请求分配到负载较低的服务器上。
如果某个服务器的负载处于状态6(过载),则分析其所有镜像服务器的负载状态,如果存在处于状态4以下的镜像服务器,则将相应部分的负载迁移到该镜像服务器,并修改规则集,将该部分URL的目标服务器和镜像服务器互换。此后的请求将直接分配到新的目标服务器上。
按照上述规则对请求进行分配,由于不同URL分配的目标服务器不同,因此可以保证不同后端服务器的Cache内容都不相同,从而提高访问的Cache命中率,同时也具有较好的负载均衡调度能力。
3 实验方案及结果分析
3.1 实验方案及结果
我们在Linux系统(Debian GNU/Linux 3.0)中仿真实现了一个PRLARD算法。本实验从http://kdd.ics.uci.edu站点上获得微软网站某一周内的访问日志,包括294个URL,32711个访问事件。实验采用的集群结构如图1所示。系统运行一个负载分配进程,该进程利用日志回放的方法产生URL访问请求,并同时进行负载的分配。另外设置n个进程,分别模拟n台后端服务器,接收并解析URL,计算负载情况,并向负载分配器报告自己的状态。
负载均衡度是指服务器集群所有后端服务器负载的总偏差与总负载之比。负载偏差可以用方差、均方差等表示,本文实验中采用服务器的实际负载与平均负载之差的绝对值表示。负载均衡的计算公式如下:
式中BL表示负载均衡度,Li为n台服务器中第i台服务器的负载,L为n台服务器的平均负载。显然,负载均衡度越小均衡效果越好。
首先,评估不同划分的方法对负载均衡度的影响。我们以HfIp散列算法[11]和本文采用的SOOP划分方法进行对比, HfIp被用于天网搜索引擎,是比较好的URL散列函数。实验对比了集群节点数目n为4,8,12,16,32情况下, HfIp散列方法、SOOP方法(k=1)、SOOP方法(k=2)的负载均衡度变化,如图2所示。
其次,评估不同的划分粒度k值对负载均衡度的影响。实验测试了节点数目n为4,6,8,12的情况下,k取1→5时不同的负载均衡度。结果如图3所示。另外,为了验证对Web内容访问的不均衡性,我们对不同URL的访问率进行了统计。先按访问率由高到低对URL排序,然后将URL等分为20份,每份占总内容的5%,再依次计算出每部分的访问率。结果见图4。
3.2 实验结论与分析
(1) 从图2可以看出:SOOP(k=1)方法获得的负载均衡度略优于采用HfIp散列方法;HfIp方法虽能使URL均匀散列,但因网络访问的不均衡性,其负载均衡性能并不是很好。而由于采用了分段互补方法,SOOP(k=2)算法负载均衡效果远优于HfIp散列方法。
(2) 对应不同的k值,负载均衡度有所不同。由图3的实验结果可知,一般k越大则负载均衡度越小,即节点负载越均衡。这是因为适当增加划分粒度,会使分配在各后端服务器的负载更加均匀。但当k增加到一定程度,再增加k值时负载均衡度的增加将会变得不明显。对于本实验所用的Web内容,k值取3会达到较好效果。
(3) 图2和图3显示,随着集群节点数的增加,负载均衡度也在加大。对于内容一定的网络集群而言,节点数目越多,各节点分配的URL数就越少。由于对不同的URL访问的负载差异很大,就增加了不同节点间负载差异的程度,从而导致负载均衡度增加。
(4) 图4结果表明,对URL访问具有极度不均衡性,绝大部分访问集中在很少一部分网页上。其中65%的访问集中在访问率最高的5%页面上,而访问率低的50%的页面总访问量只占1.8%。
4 结 语
在对现有基于内容的集群调度策略进行系统分析基础上,本文针对存在问题设计了部分复制的调度算法PRLARD。该算法首先根据URL把服务器内容分为k*n个子集,然后依据客户对其访问的流量大小对各子集排序,并采用分段互补方法把它们分布到n个后端服务器中,从而使各个后端服务器分担的负载尽可能均匀。同时,对各个子集在目标服务器之外的其他服务器上设置一定数目的镜像。当集群运行过程中出现负载不均衡时,将负载在目标服务器和镜像服务器之间进行调度,以实现服务流量的均匀分配。理论分析和实验测试表明,该算法具有高的CACHE命中率和良好的自适应负载均衡能力。
摘要：基于内容的Web服务器集群调度算法具有很多优点。在分析已有方法基础上,提出一种部分复制的基于内容调度算法PRLARD(partially replicated locality-aware request distribution)。理论分析和仿真结果表明,该算法具有良好的负载均衡能力和高的CACHE命中率。
关键词：Web服务器集群,Cache命中率,负载均衡,内容分配
参考文献
[1]Cardellini V,Casalicchio E,Colajanni M,Yu P.The state of the art inlocally distributed web-server systems.ACMComputing Surveys,2002,34(2):263-311.
[2]Pai V S,Aron M,Banga G,et al.Locality-aware request distribution incluster-based network servers.In Proc.The 8th Conference on Archi-tectural Support for Programming Languages and Operating Systems,San Jose,CA,Oct.1998:205-216.
[3]Bryhni H,Klovning E,Kure O.A Comparison of Load Balancing Tech-niques for Scalable Web Servers,IEEE Network,July/August2000:58-64.
[4]Zhu H.Scheduling optimization for resource-intensive Web requests onserver clusters.In Proc.11th Annual ACM Symposium on Parallel Al-gorithms and Architectures(SPAA 99),June 1999:13-22.