分布式软件（精选7篇）
分布式软件 篇1
1 引言
随着21世纪的到来, 软件工程的实践逐渐加深, 软件系统的规模和复杂性与之相应, 人们已经深刻的意识到系统的总体架构设计和文档说明的重要性, 已经远远超过了特定算法和数据结构的选择, 一个良好的体系架构能够保证软件系统开发成功。迄今为止, 软件体系结构没有一个固定的定义, 软件体系结构面向不同的研究目标, 具有不同的定义, 具有以下特点:软件系统架构是一个较高层次上的抽象, 该架构并没有涉及具体的系统架构, 同时也不关心具体的实现;软件体系架构应该支持软件系统的所需要完成的功能, 因此, 在进行软件架构设计时, 必须要认真的考虑系统的动态行为;在进行软件体系架构设计时, 系统分析员应该考虑现存系统的兼容性、系统的安全性和可靠性, 同时还要考虑系统运行维护过程中的伸缩性和扩展性。
2 现代分布式软件系统架构
2.1 两层的客户机/服务器架构
两层的客户机/服务器架构 (C/S) 架构是一种常见的软件系统体系结构, 服务器是网络的核心, 而客户端是网络的基础, 客户端依靠服务器获得所需要的网络资源, 而服务器为客户机提供网络必须的资源。由于硬件上的优势客户端可以分解服务器端的部分压力, 所以降低了系统对于通讯的开销要求。目前大部分应用软件系统均采用了C/S形式的两层模型结构, 随着软件应用开发正发展为分布式的Web应用程序, 网页应用程序和传统的C/S应用程序的均可以完成相同的业务流程, 应用不同的模块共享逻辑组件;虽然C/S体系的软件开发模式有一定的扩展性, 但是相比较目前发展最迅速的互联网技术, 它还是显得有很大局限, 所有的客户端必须安装客户端程序才可以连接到服务器, 而不能实现移动办公, 互联网办公。用户期望可以使用真正的开放式系统, 不是局限在一个局域网内使用, 而是可以真正实现不分平台, 不分操作软件, 不分系统版本的通用设计, 这是C/S架构的软件所不能实现的。C/S架构的软件在开发之初必须制定好操作系统及开发技术和数据库, 当用户的系统环境需要升级变更时必须要重新进行软件开发, 更换系统的边际成本极高。
2.2 三层的浏览器/服务器架构
三层的浏览器/服务器架构 (B/S) , 它跟C/S架构不同, 不需要客户端安装软件, 所有的操作在客户端层面都是通过网页基于web服务来完成的。作为两层结构, 在浏览器层面几乎没有事务处理功能, 只有很少一部分是在浏览器端处理的, 绝大多是的任务都是由浏览器端通过http请求发送到网页服务器进行处理, 然后服务器将处理后的数据发送回客户的浏览器页面, 采用这种架构需要用户建设好互联网络, 需要客户端电脑能够上网, 就可以实现软件的操作, 这就大大解放了对客户端电脑的要求, 只需要对服务器硬件进行主要投资就可以, 大大节约了用户的成本。服务依托于网络, 只要可以连接到网络服务器就可以实用软件, 从而实现了移动办公, 不但可以在局域网内办公并且还能通过互联网办公, 在局域网间建立以B/S结构为模型的网络应用, 并通过互联网模式下的数据库应用, 是成本较低、成功率较高、易于维护和使用的开发方式。相对比传统的C/S架构软件, B/S架构具有更方便快捷的使用效果, 在当前各种扩平台面向对象的开发语言出现的情况下, 采用基于B/S的管理软件将使开发变得更为方便, 快捷, 高效。
某公司通过调研组成部门和人力资源, 通过访问公司的每位员工, 积极听取每位员工的建议, 分析了人力资源管理系统的功能, 主要包括五个相关的子系统, 分别是招聘管理系统、培训管理系统、人员管理系统、薪水管理系统以及奖惩管理系统。这个系统采用了B/S体系架构, 具体内容如下:
表示层:在分布式人力资源管理系统中, 表示层在B/S体系架构中处于与用户直接接触的层面, 用户使用相关的IE浏览器等工具, 输入系统的登录链接地址, 即可弹出用户的登录信息, 系统的登录界面弹出后, 用户如果没有登录账号, 完成注册之后即可登录系统;如果用户有登录账号, 即可直接输入信息登录系统。进入系统之后, 用户即可根据相关的分布式管理系统提供的功能发送逻辑业务请求, 该请求直接发送至系统的逻辑业务处理层, 逻辑业务处理即可针对系统的逻辑业务请求进行处理, 处理完毕之后即可反馈相关的处理结果。
逻辑层:分布式人力资源管理系统中, 逻辑业务处理层非常重要, 其需要处理表示层发送的客户端逻辑业务请求, 逻辑业务处理层收到客户端发送的请求之后, 即可对其进行解析, 将用户的请求分为逻辑业务处理和数据业务处理两个方向, 如果用户的请求仅仅涉及逻辑业务请求事务, 即完成之后就可以反馈处理结果给客户端表示层;如果存在数据业务处理, 其需要将请求发送至数据业务处理层, 处理完毕之后反馈结果给客户端。
数据层:数据业务处理层由数据库服务器构成, 其保留一个高性能的数据库服务程序调用接口, 当逻辑业务处理层调用接口程序发送数据处理业务之后, 数据库服务器对数据库进行查询、插入、修改或者删除操作, 并且将处理的结果反馈给逻辑业务处理层, 逻辑业务处理层收到数据处理结果之后, 与逻辑业务处理层的结果一起反馈至客户端表示层, 以便系统用户进行浏览和查看。
3 结束语
随着分布式软件使用人数的逐渐上升, 为了提升分布式软件系统的响应速度和性能, 诸多计算机学者分布式软件系统架构进行研究, 比如为分布式软件采用混合式架构, 局域网使用C/S体系架构、外网使用B/S体系架构, 提升用户的使用感知, 必将得到更加广泛的使用。
参考文献
[1]林闯, 贾子骁, 孟坤.自适应的未来网络体系架构[J].计算机学报, 2012, 35 (6) :1077-1093.
[2]张淑荣, 苏兵.C/S与B/S两种软件体系结构[J].电脑学习, 2010, 6:l26-127.
[3]李云云.浅析B/S和C/S体系结构[J].科学之友:中旬, 2011 (001) :6-8.
[4]张淑荣, 苏兵.C/S与B/S两种软件体系结构[J].电脑学习, 2010, 6:l26-127.
[5]王进.B/S模式下的三层架构模式[J].软件导刊, 2011 (3) :30-31.
分布式软件技术及其应用研究 篇2
随着计算机网软件技术地迅猛发展, 一些先进软件技术也非常普遍地应用在我们的实际生活中, 但是现在国内的软件无论是在技术上或应用上都比国外要落后。现在的软件产品的存在问题主要有[1]:1) 适应性差, 结构比较死板;2) 集成度低;功能较单一;3) 稳定性差, 可重用程度比较低;4) 开放性差, 接口专用。所以采用新的软件技术才能满足现在数字图像处理和工业自动化和实际需要, 我们应该加大分布式软件技术的研究及其应用。
2 分布式软件技术
分布式软件通常被定义为:分布式软件技术是将物理上的分布不同网络节点的各个软件组件经过分布式组件技术使其组成一个系统逻辑统一的过程。从定义上面可以看出, 该技术的软件在逻辑上来说是属于统一的, 整个系统的全局应用平台, 在物理分布方面来说是由很多局部软件组件构成的。因此分布式软件技术也可称为组件技术[2]。
分布式组件技术满足了软件复用要求和满足了网络应用要求, 现在, 分布式软件技术正在逐步取代传统软件的设计方法, 该技术实现了软件复用和积木化, 甚至可导致软件开发的更快, 软件更高。分布式软件技术的架构很好地为网络应用开发提供支撑, 还为应用提供更好的可伸缩性和开放性。分布式软件由于在内部结构上是较松藕合的, 所以便于维护, 修改时产生的副作用极小。以分布式软件技术上来看, 这是基于组件的一种应用程序, 它是由执行框架、组件还有对象总线等组成[3]。与传统的面向对象技术进行比较, 分布式技术的进步在于实现了二进制代码复用, 现在它已经成为在开发网络环境下进行异构平台的分布式的应用非常好的手段。通常地, 组件是软件使用、开发时具有某些功能并能够维护和大报的基本单元, 其特点为拥有特定的特点和功能, 能够完成一定任务, 一些小部件能够进行组合成大部件。它具有在不同环境下的不同的工作能力;能够无缝插用, 也可以打包成软件, 实现维护。分布式软件结构主要分为六个部分:实时数据采集与处理、数据共享、报警处理、报表设计、在线响应趋势、先进控制策略。分布式软件也可按微软框架结构来进行设计, 在表示层通过对话框和视图等来实现与客户之间的交互;在业务层来实现业务的内部算法;在数据访问层主要是实现数据管理。
3 分布式软件的应用
前面提到分布式软件分为六个部分, 它们主要有如下几个功能。在实时数据采集与处理部分, 可以处理来自工业现场那些带有过失误差或者噪声的过程信息, 对这些数据进行调理和检验, 使其满足实际系统的多种控制需要、扩充需要、特殊需要等, 提升系统的灵活性与开放性。在实时响应曲线部分, 可在线跟踪实际控制对象, 进行实时响应, 加强了软件的适用性。在数据共享部分, 能够实现分布式软件的管控一体化, 可适应网络控制、异地监控等需求, 整个软件数据通信的可扩展能力和开放性也得到加强, 现在很多好的企业都实现了数据共享。在报表设计部分, 该部分可根据不同控制对象产生不同报表, 对数据进行实时记录、整理等功能, 还可对不同需求修改或增加报表类型。在控制策略部分, 可使软件的可维护性、可靠性、平台无关性、可移植性、代码复用性等大大加强。下面以其中的实时数据采集部分为例进行详细说明[4]。
在分布式软件中的实时数据采集部分所采用的数据采集卡主要为PCL-818L。这种采集卡PCL-818L作为一种高速数据的采集卡, 它具有A/D、D/A转换, 数据采集, 可编程计时/计数, DIO等功能[5]。所以这是一种性价比较高, 在各种各样的计算机实时控制系统中被广泛应用的采集卡, 它的数据采集方式主要为以下三种:查询方式、中断方式、DMA方式。分布式软件可利用Visual C++6.0, 然后借助数据采集卡中的DLLs包含的API函数来开发实时采集数据的程序[6]。
分布式软件技术能够解决普通软件的组织机构分散问题, 而通常情况下很多数据是需要相互联系的。譬如银行系统, 总行与各个分行常常处在不同城市或者城市中的不同位置, 在业务处理上各行可能需要彼此交换数据, 共同处理处理客户的数据, 这时就需要分布式软件系统技术了。
3 结论
本文对分布式软件技术的特点、特征进行了分析研究, 主要分为六个部分, 还对该软件的应用进行了分析, 该软件具有较好的适应性、灵活性、开放性等特点, 分布式软件技术的应用将会越来越广泛的。
参考文献
[1]王德康.分布式先进控制软件技术与应用[D].浙江大学.2001 (6) :78-82.[1]王德康.分布式先进控制软件技术与应用[D].浙江大学.2001 (6) :78-82.
[2]胡旦华.OPC技术在分布式环境下的实时数据通信[D].华北电力大学 (河北) 2004 (6) :55-59.[2]胡旦华.OPC技术在分布式环境下的实时数据通信[D].华北电力大学 (河北) 2004 (6) :55-59.
[3]陈国宝.分布式行业中间件平台的研究[D].西北工业大学.2004.[3]陈国宝.分布式行业中间件平台的研究[D].西北工业大学.2004.
[4]杨振宇.面向企业级分布式应用软件体系结构的研究与设计[D].国防科学技术大学.2004 (9) :89-92[4]杨振宇.面向企业级分布式应用软件体系结构的研究与设计[D].国防科学技术大学.2004 (9) :89-92
[5]刘广宾.分布式系统中实体交互行为的可信研究[D].湖南工业大学.2010 (6) .[5]刘广宾.分布式系统中实体交互行为的可信研究[D].湖南工业大学.2010 (6) .
分布式软件 篇3
关键词：分布式仿真,通信软件总线,软件复用
1 引言
分布式仿真系统需要由多台计算机协同完成仿真任务,仿真节点间的通信是关键问题之一。通常的“点点”通信方式,如果系统内有n个仿真程序需要通信,在极端情况下,需要有n(n-1)条逻辑通信链路。这种通信方式的不足之处在于通信链路多,数据拥塞,浪费网络带宽,造成通信效率下降;仿真程序紧密藕合,每一个仿真程序都需要知道与之通信的其它仿真程序的存在;通信方式不规范, 当系统内增加需要通信的仿真程序时,会导致对已存在的仿真程序通信代码的修改;通信数据分散,造成通信数据监控困难,不便于系统开发时的调式和系统运营后的状态监控。本文采用软件总线方法解决这些通讯问题。
2 通信总体结构
如图1所示是采用通信软件总线的分布式仿真系统的通信逻辑结构。分布式仿真系统由若干仿真节点和一个总线节点构成,各仿真节点和总线节点通过以太网络相联。仿真节点运行仿真程序,仿真程序是完成具体仿真任务或硬件驱动任务的程序。总线节点运行一个通信管理程序(以下称通信软件总线),该程序协调各仿真程序之间的通信。各仿真程序不能直接而是必须经过通信软件总线进行通信。各仿真程序向通信软件总线发送数据而不必关心这些数据发向哪个仿真程序,只需接收通信软件总线的数据而不必关心这些数据来自哪个仿真程序,数据的路由完全由通信软件总线根据外部配置文件确定,如图2所示,从而实现了各仿真程序间的通信解耦。总线节点(计算机)可配置一块或多块以太网网卡, 具体网卡数量根据具体仿真系统的通信节点数、通信流量和实时性的要求具体决定。
3 通信软件总线组成
通信软件总线由五个模块和两个外部配置文件组成,如图2所示。五个模块为外部配置解析模块、数据接收模块、数据发送模块、数据整合模块、数据监控模块;两个外部配置文件为数据包配置文件、通信路由配置文件。数据包配置文件用于定义通信数据包的结构、数据包之间的赋值关系;通信路由配置文件用于定义通信接入端口,通信发送路由。
数据包配置文件、通信路由配置文件存储于总线节点(计算机)硬磁盘上,将其从通信软件总线程序中分离出来,而不是与通信软件总线程序二为一,是为了实现通信软件总线的通用性问题。这两个配置文件为文本文件,可用任何一种文本编辑工具对其进行修改,如果需要产生一个新分布式仿真系统的通信系统,只要在这两个配置文件中填入新的内容即可,而通信软件总线程序不需做任何改变,可大大提高通信系统开发效率。
4 外部配置文件
4.1 数据包配置文件
数据包配置文件用于定义通信数据包的结构、数据包之间的赋值关系,其定义格式:
数据包配置文件:数据包列表数据包赋值列表;
数据包:struct数据包名{数据成员列表};
数据成员:成员类型成员名;
成员类型:float|double|char|short|int|long|
unsigned char| unsigned short| unsigned int|unsigned long|数据包名;
成员名:标识符|成员名[正整数];
数据包赋值:数据包名::成员标识符 = 数据包名::成员标识符;
成员标识符:标识符|成员标识符[非负整数]。
4.2 通信路由配置文件
通信路由配置文件用于定义通信接入端口,通信发送路由,其定义格式:
通信路由配置文件: 通信接入端口配置通信发送路由配置;
通信接入端 口配置 :[LinkIn Ports]= {接入端口列表};
通信发送路由配置:[Send Links]={发送路由列表};
接入端口:<packet= 数据包名,ip=IP地址, port= 端口号 >;
发送路由:<packet= 数据包名,
ip(from)=IP地址 , port(from )= 端口号 ,ip(to)=IP地址, port(to )= 端口号 >。
5 通信软件总线算法
外部配置解析模块解析数据包配置文件,在内存中建立通信数据包的结构(以下简称数据包结构)、数据包之间的赋值关系(以下简称赋值关系)、数据包存储区;外部配置解析模块还解析通信路由配置文件,在内存中建立通信接入端口(以下简称接入端口)、通信发送路由(以下简称发送路由);
数据接收模块按接入端口接收网络数据,存于数据包存储区;
数据整合模块按赋值关系对数据包存储区进行赋值操作,达到数据包整合目标;
数据发送模块按发送路由发送数据包存储区中的数据包;
数据监控模块按数据包结构显示数据包存储区,用于系统开发时的调试和系统运营时的状态监控;
通信软件总线完成通信的主要分为几个步骤。
步骤1(系统初始化):通信软件总线的外部配置解析模块解析外部配置文件的数据包配置文件,在内存中建立数据包结构、赋值关系、数据包存储区;外部配置解析模块还解析外部配置文件的通信路由配置文件,在内存中建立接入端口、发送路由。
步骤2(发送数据包):仿真程序以UDP协议经以太网络分别向通信软件总线发送数据包。
步骤3(接收数据包):通信软件总线的数据接收模块根据接入端口接收新的数据包存于数据包存储区。
步骤4(形成新的数据包):通信软件总线的数据整合模块根据赋值关系对接收到的已存入数据包存储区的数据包进行整合,形成新的数据包。
步骤5(发送新的数据包):通信软件总线的数据发送模块以UDP协议经经以太网络, 按发送路由向第一仿真程序发送新的数据包。
步骤6(显示数据包存储区):通信软件总线的的数据监控模块根据数据包结构显示数据包存储区,用于系统开发时的调试和系统运营时的状态监控。
步骤7(循环控制):继续通信,转步骤2;否则,转步骤8;
步骤8:通信结束。
6 结束语
分布式软件 篇4
事实上,任何软件制品都是过程的结果。我们从软件工程的发展历程和当前软件工程的研究情况来看,人员、过程和工具(或管理技术)是决定软件项目成败的关键因素。成功的软件项目在对适合当前项目的人员、过程和工具的侧重上维持了平衡[1]。这种观点受到了RUP(Rational Unified Process,Rational统一过程)等方法论的支持。单纯的侧重这三个方面中的任何一个方面,对于软件项目来说都会造成重大风险。
然而,随着信息社会的进步,面向云计算、物联网以及企业大型信息化项目的分布式软件开发方法的研究似乎成为了业界另一个热点,并给传统的软件开发方法提出了新的挑战。它要求软件开发团队要担负多重角色和任务并且灵活机动(这样才能提高效率)、软件开发成本要尽可能的低廉(但是不能以降低软件制品的质量为代价)、信息资源要共享(从而适应需求的不断挖掘和演进)、人力资源要整合(集多方技术优势,共同开发,解决技术及成本难题,通常称为异构组织)、过程控制要有效(要尽可能的规避开发及运营风险)等等现实要求。特别是面向云计算服务平台项目的开发,软件研发的“团队化”趋向“社会化”,编程不再是一个开发团队,可能很多组件、很多服务来自互联网,来自你不认识的人,来自于你看不见的地方[2]。面向分布运行的大规模信息化项目,支持基于广域网络的协同开发团队,规避软件过程风险,确立在需求演进状态下实现“业务驱动开发”的软件过程管理模型是本课题研究的目标。
一、大型软件项目中引入敏捷思想的必要性
1、有利于编程规范的贯彻和完善内部协同机制
从我们以往的工程实践来看,敏捷编程更需要编程规范的指导和内部协同机制的完善。每个编程小组(结对编程或者多人协同编程)需要遵循内部统一的编程规范来协调代码的可读性、可维护性、稳定性和可扩展性。从工程实践的角度来看,敏捷编程不是彻底放弃规范、放弃文档的管理、弱化系统功能的迭代层次;相反,敏捷编程需要通过强化内部沟通来完善软件制品的品质,必须要加强必要的编程规范和内部协同机制的。
2、有利于人才培养模式改进
当前IT企业或自由开发组织均面临一个至关重要的问题,那就是随着信息技术的进步和涉众对应用系统需求的演进所出现的系统开发人才吸纳和培养的模式问题。不管是国外还是国内的高校,在最前沿的系统构建技术培训方面都有滞后性。例如,基于i Phone平台的系统开发、面向云计算的软件组构技术等等,需要软件开发企业或软件开发组织承担起快速培养新生力量的重任。敏捷编程,强调内部协同和软件创作的自由度(重知识、重经验),强调结对编程(传帮带)方法的实践。这种方法非常有利于知识、经验的转移和扩散,有利于培养新手快速的学习和提升。
3、有利于需求变更管理
IBM Rational把软件需求的定义为:“(正在构建的)系统必须符合的条件或具备的功能”。这与IEEE所定义的软件需求类似。需求变更的本质原因是“业务过程再工程”或者业务过程改进,而业务过程改进是永不停止的过程,所以需求的变更是时刻都可能发生的。对需求进行有效的管理,获取、组织并记录系统需求,以及使客户与项目团队对不断变更的系统需求保持一致,从而在需求管理上减少系统开发风险,正是敏捷编程的精髓所在。
4、软件开发的本质是创作
把软件开发过程工程化,是业界的重点期望之一。这种思想关注软件制品的质量。但是软件的开发,除了规范化的要求之外,还有更多的空间是留给开发者去创作,且带有开发者自身强烈的个性色彩。比较典型的例子是对某些问题的求解算法是无法要求千篇一律的。这要结合操作系统,计算机硬件平台,网络平台、编程语言及个人思维定式等等要素去综合考虑。以上要素的不同组合会产生不同的系统运行效率和结果。所以软件开发过程中有创作的成分。过多的和过重的软件过程管理方法,会严重阻碍软件开发人员的创作灵感和工作效率。当然,生产心脏起搏器的公司和生产互联网商业软件的公司所期望达到的应用需求是不同的,管理强度也是不同的。一般来说,大规模的管理信息系统,在开发过程管理上,给开发者的创作空间比较大。这正是敏捷编程思想所关注的问题之一。
基于以上分析,在大型软件项目的建设过程中,引入敏捷编程方法是重要的实践。我们拟采用的方法是:基于一个支持分布式软件开发的支撑平台(工具),并拓展XP的基本属性,改“结对编程”为“多方编程”(人员和过程)和“IRC资源分配”(资源),自动形成基础性软件过程文档(代码和文档),从而完善传统XP在大型项目软件过程管理中存在的先天性不足,保证软件开发元素(团队、资源、过程、代码、文档和工具)的完整性和关联紧密性,从而实现本课题确立的基本目标。我们简称这种过程模型为“XP+”或“XPPlus”。
下面将从构造XP+的分布式模型(宏观模型)和以小组为单位的软件开发团队内部的XP+过程模型(微观模型)两个密不可分的方面来进一步进行讨论。
二、XP+中的分布式开发模型
基于异构组织的分布式开发模型,需要解决两个方面的核心问题:区域自治、资源共享。这包含几个方面的含义:(1)在预定义协议框架内要让协议方(开发团队)“只能”看到应该看到的信息;(2)让协议方看到“所有”应该看到的信息,不能遗漏和缺失;(3)所有协议方最终形成“自治区”和“共享区”,但是以“配置区”(或称为IRC,Information Resource Center即信息资源中心)为核心。配置区中的数据由共享区推送,保证有效的资源隔离,防止不恰当的访问进入到共享区;(4)配置区必须肩负身份认证和授权管理的任务,从而为资源分配建立规则。基于以上几方面的综合分析,本文提出一种分布式的异构组织进行协同系统开发的宏观模型。该模型分为三个区间(自治区、共享区、配置区)、一个核心区域(配置区)N个分支区域(自治区与共享区的搭配区域)。我们称之为XP+的复合气泡模型,如下图所示:
在这个模型中,(1)强调异构组织的业务独立性、资源保护和资源共享,为此必须明确界定其自治区范畴;(2)同时强调业务配置的重要性——这个模型的核心是配置区的功能调用,即资源的调集与分配。这里的资源指配置区提供一个集成的工能集、词汇表、项目建设的资金、人力资源、时间、知识和用于软件开发任务的复杂方法,使业务、软件开发和开发团队整合为一体。这是XP+微观模型的基础。
三、分布式多方编程的过程设计
在XP+的复合气泡模型的基础上,我们来设计微观的支持“多方编程”的过程模型。本质上所有需求都是原型,所有需求的实现都是原型的迭代。这个模型由三个部分组成,首先是用户的需求演进模型,用以产生业务需求和对需求进行迭代,从而驱动软件过程向前推进。用户对系统开发的参与程度随着演进级别的提升逐层增强(而不是原型模型中的逐渐减弱或消失),从而形成充分的业务需求反馈。这是业务驱动开发的基本要求。其次是软件过程模型,在用户需求模型的驱动下完成敏捷的迭代的系统开发过程。这一部分属于共享区的工作内容。第三个部分是配置区的功能集,负责资源的调集、路由和分配。
这个过程模型是“复合气泡模型”微观表现,本质上是一个螺旋的演进的系统模型。从中我们可以发现它吸收了极限编程的敏捷元素。
1、支持业务驱动的开发
我们通过研究发现,要构造一个与业务目标良好匹配的软件开发过程XP+,需要注意三个方面的问题:首先,在利用组件和服务架构的基础上,要着重强调架构;其次,在业务需求和项目管理的基础上,要着重强调基于资源配置的开发;最后,必须拥有一个支持持续的“业务过程再工程”的迭代式开发过程。这样,我们可以获得一个业务驱动的和基于资源配置的软件开发过程。这个过程的核心是配置区的功能调用。通过提供一个集成的工能集、词汇表和用于软件开发的调度方法,使业务、软件开发和开发团队整合为一体。
XP+(配置区)以业务为重点的功能对这个迭代过程进行了优化,这些功能允许从业务的角度对资源需求进行划分优先级,规划如何实现和自动化这些需求,管理实现、测试和部署过程,以及把结果当作输入参数进行度量以谋求持续的改进。
2、用户业务过程优化
用户业务过程的优化会产生新的系统需求。项目管理人员和系统用户需要首先确定演进系统的涉众,并且根据涉众的需求生成更加全面的业务案例,即业务过程中的具体问题的综合描述(按照敏捷联盟的术语,这是“讲故事阶段”),它可能是一个有很大外延的需求集。项目的成功依赖于良好的需求管理,需求管理的根源是业务驱动的用例模型,业务驱动的主要表现形式就是业务用例的可描述性和可跟踪性。这方面的努力还可以解决另外一个方面的问题,那就是确定问题出现的根本原因和对问题本身进行溯源,因为往往一个新的需求产生了,原因不在于这个需求本身,而是整个业务过程改进的结果。否则,无法确定真正的用户需求,软件过程到此就应该停止了。
需要强调一点,“涉众”是一个利益侧重不同的角色集合,也是对客户需求总结的关键。不同的涉众有不同的利益主旨,会产生不同的需求,哪怕是关于应用程序界面这样的非功能性需求。云计算时代,更加强调涉众个性化。系统分析人员仅仅与主要业务人员交谈而获得需求是“一叶障目”,会造成很大的风险。系统分析人员最好的做法是与所有的涉众建立有效的沟通机制,保证与涉众信息交换的通畅[5]。这是配置区的主要任务之一,打破了传统“结对编程”的二人组合,使编程真正的成为了涉众需求的集中体现,也更加符合“敏捷联盟”的精神。
在这个阶段,生成“核心原型系统”是非常必要的。这里需要注意的是,核心原型系统只能解决业务流程中的关键环节,并且可能是多个完成不同功能的原型的简单组合。这个阶段的原型系统的大规模延展,可能会造成后续环节的工作量成倍增长,而且不利于形成需求精简集。另外,虽然涉众是一个很大范围的角色集合,但在这个阶段问题分析的一个关键步骤是确认应用系统的主角。这一切我们称之为工程基础。
这个阶段的结束,会生成一个针对当前案例的综合分析报告(或者诸多卡片),内容包括对涉众的描述,业务过程背景描述,问题出现的案例描述,高度概括的软件需求描述和一些核心功能软件原型。这一切最后形成了“敏捷建模”。这些是软件过程向更高层次进展的基础,具有纲领性意义。
3、敏捷建模
之所以把敏捷建模单独拿出来讨论,在于它的重要意义不亚于XP方法本身。敏捷建模(Agile Modeling,AM)是一种基于实践的过程,它描述了怎样才能够成为一个高效的建模人员。AM是一个轻量级的过程,期望在进行了足够的建模以保证有效地研究和记录系统,但又没有过多地建模以致变成减慢项目进展的负担方面找到平衡点[5]。在XP大行其道的今天,依然有人倡导:“敏捷建模是混乱而有序的”。当开发一个小型的系统,卡片能够解决大部分问题的时候,我们可以借用这个观点(方法),因为要支持需求的多次迭代,所以“对变更及时做出反应高于遵循计划”(传统XP价值观之一)。可是,对于分布式的异构组织的开发团队来说,没有一个事前确定的业务模型,那无异于要进行一场“没有起点只有终点的战争”,注定会失败。
建模是一门专业的学科,与数学与管理学相关。敏捷模型的定义是一个达到了它的目的而且仅此而已的模型;它能够被所有的涉众理解;它简单、足够精确、一致和详细;对创建和维护敏捷模型所做的资源投入为项目提供了积极的价值[3]。一个项目中的敏捷模型的数量与项目的大小和复杂度有关。
4、风险分析过程
正如前面论述的那样,由于当前软件开发的社会环境、组织环境、技术环境等等越来越复杂,变化频繁,各个方面都可能产生意想不到的风险。从概念上讲,“风险是指一个特定的、危险的、不需要的事件在一个规定的时间段内或者在某些环境下发生的可能性。”[4]这些风险对用户和软件开发组织都具有重要的参考意义,甚至是灾难性的。定义软件开发过程的风险,是软件过程向前推进的重要里程碑。
风险管理需要我们不断地评估什么环节可能会出现风险或者造成风险,从而制定应对策略。在我们看来,涉众利益、用户需求、技术需求、工程过程、管理决策、人员流动和政治导向都可能造成风险。在XP+中,项目管理人员将会要求软件开发团队按照提前定义的风险等级来排列风险,然后有针对性地采用风险规避和补救手段。
用户对于风险的评估是非常重要的,特别在项目投资、开发进度和软件性能三个典型风险参考量的预测方面,是开发团队制定系统演进策略的重要的参考依据之一。软件开发的风险策略是一个复杂的管理过程,应该是软件开发过程的一个分支子过程。软件开发团队必须了解,风险管理不仅仅是人力资源的管理,还要考虑更多的外在因素。而且,风险管理需要资金的支持。
5、功能元素的构成
基于敏捷模型而定义系统的输入、输出、应用逻辑、属性和系统环境的属性,就决定了一个完整的需求集合。定义需求的过程是迭代的。它决定了对系统的设计方式和完成的功能,这同时可能产生新的需求。这个过程必须引入“设计约束”的概念,具体的说就是对系统设计过程或开发过程进行必要的限制,从而减少不必要的功能外延。
为保证系统能够按照约定功能,约定成本,约定时间圆满完成,依然需要针对需求集进行考证和剪裁,并生成细化的原型系统。确切定义的需求,我们也称之为“需求精简集”。
这个阶段的用户评审非常重要。用户可以由此知道了最终得到的系统的具体属性,包括界面,操作方法,流程控制和一些注意事项。这个过程也是用户开始学习使用系统,维护系统的过程。
很多软件开发模型都引入结对编程的方法来共享知识和经验,提高软件编码人员的劳动生产率和减少出错率。狭义的说,结对编程就是“两个程序员使用同一台计算机去完成同一项任务”,[5]结对编码可能更加适合基于分布式XP+支撑系统环境下的软件演进开发。辅助编程者不仅仅是“领航员”,更是XP+支撑平台上最佳实践的挖掘者和发现者,同时完成网络环境下与用户的交互任务,澄清有关项目的需求并收集客户的反馈意见,从而及时对代码编写者提供意义重大的参考意见;同时,这个阶段也是形成测试用例的最佳时机。系统全部完成之后测试用例的编写是一个非常复杂和繁重的工作,而在开发过程初期编写测试用例则可以大大减少劳动强度和技术复杂度,并且现场用户可以及时澄清对测试用例的要求。测试用例本身是系统需求的一个组成部分,是系统实现目标的真实体现,所以程序模块必须要保证所有的用例能够百分之百的通过测试。
与用户的交互,可以应用XP+支撑平台,因为那上面已经集成了所有的网络交互功能。所以,在XP+中定义的多方编程,是由用户、业务专家、配置区的技术专家和实际编程人员构成的一种新的编程方式,是结对编程的一种进化。
编程过程会产生开发文档。这些文档会按照既定的格式推送到配置区,成为新的可回溯、可引用、可挖掘、可知识发现的重要资源。
测试活动是软件开发过程的一部分,与所有其他活动一样,应当组织软件开发团队的成员对测试工作进行规划、设计、实现和执行。用户参与编码和测试,生成用例测试文档和评审依据。这样才能产生“正确的软件产品”。同时,用户有大量的机会根据需要对需求进行更加精确的确认。这是XP+与其它线性模型和CMMI等传统开发方法最大的区别之一。
6、软件功能组合
软件功能组合是这个微观模型中的最高层次。在面向服务的软件开发过程中,基于功能模块组构新的应用软件将会越来越普遍。当所有的工件全部完成,或者部分可运行工件已经完成(以完成单元测试为标志),配置区就可以协同相关小组进行系统的组装。这期间可能会产生新的边缘需求。配置区会对开发任务进行一次重新分发。这容易被认为是一次迭代,也可能被理解成是做一个框架,把所有软件制品全部组合起来。但是从我们的工作经验和研究过程来看,这更多是一次真正的开发,就像开发一种粘合剂,把所有的制品全部粘合在一起一样。这种开发强调的是功能内部的衔接和调用来满足用户的需求。
这个阶段发生迭代或者重构(Re-factoring)的可能性非常大。重构的含义是:改善代码的内部结构但不破坏其外部行为的正式的编程过程。事实上,在编码的初期阶段,往往为了最快速的体现客户需求,从而简化代码的编写。简化代码所必须付出的代价是系统功能的不稳定和不完善,例如当表单中的数据已经被修改,客户在随意关闭表单的情况下系统不能给与必要的提示或不能进行自动数据保存,等等。建模的意义在于迭代或者重构的时候有章可循,特别是大规模的异步开发,没有恰当的建模或者缺少文档的支持,这个阶段的迭代或重构几乎是毁灭性的。
四、XP+模型的实现
随着世界范围内各种云计算平台建设,为涉众需求的聚集、信息资源的集约应用、应用软件的统一管理提供了新的机会,基于分布式环境的网络协同开发将逐步盛行。各种应用(Saa S,软件即服务)如雨后春笋涌现出来,而各开发团队属于不同的法人主体,并且居于不同的地域空间和管理制度下,在合作方面需要一个相对稳定而且优化的过程管理机制。这种异构组织的项目合作与应用技术开发,正是XP+的应用领域。
首先,需要确定和构建一个基于广域网络的分布式开发平台。它是XP+的配置区域,负责信息资源的调集、路由与分配,同时负责合作项目的配置管理。
其次,每个法人主体作为一个“自治区域”,都要划定一个逻辑上的“共享区域”,从而把需要共享和推送到配置区的软件代码、过程文档等软件制品放到共享区,并对共享区进行协议控制。这样就保证了“区域自治、资源共享”原则的有效实现。
在软件开发组织多方共建信息化项目的微观过程控制方面,即需要保证过程管理的“敏捷”属性(不能因需求变动及过程管理的复杂度而降低项目的可操作性及阻碍项目进度),充分发挥各方的人才优势和技术优势,又不能使项目管理失去协调统一的控制,从而增加项目的大规模迭代,所以需要XP+微观模型对各方共建信息化项目进行过程管理和改进。
五、结束语
软件开发组织要采用什么样的软件过程模型,与具体的项目类型和开发团队的组织形式相关。当前在面向以云计算为代表的大型分布运行系统的异构组织开发方法或者过程管理模型方面,软件工程领域并没有一个很好的解决方案,这方面的研究也刚刚兴起。本文从宏观模型和微观模型两个方面提出了一种解决方案。
摘要：面向分布运行的大规模信息化项目,支持基于广域网络的协同开发团队,规避软件过程风险,确立在需求演进状态下实现“业务驱动开发”的软件过程管理模型,是软件工程领域的重要课题。我们采用的方法是:基于一个支持分布式软件开发的支撑平台,并拓展XP的基本属性,改“结对编程”为“分布式编程”和“IRC资源分配”,从而完善传统XP存在的先天性不足,保证软件开发元素的完整性和关联紧密性,提高了系统开发效率和软件制品质量。
关键词：软件过程,XP,结对编程,业务驱动开发
参考文献
[1]Gary Pollice,Liz Augustine,Chris Lowe等,小型团队软件开发:以RUP为中心的方法[M].宋锐等译.北京:中国电力出版社,2004.8.
[2]奉继承,云计算与软件工程,四方国件中间件产业技术创新联盟网站,网络连接:http://www.orientware.org/viewArticles.do?action=browse&columnId=27&id=32&flag=home,2011年3月2日.
[3]Scott W.Ambler,敏捷建模:极限编程和统一过程的有效实践[M].张嘉路等译.北京:机械工业出版社,2003年4月.
[4]Pierre N.Robillard,Philippe Kruchten,Patrick d’Astous,软件工程过程[M],施平安译,清华大学出版社,2003,北京.
分布式软件 篇5
关键词：分布式电源,综合经济效益,软件设计开发
1 引言
分布式电源就近接入、直接向用户供电有利于降低输配电损耗、延缓电网投资、节能降耗、减少污染等, 将带来良好的经济社会效益。但是, 分布式电源开发建设需要较大的初始投资, 同时高渗透率接入电网也可能带来电网改造成本和限电损失等。因此, 科学定量评估分布式电源接入配电网带来的各项成本和效益, 可以为分布式电源优化规划提供科学依据[1]。
2 分布式电源接入的综合经济效益分析
2.1 经济效益分析基本方法
综合经济效益分析的方法主要有如下三种方法, 各有各的特点, 具有不同的适用性。
(1) 净现值法
净现值法是一种比较科学也比较简便的投资方案评价方法。利用净现金效益量的总现值与净现金投资量算出净现值, 然后根据净现值的大小来评价投资方案。
(2) 现值指数法
现值指数法通过计算比较现值指数指标判断决策方案好坏的方法。现值指数是指未来收益的现值总额和初始投资现值总额之比。
(3) 内部收益率法
内部收益率是指能够使未来现金流入现值等于未来现金流出现值的贴现率。内部收益率法是根据方案本身项目收益率来评价方案优劣的一种方法。项目收益率大于资金成本率则方案可行, 且项目收益率越高方案越优。
2.2 分布式电源接入的综合经济效益
考虑到分布式电源接入带来的综合经济效益涉及项目业主、电网企业和社会等, 不属于同一个主体, 且相互之间存在关系, 结合各种经济效益分析方法的特点, 本文采用净现值法对分布式电源接入的综合经济效益进行分析。分布式电源接入配电网的综合经济效益为:
式中, BCF为分布式光伏发电接入带来的综合经济效益;Cg为项目初投资成本;Cr为分布式光伏接入引起的电网改造成本;Com为维护成本;cC为限电损失;Binv为延缓系统投资收益;Bloss为降低系统损耗收益;Benergy为节能效益;Benviroment为环境收益[2], Bsell为发电量收益, 上述成本和效益均为等年值。
2.3 综合经济效益分析流程
综合经济效益分析的基本思路是:对含分布式电源的配电网进行年度8760小时潮流计算, 得到各个时点的运行状态, 以此为基础, 分析各个时点的限电量, 以及年度的各项成本效益。考虑到各项成本效益与电网年度运行状态有关, 本文提出了基于年度8760小时网络运行状态的成本效益分析方法, 流程图见图1。
3 分布式电源接入综合经济效益分析软件设计和实现
3.1 软件框架
分布式电源接入的综合经济效益分析软件 (Comprehensive Economic Analysis of Distributed Generation, 简称Cea DG) 的技术层次包括基础数据、基础应用和集成应用等, 见图2所示。
(1) 基础数据部分
用于综合经济效益分析软件计算所用的基础数据。主要包括电源、电网、负荷、价格数据和案例库。将常用数据内置在程序里, 对一些需要进行变化的数据采用自定义文件方式, 由程序读取。
(2) 基础应用部分
用于实现基本功能和算法, 以供集成应用进行调用, 实现具体的应用功能。主要包括技术分析、优化分析及第三方软件接口等功能。第三方软件可以实现矩阵稀疏、数学规划算法、智能优化算法调用等功能。
(3) 集成应用部分
将基础数据和基础应用进行整合, 实现具体的应用功能。分布式电源接入的综合经济效益分析软件中主要是指基于电网年度运行状态计算包括项目本体成本、接网成本、电网改造成本、降损效益、延缓电网投资效益、节能效益、环境效益等。
结合分布式电源接入的综合经济效益分析软件层次结构分析, 提出软件框架, 主要包括基础数据部分、基础应用部分、集成应用部分和输入输出等四大部分, 见图3所示。
3.2 软件设计
分布式电源接入的综合经济效益分析涉及大量的数据和应用模块。考虑到随着软件的开发, 不仅可实现电力系统稳态分析和优化分析等高级功能, 还可以更高效的实现分布式电源相关数据和分析方法的归集整合, 并进行发掘提升, 基于已有模块开发更多高级应用模块。因此, 需要在数据和模块方面具有较强的可扩展性。
(1) 数据部分的设计
数据类具有繁杂分散、结构多样性的特点, 且和输入输出类有较大的耦合关系, 考虑到两者的解耦, 设计了两者的接口原则。在接口原则确定的基础上, 按照开放的原则设计数据类, 可以自由的加入和完善, 而对输入输出类进行适当的封闭。
考虑到提高软件使用的友好程度, 兼顾灵活性, 将通常不会改变、且使用者可能难以获取的数据直接纳入源代码作为变量进行管理, 从而加快输入数据的读取和运行速度, 但同时也开放了部分数据, 允许软件使用者在输入文件中对这部分数据进行重写, 最大限度方便软件使用者。
(2) 应用部分的设计
考虑到各类应用的相对独立, 各个应用类的设计相互耦合度较小, 可以独立开发并扩展, 技术分析类、经济分析类和优化方法类是基础应用类, 并且是可以自由扩展, 例如可以采用其他优化算法或者调用潮流计算库等, 减小了代码的开发量和维护量, 集成应用类是综合功能类, 它也是可以扩展的。
数据类、输入输出类、基础应用类、集成应用类的良好扩展性, 可以使得软件按照设计目标的类别, 将各种类结构重新集成可实现新的目标, 原有的数据类和应用类可以被继续复用, 使软件工程成为可继承的事件, 有助于提高软件开发效率。
3.3 软件模块
目前分布式电源接入电网的综合经济效益分析软件主要包括输入输出、电力系统潮流计算、优化算法、综合经济效益分析等功能模块。
(1) 输入输出功能模块
软件输入支持自定义数据格式和外部软件输入格式。自定义数据格式为文本类型, 用户在按照约定格式输入参数后, 软件也会按照约定进行参数读取, 并存入统一的参数容器。在具体的功能模块调用时会进行相应数据的抽取。外部软件输入格式主要由外部软件支持格式决定, 其中包括CSV格式。
软件输出支持文本输出、plot预览输出、外置软件直接输出、excel输出。文本输出和文本输入类似, 都是约定的数据格式进行输出。Cea DG软件支持三种数据输出, 分别是各省数据、24小时数据和8760小时数据, 将根据类型自动选择。Plot预览输出主要是调用了外部软件, 直接对数据文件进行读取画图, 便于直接观察数据结果, 见图4所示。外置软件输出类似于外部软件输入格式, 主要是由调用的第三方软件所支持的输出形式支持。Excel输入输出, 主要是采用excel将各省数据、24小时数据和8760小时数据进行输出, 相对文本格式具有方便后期处理、分析和画图的优点。
(2) 电力系统计算模块
针对给定配电网和分布式电源参数, 对含分布式电源的整个电力系统进行电网潮流计算和短路电流计算, 得到电网的运行状态, 为后续经济分析提供网络运行状态数据。
(3) 优化分析模块
目前主要是实现粒子群优化算法和遗传优化算法, 为后续优化求解提供功能支持。
(4) 第三方软件接口模块
主要实现调用外部矩阵稀疏、预览软件等功能。
(5) 综合经济效益分析模块
主要基于电力系统分析模块, 得到分布式电源接入的综合经济效益, 包括项目本体成本、接网成本、电网改造成本、延缓电网投资效益、降损效益等成本和效益的计算。
3.4 软件流程
Cea DG的软件计算流程如图5所示。
首先是读取数据文件。通过输入输出模块对自定义输入文件进行读取, 利用电力系统分析模块对电网案例库读取电网结构数据。读取过程中会对文件进行校核, 如果发现格式错误会自动报错, 给出提示信息。
其次进行电力系统潮流计算。电力系统分析模块按照给定的单点、典型日24小时和年度8760小时要求, 进行电力系统潮流计算, 并在电网运行出现电压越限和电流过载时, 按照既定控制策略, 对分布式电源进行限电处理, 记录各个时间点的电网运行状态。
然后进行综合经济效益分析。基于网络运行状态, 调用基础数据模块里的价格数据, 按照项目本体成本、接网成本、电网改造成本、延缓电网投资效益、降损效益等成本和效益的计算公式, 对相关的成本和效益进行综合分析。
最后进行结果输出与显示。它可以根据不同的数据格式提供灵活和可扩展的数据输出并显示。
3.5 软件实现
(1) 软件实现基本原则
考虑到分布式电源接入综合分析软件具有较强的基础性和通用性, 未来课题组需要针对新问题新要求, 在此软件基础上进行后续开发, 满足其他研究需求, 因此, 软件实现考虑如下两个原则:
一是自主开发。实现功能的完全定制和升级维护, 满足自主需求;自主开发有利于避免外委时在设计、开发、测试等各阶段的沟通协调时间。
二是严格执行大型软件项目标准:提高软件健壮性、灵活性、可扩展性和开放性。
(2) 软件开发语言和环境
C++是一种面向对象程序设计语言, 具有封装、继承和多态的特性。C++语言具有灵活、准确、功能强大等特点。正是基于这些特性, 分布式电源接入的综合经济效益分析软件采用C++语言和面向对象方法加以实现。编程工具采用微软公司推出的Visual Studio 2013, 是目前最流行的Windows平台应用程序开发环境。
4 结语
本文针对分布式电源接入的综合经济分析问题, 结合分析方法特点和需求, 提出了分布式电源接入综合经济效益分析软件的设计开发方案, 可实现对分布式电源接入配电网后综合经济效益的科学定量评估, 并且具备良好的通用性和扩展性, 可在此平台基础上进行更全面、更深入的分析功能的开发。
参考文献
[1]王成山, 陈恺, 谢莹华, 等.配电网扩展规划中分布式电源的选址和定容[J].电力系统自动化, 2006, 30 (3) :38-43.
分布式软件 篇6
目前, 中航工业试飞中心开发的基于C/S, B/S架构体系的飞行试验数据网络处理系统 (FTDPS) 已经解决了海量试飞数据的分布式存储及计算问题[1], 并在重点型号任务的试飞过程中发挥着重要作用。该系统可以处理PCM数据和FCS数据[2], 1553B数据仍然采用单机版处理。随着飞行试验中参试飞机飞行时间、测试参数的不断增加, 总线数据量剧增, 同时试飞工程师的参数处理需求更加多样, 采用现行1553B数据处理方法给每位试飞工程师拷贝数据、处理数据、发送结果等过程耗时达到数小时, 已经严重影响数据处理效率和型号试飞进度。针对这一问题, 本文开发了基于分布式网络的1553B数据处理软件, 使得课题人员在FTDPS的平台上可以根据任务所需个性化定制处理参数、处理时间段及飞行架次等课目。工程实践表明, 本软件极大地提高飞行试验数据的处理效率, 满足了多用户并行处理需求, 保证了型号试飞任务进度。
1 ORACLE数据库设计
单机版的1553B数据处理系统由ICD信息数据库[3]和处理软件2部分组成。将1553B数据处理系统以分布式中间件的形式嵌入到FTDPS系统中, 首要的工作就是在FTDPS的数据库中设计并增加新的ICD信息的ORA- CLE数据库, 完成1553B数据处理系统数据库的网络化升级, 文献[4]已经将ORACLE数据库设计完成, 数据库总体设计如图1所示, 为本文实现与FTDPS的输入输出接口工作, 开发1553B数据处理中间件做好了准备工作。
2 1553B数据处理中间件设计
2.1软件接口设计
开发FTDPS的数据处理中间件, 本软件首先应保证总线参数名称的一致性, 其次要满足系统标准的输入输出接口要求[5]。
2.1.1参数名一致性
参数名称必须能够写入FTDPS数据库的TESTIN-SIDEPARAINFO表中, 测试系统名称为Mini700, 测试数据属性为1553B。参数名称是数据库表的主键, 要求具有惟一性的特点;为了方便用户在浏览器端选择要处理的参数, 参数命名也要符合总线参数特点, 易于用户识别。因此在ICD文件中, 选择总线信号名的规范名称作为数据库中的参数名, 例如A/M1IR/00-00-00, 可以满足参数名称惟一性和易于专业人员识别的需求, 如图2所示。
2.1.2软件接口统一
作为FTDPS的中间件, 标准接口有2个要求:
(1) 软件必须为可执行文件.exe, 带有一个命令行参数, 命令行参数为一个接口文件的名称;
(2) 命令行参数所指的接口文件必须是文本文件格式。所以软件接口统一的工作实质是把原处理程序改写为CONSOLE APPLICATION控制台应用程序, 完成读取图3所示的接口文件, 然后按照FTDPS的输出格式输出。本文以Delphi7.0为软件开发工具[6], 控制台程序关键代码如下:
2.2系统调用软件流程
1553B数据处理软件以分布式中间件的形式嵌入到FTDPS系统中, 按照已约定好的内部接口和整个数据处理系统之间协调通信, 有效快速地进行数据处理, 并准确地将结果信息返回给数据处理系统。客户端计算机需要安装分布式计算Active控件, 主要完成的功能为向系统发出计算请求、与1553B数据处理中间件之间进行信息通信、监控计算过程的状态、接收系统返回的数据。FTDPS系统调用1553B数据处理中间件流程如下:
(1) 客户端计算机 (B端) 首先向调度服务器发出数据处理申请, 同时生成B端接口文件, 调度服务器指定某台分布式计算服务器进行计算;
(2) 计算服务器调用1553B数据处理中间件, 访问存储在磁盘阵列上的原始总线数据文件进行解析计算, 同时将状态信息输出到控制台, 客户端Active X控件通过接口协议捕获并以界面的形式显示给用户。并输出标准格式的文件;
(3) 计算结束后, 结果文件通过Socket方式回传到用户客户端的Active X控件安装目录下。
图4展示了1553B数据处理中间件在FTDPS中的调用流程。图5是客户端Active X控件显示的软件运行状态示意图。其中*.eng文件为LST工程量文件;*.cod为文本文件, 用户可以直接打开2种文件类型进行分析。*.inf文件是FTDPS的接口文件, *.sta文件为本次计算过程的状态文件。
2.3软件设计
根据FTDPS系统调用1553B数据处理中间件的流程, 设计软件的算法如下:
(1) 获取接口文件名称后, 解析接口文件协议, 获取软件要处理的参数、时间段信息, 以及结果文件存放位置等信息;
(2) 访问ORACLE数据库中的ICD数据库, 把所有参数相关的信息读取到结构体数组中;
(3) 读取总线数据文件的时间信息;
(4) 读取处理时间段内总线数据文件中的消息块信息, 与数据库中读取的关键字逐一进行判断, 若相等则表示找到数据中此参数的信息。然后根据MIL-STD-1553B (GJB289A) 数据总线标准[7]中的总线消息收发标准进行计算、解析;同时将数据的时间等计算状态信息输出至控制台;
(5) 根据接口文件协议, 将结果文件传送到服务器指定的存放位置。
算法流程图如图6所示。
3结论
飞行试验数据网络处理系统 (FTDPS) 在型号试飞中发挥着重要作用, 1553B数据处理中间件又是该系统中极为关键的子软件。1553B数据处理软件采用基于Web的分布式中间件技术, 将数据处理软件做成标准化的分布式中间件, 通过标准的接口协议成功地嵌入到FTDPS系统中。本文开发的软件作为FTDPS的1553B数据处理软件, 已经用于某型号4架飞机的飞行试验总线数据处理, 运行情况良好, 数据处理效率满足了海量试飞数据处理的需求, 保障了试飞数据及时高效的处理。
摘要：为了解决当前1553B数据处理单机软件制约海量数据情况下多课题并行处理效率的现状, 在此采用基于Web的分布式中间件技术, 将1553B数据处理软件开发成基于分布式网络的标准数据处理中间件。为保持参数名的惟一性, 以ICD文件中的消息规范名为数据库中的参数名称, 并且编写了该软件与飞行试验数据网络处理系统 (FTDPS) 的标准数据接口文件, 根据分布式中间件的调用流程设计了相应的算法, 最终实现100%1553B数据的网络化并行处理, 极大地提高了总线数据处理效率。
关键词：1553B数据,接口文件,分布式网络,数据处理软件
参考文献
[1]王建军, 党怀义.基于Web的分布式试飞数据处理系统结构设计[J].计算机测量与控制, 2010, 18 (6) :1452-1454.
[2]张阿莉, 许应康, 郭永林.飞行控制总线数据网络化处理软件设计[J].现代电子技术, 2013, 36 (10) :37-39, 44.
[3]夏庆梅, 徐亚军, 熊华刚.航空电子接口控制文件的数据库管理[J].航空计算技术, 2001, 31 (3) :39-40.
[4]刘威, 周嫦娥.1553B网络数据处理系统数据库优化设计[C]//航空试验测试技术交流会议论文集.北京:《测控技术》杂志社, 2011:97-99.
[5]党怀义.ARJ21飞机试飞数据处理系统软件详细设计说明[M].西安:飞行试验研究院, 2006.
[6]周果宏, 罗述谦, 罗起.Delphi程序设计题解、编程技巧与疑难解答[M].2版.北京:清华大学出版社, 2007.
[7]国防科学技术工业委员会.数字式时分制指令/响应型多路传输数据总线[M].北京:国防科学技术工业委员会, 1998.
分布式软件 篇7
当前国内外电网的调度控制仍然采用以调度中心为主导的集中式调度模式,变电站只是被动的信息采集和控制执行机构。多年来国内外的电网运行经验和大量电力事故的发生,表明传统集中式调度模式存在以下问题。
1)基础数据的准确性问题。主要表现为时常有拓扑错误和量测坏数据出现,严重时导致状态估计不可用或不可信,进而降低了电网运行人员对电网运行状态的判断和控制能力[1]。
2)敏捷性不足。在以下两个环节将产生延时: 1遥测、遥信的上行通信延时,遥控、遥调的下行通信延时;2大规模全局电网分析决策的计算耗时。这些延时有时将导致决策控制难以取得理想的效果,特别是无法满足紧急情况下的调度控制要求。美加“8·14”等国内外大停电事故表明,电网需要有更快的事故响应能力[2]。
3)集中维护负担重。对大规模电网,调度中心维护图形和模型的负担很大,而且容易出错,一旦出错,还难以诊断。如果能利用变电站已经建好的图模,在调度中心自动完成拼接,则可支持调度中心图模的免维护或低维护。
另一方面,数字化变电站[3]实现了站内设备互操作,包括测控 装置、相量测 量单元 (phasor measurement unit,PMU)、保护装置、录波装置在内的大量智能装置的信息可以被方便地建模和采集, 为变电站智能化铺平了道路。
2009年国家电网公司提出了建设坚强智能电网的愿景[4]。为了适应可再生能源的强波动性和保证智能电网运行的高可靠性,电网运行调度体系开始从集中式向分布式方向发展[5]。一个重要的方向就是向变电站发展。如何发挥变电站本地信息的冗余性和本地决策的敏捷性优势,提高变电站为电网调度控制服务的智能性,是国际上智能变电站发展的重要趋势[6]。包括笔者研究团队在内的国内外多位学者已对变电站高级应用进行了深入研究和局部示范。2008年,美国New York电力公司 和美国Entergy电力公司分别与Georgia理工大学开始合作,分别以两个相邻变电站作为示范,研究和实施变电站状态估计的示范工程[7]。2009年,清华大学提出了基于零阻抗支路模型的变电站三相非线性状态估计方法[8],并在华东电网进行示范应用,取得了良好效果[9]。2011年,华南理工大学与江西省电力公司合作,在兴国数 字化变电 站实施变 电站智能 告警[10]。
综上所述,应对“分布自治”与“集中协调”进行合理平衡,变目前的集中式调度模式为集中与分布相协调的变电站—调度中心两级分布式智能调度控制模式,其基础是建立变电站高级应用软件体系。
本文提出了完整的变电站高级应用软件体系架构和功能实现,并对其中的部分应用进行了工程实践。与传统的集中式调度模式相比,变电站高级应用软件可以在不明显增加变电站与调度中心间通信量的情况下,显著提升上送调度中心的基础数据的准确性和有效性,增强相关控制功能的可靠性和敏捷性,并支持控制中心的分布式容灾和自愈,使变电站自动化系统真正成为调度体系中的站级智能体, 实现纵向贯通。
1 变电站高级应用软件体系
本文提出的变电站高级应用软件的体系结构如图1所示,这里的变电站属于广义的变电站,包括电厂的变电站部分、常规变电站、风/光等可再生能源发电场升压站等,在变电站一体化标准化信息集成平台的基础上,包含分布式建模、分布式状态估计、分布式智能告警、分布式电压稳定评估与控制、分布式自动电压控制(AVC)、分布式风险评估建模等应用。
上述各项变电站高级应用在调度中心都有较为成熟的对应功能。如果将调度中心的能量管理系统看做电网运行控制的“大脑”,那么在变电站安装高级应用软件便可以看做电网运行控制的“小脑”。对其开展研究的主要技术挑战在于,如何处理好“分布自治”和“集中协调”这一对矛盾,使得一方面可以利用变电站本地的冗余信息实现可靠、敏捷的自治分析决策,另一方面向上级控制中心提供经过本地分析处理的适量“熟数据”,并接收上级控制中心协调指令,从而提升对整个电网调度控制的可靠性和敏捷性。由于变电站网络的特殊性,传统调度控制中心的高级应用软件无法直接应用到变电站之中。
2 变电站高级应用软件
下面分别对各变电站高级应用的功能、特点和算法进行简要介绍。
2.1 变电站分布式建模
与IEC 61850及其他变电站自动化标准所规定的为变电站通信提供支持的信息模型不同,这里的分布式建模指的是基于变电站一体化标准化信息平台,建立为变电站高级应用提供支持的信息模型。 该模型具体又包括一次模型[11]和二次模型[12]。一次模型描述站内一次设备的拓扑连接和特性参数, 量测模型由于与拓扑和状态估计应用联系紧密,所以也归入一次模型;二次模型描述站内监控、保护、录波等设备的功能和配置。变电站的模型应支持导出,导出的各个站的模型在调度中心通过拼接形成全网的模型,供调度中心的高级应用使用,从而实现模型的源端维护。
变电站具有比调度中心更详细的一次模型。变电站采用的是三相的网络模型,具备三相量测,包括开关上的三相量测和三相分合信号,此外还包含接地刀闸、互感器、站用变压器等设备。该一次模型在导出时应进行转化以满足调度中心模型的要求。而传统调度中心对保护设备的建模比较薄弱,所以二次模型以IEC 61850标准中的保护模 型为基础 建立。考虑到包括智能告警在内的高级应用对二次模型的需求,在IEC 61850模型的基础上添加了对各保护逻辑节点保护属性的分类描述,并忽略大量通信相关的逻辑节点。表1具体描述了变电站与调度中心量测和保护模型的区别。
注:√表示含有;×表示不含有。
表1中:Vp和Vl分别为电 压单相值 和线值; VAB为AB线电压;Ip为电流单相值;PΣ,QΣ分别为有功和无功功率三相总加值;T为变压器挡位;Scp 和Sop分别为分相合位置和分相开位置;Sc和So分别为合位置和开位置;Sg表示总位置。
2.2 变电站分布式状态估计
进行分布式状态估计的目的在于,利用变电站内高冗余的量测配置,剔除站内的拓扑错误和坏量测,提升基础数据的准确性,并将熟数据上送至调度中心。
与传统的电网节点支路模型不同,变电站内的网络主要由零阻抗支路(开关支路)构成。所以传统的状态估计方法无法直接应用。为此,提出了一种基于基尔霍夫电流定律(KCL)的变电站三相非线性状态估计方法[8]。与调度中心采用节点复电压为状态变量不同,变电站中以各零阻抗支路的三相复功率为状态量,建立非线性量测方程,可以同时考虑远程终端单元(RTU)和PMU两种量测来源,同步辨识拓扑错误、坏量测及三相不平衡。
分布式状态估计流程图如图2所示。以变压器为分界点,划分电压等级,基于KCL对各电压等级下的三相量测数据建立量测方程。根据开关状态形成开关岛,在开关岛内进行三相零阻抗电压状态估计和功率状态估计,再根据估计结果剔除模拟量坏数据,计算三相不平衡度,并判断开关的真实开合状态。分布式状态估计结束后,变电站将估计后的熟数据上传给调度中心存储和使用。
2.3 变电站分布式智能告警
进行分布式智能告警的目的在于,利用变电站本地在 故障前后 的冗余告 警信息 (测控、保护、PMU、录波等),进行可靠、快速的站内告警,并将诊断结论上送调度中心。
将分布式智能告警分成基于告警信号的快速故障诊断和基于模拟波形的详细故障诊断两个步骤 (见图3)。快速故障诊断采集一个时间窗内的事件顺序记录(SOE)告警,并基于变电站保护模型建立包含这些告警信号的因果网络,采用溯因推理的方式诊断 故障设备 和故障类 型,并形成故 障事件树[13]。同时,以快速故障诊断的结果为触发,采集对应设备的录波文件,采用相量启发式检测与小波变换相结合的方法对模拟波形进行突变量识别,提取故障事件、故障过程和故障类型[14]。将快速故障诊断和详细故障诊断的结果合并,上送调度中心。
2.4 变电站分布式电压稳定评估与控制
集中式的静态电压稳定的评估方法依赖系统网络模型。但由于参数的不准确或外网建模的困难, 导致准确的系统网络模型难以获得,且评估计算耗时长。分布式静态电压稳定评估方法仅 依靠本地PMU实时量测进行戴维南等值,不依赖于网络模型,具有高敏捷性优势。其难点在于,本地等值的线性模型难以准确表征时变的网络模型,从而使得分布式的电压稳定裕度结果不够准确。为此,提出一种本地级—系统级两级分布式电压评估方法[15],利用本地级分布自治的特点完成电压稳定可信性评估和时变等值参数模型的辨识,将辨识得到的等值内阻抗和等值内电势结果上传系统级;系统级利用全网负荷增长情况信息,在不依赖于网络拓扑的基础上,经过负荷转移阻抗辨识、崩溃点时刻求解和崩溃点时刻模型参数计算等步骤后,得到修正后准确的崩溃点时刻的等值内阻抗和等值内电势,下传给本地级计算准确的本地电压稳定裕度结果,如图4所示。图中:VFFRLS表示可变遗忘因子递推最小二乘方法。
相较于集中式的静态电压稳定控制方法,分布式静态电压稳定控制方法同样具有本地决策的敏捷性优势,但是由于缺乏协调会出现控制不解耦问题, 即本地的电压稳定水平表现结果与内网其他负荷的增长存在关联,所以本地难以给出独立解耦的控制门槛值和控制量。为此,提出一种本地级—系统级两级分布式电压稳定控制方法[15]。系统级利用各地负荷增长速度和重要性的信息制定协调整定值下发给本地级,作为本地分布自治的电压稳定控制器的参数。本地级电压稳定控制器在依据系统级协调的整定参数的基础上,根据本地实时裕度结果计算出控制时延和控制量,从而实现各个本地控制器的协同解耦控制(见图4)。
2.5 变电站分布式 AVC
集中式AVC的控制策略(发电机无功出力、电容电抗器的投切、分头的调节)均由控制中心给出, 下发给变电站侧设备执行,其风险过于集中,操作安全性和可靠性考虑不足;此外,变电站的电压无功控制(VQC)已处于淘汰边缘。
分布式AVC中,控制中心给出的控制策略不 再具体到每个设备的动作,而是给出一个变电站整体的无功资源投切量,让变电站子站端去决策具体动作哪些设备来达到控制中心的要求。在此之前, 子站必须及时将当前可操作的无功资源统计提供给控制中心作为控制策略的约束。
子站端的分布式AVC的控制流程图见图5。
根据电网当前的运行方式,形成控制单元。若单元不可控,AVC系统闭锁该控制单元的自动控制并告警。接下来依次判断母线电压是否合格、无功功率是否合理,若存在不合格或不合理,则控制无功设备和变压器分接头进行消除。在电压合格和无功功率合格的情况下,考虑高压侧的电压优化策略。高压侧的优化电压设定值采用全局无功优化计算给出的电压设定值,如果全局无功优化计算不可用(计算失败),则采用人工给定的优化曲线值。
2.6 分布式风险评估建模
进行分布式风险评估的目的在于,利用变电站重要设备的状态监测信息构建设备停运模型并上传至调度中心,根据当前设备实时运行工况对未来电力系统运行风险进行合理评估。
在传统电力系统中,风险评估为集中式模式,调度中心侧计算预想故障概率时采用的数据为长期历史统计数据,由此得出的风险指标难以反映当前设备实时运行工况。而分布式风险评估的实施分为调度中心层和变电站层两个层面[16]。在变电站层,基于厂站侧各类关键电力设备的状态监测数据,生成反映电力设备当前运行工况的停运模型并上传至调度中心,在调度中心层,调度中心收集各厂站上传的设备停运模型,采用状态枚举法给出系统主要预想故障列表及其发生概率,并计算系统未来一段时间内的风险指标,根据风险指标做出决策并下发给变电站。这种变电站层和调度中心层紧密互动的风险评估模式,既发挥了变电站侧的数据优势,也发挥了调度中心侧的计算优势,以设备停运模型为纽带,避免了变电站侧状态监测数据的大规模传输,同时调度中心侧可以实时掌握变电站侧设备运行工况。分布式风险评估模式如图6所示。
3 应用示例
以上介绍的各项高级应用都已由笔者的研究团队完成软件研发和实验室测试,部分功能已经在实际电网得到应用。下面以分布式建模和状态估计、智能告警为例,介绍应用情况。
3.1 分布式建模和状态估计
基于本文方法开发的分布式建模和状态估计功能已在华 东、湖北、重庆、深圳 等电网公 司下辖的6个厂站投入实际运行,2个厂站完成离线测试,并与南京南瑞继保电气有限公司、北京四方继保自动化股份有限公司和许继集团有限公司实现了内嵌式开发。该算法的有效性和软件系统的可靠性已经过 充分验证。该系统的软件功能模块如图7所示。
以220kV中航变电站为例进行蒙特卡洛仿真实验,验证状态估计的统计效果。表2给出了变电站状态估计前、后坏数据个数占遥测或遥信总数的比例,其中遥信 坏数据个 数比例下 降为原比 例的7.619%左右,遥测坏数据个数比例下降为原比例的9.268%左右。可见,分布式状态估计能够显著减少坏数据个数。分布式状态估计的时间指标如下:繁昌变电站为23.8ms,由拳变电站为10.9ms,宿州电厂为5.2ms,当涂变电站为17.3ms,完全满足数据采集与监控(SCADA)系统的时间要求。
3.2 分布式智能告警
基于本文方法开发的分布式智能告警系统已在湖北电网纪南220kV智能变电站投入测试运行。以2013年1月18日发生的枝纪线B相单线接地短路的故障数据为例进行测试。表3为综合自动化平台接收的SOE告警信号。故障相电流录波图见附录A图A1,附录A图A2是智能告警系统自动收集SOE和录波信息进行诊断后得出的诊断简报。可以看到,诊断结果准确,并且提供了故障元件、故障时间、故障相别、正确告警、误告警、漏告警、重合闸情况和时间等丰富的告警信息。
4 实用化问题探讨
4.1 标准化问题
智能变电站高级应用软件在开发过程中严格遵循电力系统自动化的相关标准,满足与调度控制平台和综合自动化后台的良好兼容性。例如,分布式建模应用在变电站侧依据IEC 61850标准对变电站的一、二次设备进行建模,并依据IEC 61970标准对一次模型进行了补充。建成后的变电站模型和图形可以分别精简并导出为变电站配置描述(SCD)模型文件和可缩放矢量图形(SVG)文件;调度中心侧接收并解析来自智能变电站的SCD文件后,与调度中心的公共信息模型/可扩展标记语言 (CIM/XML) 文件拼接生成新的完整的CIM文件。考虑到CIM/ XML与公共信息模型/E语言(CIM/E)文件可以相互转化[17,18],导出的变 电站模型 也可以转 化成CIM/E格式[19]。此外,变电站分布式 状态估计 和智能告警等应用使用IEC 60870-5-104协议向调度中心上传实时数据。
4.2 外挂式/嵌入式模式
智能变电站高级应用软件的实现可采用外挂式和嵌入式两种模式。外挂式模式需在调度中心和变电站单独设置工作站,构成独立系统,其优点是开发方便,缺点是维护成本较高,站内通信量较大;嵌入式模式是指将各项高级应用嵌入综合自动化后台或远动机,其优点是维护方便、功能简单、通信量小,缺点是需要综合自动化平台厂家开放接口,并进行联合开发。
4.3 对 PMU 量测的需求
国内的500kV变电站及部分220kV变电站已配备了PMU量测。在智能变电站高级应用软件中,分布式电压 稳定评估 与控制要 求站内配 置有PMU量测,其他应用并无明确要求。对于分布 式状态估计,PMU量测可以提高量测数据的精度和冗余度,但对于未配置PMU量测的站,也可仅利用RTU三相量测进行估计。
4.4 维护难度
智能变电站高级应用软件虽然不要求变电站有人值守,但是还难以做到完全的免维护,主要原因在于各项高级应用软件对变电站模型的依赖。当变电站的模型发生改变时,将不可避免地进行重新建模。为此可采用嵌入式模式,简化建模过程,尽可能地做到少维护、易维护。
4.5 软件可靠性及对外部的影响
智能变电站高级应用软件从设计到开发的全套过程严格遵循软件设计开发的规范,在程序的执行效率和内存管理等方面精益求精。根据已有的运行经验,应用软件的可靠性在多个厂站得到验证。
就应用软件对外部的影响而言,分布式建模、状态估计、智能告警和风险评估等分析型应用不涉及控制操作;分布式电压稳定控制和AVC等控制型应用,将本地可控资源提供给控制中心,使控制中心给出的控制策略更加合理、安全,有效地提高了控制中心的控制可靠性和变电站的操作安全性。此外, 控制策略中闭锁逻辑等技术的应用也有效地降低了变电站控制的风险系数。
4.6 与智能电网调度控制系统基础平台的关系
智能电网调度控制系统基础平台实现了国、网、省、地、县调度自动化系统的横向集成和纵向贯通, 顺应了中国特大电网智能调度控制的需求。本文提出的变电站—调度中心两级分布式调度控制体系及变电站高级应用软件是对这一思想的自然扩展和有益补充。变电站高级应用软件的本质作用是将变电 站自动化系统纳入智能电网调度控制体系当中,从而从根本上提升特大电网智能调度的可靠性和敏 捷性。
5 结语
传统集中式调度模式在可靠性、准确性、敏捷性等方面的不足愈加突出。建立分布自治和集中协调相统一的两级分布式智能调度控制模式符合智能电网的发展趋势。变电站高级应用软件是该调度控制 模式的基础,同时也是变电站由数字化向智能化发展的必然要求。
本文的初步实践表明,变电站高级应用软件可以有效提升电网运行控制水平。特别的,可以进一步发展出针对可再生能源电场(站)特色的分布式高级应用,提高可再生能源建模、分析和控制的敏捷性,适应可再生能源发电的强波动性。可以相信,随着相关关键技术的研究和解决,以及其工程实践的不断深入,变电站高级应用的家族会有越来越多的新成员加入,为提升智能电网环境下电网的运行控制水平作出贡献。