（计算机系统结构专业论文）业务规则管理的研究及其在变压器故障检测系统中的应用.pdf

中文摘要 随着各种各样新技术的发展，人类的生活发生着翻天覆地的变化，这样的变 化在近几年来尤为迅速。信息技术在社会各领域的广泛应用，使得该技术本身也 要针对各领域内发生的变革做出及时和适当的变更。因此，基于规则的方法应运 而生。基于规则的方法的根本目的在于将业务规则与程序代码分离开来，使业务 规则变成可维护的对象，从而在业务逻辑发生变更的时候，无需变更程序代码而 完成修改。 当今电力系统中的输变电设备故障检测系统使用的是基本的信号反馈方法， 每一个监控站监控的设备数量庞大，故障信息依靠屏幕提示的方法反映给工作人 员，屏幕提示信息刷新的速度以及工作人员进行推理需要的时间都将导致工作人 员可能漏掉重要的故障信息。 本文针对输变电系统中变压器的故障检测，使用基于规则的编程方法，开发 了变压器故障检测系统，帮助工作人员对故障信息进行分析和做出相应的处理。 为了使用户能够真正的独自对业务规则进行维护，本文进行了业务规则管理系统 的研究与实现，并且，对业务规则集中业务规则之间可能发生的冲突进行了分析， 给出了可能发生冲突的规则模式，并针对不同的冲突情况提出相应的冲突检测算 法。 关键词：基于规则方法业务规则管理系统冲突检测变压器故障检测 a b s t r a c t w i t ht h ed e v e l o p m e n to fv a r i o u sn e wt e c h n o l o g i e s ，h u m a nl i f eh a sa l w a y sb e e n c h a n g i n gg r e a t l ya n dr a p i d l y e s p e c i a l l yi n r e c e n ty e a r s d u et ot h ee x t e n 5 1 v eu s em m o s ts o c i a lf i e l d s ，i n f o r m a t i o nt e c h n o l o g yh a s t om a k ea p p r o p r i a t ea n dp r o m p t c h a n g e st om er e v o l u t i o ni ne a c hf i e l da n du p o n t h a tr u l e _ b a s e da p p r o a c he l n e r g e d t h eb a s i cg o a lo ft h i sa p p r o a c hi st os e p a r a t eb u s i n e s sr u l e s f r o mi m p l e m e n t a t l o n c o d e 。计l i c hc o n v e r t sb u s i n e s sr u l e s t om a i n t a i n a b l eo b je a t ss ot h a tw ec a l la c c o m p l l s n m o d i f i c a t i o n sw i t h o u tc h a n g i n gp r o g r a mc o d ei nc a s eo f b u s i n e s sc h a n g e i np r e s e n te l e c t r i cp o w e rs y s t e m s i g n a lf e e d b a c ka p p r o a c h i su s e dmf a u n d e t e c t i o ns y s t 锄o fp o w e rt r a n s m i s s i o na n dt r a n s f o r m a t i o nd e v i c e s e a c hm o n i t o r s t a t i o nc o l l 仃d l sh u g ea m o u n t so fd e v i c e s f a u l ti n f o r m a t i o n i sd e l i v e r e dt ow o r k e r sb y d i s p l a y i n go nt h es c r e e n t h eh i g hr e f r e s hr a t eo fp r o m p t i n gm e s s a g e s o ns c 。e e l la n d t h e1 0 n gd l i r a t i o no fd e c i s i o n - m a k i n gw i l l r e s u l ti nt h el o s so fi m p o r t a n t f a n l t i n f o r m a t i o n b a s e do nt h ef a u l t d e t e c t i o no ft r a n s f o r m e ri np o w e rt r a n s l n l s s l o n a n d 仃a n s f 0 肌a t i o ns y s t e m , w ed e v e l o p e dt h et r a n s f o r m e r f a u l td e t e c t i o ns y s t e mb y a d o p t i n gr u l e - b a s e dp r o g r a m m i n ga p p r o a c h t h i ss y s t e m c a l lh e l pp e o p l ea _ n a l y z et h e f a u l ti 1 1 f o n n a t i o na 1 1 dt a k ec o r r e s p o n d i n go p e r a t i o n s i no r d e r t ol e tu s e rm a i n t a i nt h e b u s i n e s sr u l e sb a s ei n d e p e n d e n t l y ，w e s t u d i e da n dd e v e l o p e db u s i n e s 8 r u l e m a n a g e m e n ts y s t e m c o n s i d e r i n gp o s s i b l ec o n f l i c t sb e t w e e nr u l e s i nr u l eb a s e , w e a n a l y z e dt h o s e c o n f l i c t sa n dp r o p o s e dc o n f l i c td e t e c t i o na l g o r i t h ma c c o r d i n gt o d i f f e r e n tc o n f l i c ts i t u a t i o n s k e yw o r d s ： r u l e b a s e da p p r o a c h ， d e t e c t i o n ，t r a n s f o r m e rf a u l td e t e c t i o n b u s i n e s sr u l em a n a g e m e n t ，c o n f l i c t 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得叁盗盘堂或其他教育机构的学位或证 书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均己在论文中 作了明确的说明并表示了谢意。 学位论文作者签名：西1i 玄露 签字日期： 州年6 月乡日 学位论文版权使用授权书 本学位论文作者完全了解鑫鲞盘堂有关保留、使用学位论文的规定。 特授权丕鲞盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校 向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：hi 移 导师签名：狠绷 签字日期：寸卅年g月y 日 签字日期：洲年6 月 第一章绪论 1 1 研究背景 第一章绪论 在当今世界中，一切都充满了无穷尽的变化，从市场到公司的产品，从客户 需求到领导的决策，从工艺流程到产品规格，“唯一不变的就是变化，【1 1 。随着 计算机应用到社会生活中的各个领域，深化到社会的每一个环节，随着信息技术 的迅速发展和广泛应用，企业内外的经营环境发生了剧烈的变化，业务流程变革 已成为企业增强竞争力、适应未来的有效手段。业务流程变革要求信息技术与企 业流程创造性地结合，深化两者之间极为密切的关系【2 】。对于软件系统灵活应对 这些业务流程的变更提出了新的挑战和更高的要求，这些变更对应在信息管理系 统中即所谓的业务逻辑的变更。 传统的企业应用软件变更的过程是这样的，当业务人员想要对已有软件的某 些功能和流程进行修改的时候，要向i t 部门提出申请。而i t 部门的工作人员对 于具体领域中的业务问题知之甚少，于是，两者需要大量的时间用来沟通以达成 共识。之后，i t 部门对于软件做出调整，变更的业务逻辑分布在程序的各个角 落，通过复杂的调整与测试，交由业务人员来确认使用。期间，可能因为不符合 业务人员原来提出的需求而不得不重新更改代码或者重写代码，这样的过程带来 的时间和费用上的开销是巨大的，而业务人员最终也可能拿到的仅仅是勉强可以 接受的代码。 需求的变化与i t 能力之间的差异被称为i t 空白带 3 。针对信息系统在业务逻 辑上的易变性和i t 空白带的存在，迫切需要一种新的软件开发方法来提高软件的 复用性和开发的效率。于是基于规则的软件开发方法应运而生。它试图将那些埋 没于过程代码中的业务知识分离出来作为规则单独加以管理，使业务知识可以用 一种描述性的非过程方式加以定义。这样一来，程序的业务逻辑本身和它的实现 被分离开来，业务逻辑以业务规则的形式表述，它的变化不会影响到应用系统本 身。原来的“黑盒”系统演变为一种“白盒”系统，业务逻辑可以为外界所见【4 】。 运行时，规则引擎必须对这些业务规则进行解释。可以将规则引擎理解为一 种高性能的专用解释程序，其中包含i f - t h e n 命令，可根据预先定义的规则对转 换的值和对象进行分析，然后返回修改后的值和对象，或直接执行操作。因此， 大多数规则引擎使用“r e t e ”算法，并支持演绎和归纳。 为了弥合业务观点和i t 观点间的差距，就产生了对业务规则管理系统 第一章绪论 ( b 蹦s ) 的需求。在业务规则管理系统中，会将公司使用的策略和过程进行结 合，以管理业务规则的整个生命周期。因此，受影响的部门和非i t 人员必须能够 实时地修改i t 基础架构，以适应一般条件和策略【4 】。 业务规则管理系统源自以下想法：开发人员把应用软件的业务逻辑与数据验 证逻辑及工作流控制相隔离，形成独立的业务逻辑容器业务规则管理系统， 随后业务人员就可以用简单的类似英文的编程语言为业务规则“编写代码”【5 1 。 在规则引擎引用到软件系统的开发过程中之后，对于i t 人员来讲，大大地 减轻了其在业务需求变更和后期维护的过程中的工作量：对于企业来讲，很大程 度上减少了变更管理的成本。而业务规则管理系统的引入，进一步解放了i t 人 员的劳动力，使得变更管理变得更加容易，应用效率得到很大的提高。 1 2 研究现状 作为一种技术，基于规则的编程方法在2 0 世纪8 0 年代就已经诞生，而且曾 随着人工智能的研究热潮达到顶峰。到2 0 世纪9 0 年代，随着面向对象开发方法 的流行，类、封装、继承以及消息通信机制等技术的出现为基于规则的程序提供 了良好的集成和实现环境，对象模型可以和业务规则模型完美的结合在一起。在 这种背景下，业务规则方法形成理论并逐渐得到青睐，而且在最近几年得到了较 快的发展。研究表明，业务规则技术可以很好地应用于信息系统的业务逻辑层的 实现之中【6 1 。 此时，自动化的业务规则管理显示出了特别显著的优势：包括强大的可控制 性、发展的灵活性以及在开发过程、信息系统和各种应用中快速部署业务规则的 能力。但是，很少的业务规则管理商品被应用于信息系统之中。在计算机领域， 对于业务规则的研究十分活跃，包括规则编程、数据建模、规则提炼、规则使用 接口、规则引擎以及规则在面向服务架构中的应用角色。 这样的研究刺激了市场的发展，业务规则引擎在每年的产品销售中取得了 5 0 0 万美元的销售成绩，全球范围内，有5 0 多个商家在出售规则引擎【7 】。除了商 业产品，开源社区也有不少优秀的规则引擎，其中的代表有j b o s sr u l e s 、 m a n d a r a x 、j l i s a 掣8 1 。这些开源引擎尚不具备完善的规则管理功能，但某些已经 拥有很好的推理效率和性能。 当前有一个基- z m a n d a r a x 规则引擎的工具o r y x 来管理规则集【9 】。m a n d a r a x 规 则引擎使用b a c k w a r d c h a i n i n g 的推理方式。m a n d a r a x 是第一个支持r u l e m l 的应 用。o r y x 是一个图形界面的规则编辑工具，它是一个包含了谓词，函数和数据库 链接的知识库。o r y x 可以生成r u l e m l 语言，r u l e m l 语言是基于x m l 语言的一种 第一章绪论 规则表达语言。 将规则描述成r u l e m l 语言的转换器还有： ( 1 ) p r o l o gp a r s e ra n dr d ft r a n s l a t o r ，可以生成r d fr u l e m l 。 ( 2 ) p r o l 0 9 2 r u l e m l ，可以将p r o l o g 转换成r u l e m l 。 ( 3 ) v d r - d e v i c e ，可视化界面，可以为语义网开发可废止逻辑。 ( 4 ) t r a n s l a t o r ，将a c e ( c o n t r o l l e dn a t u r a ll a n g u a g e ) 转化成r u l e m l 。 由于常用的d r o o l s 规则引擎通常使用的是d d 文件与d s l 文件作为其规则文 件，所以需要一个规则管理器来管理支持d r o o l s 规则引擎的规则。 总体来说国际上对于规则管理平台的研究已经有1 0 年左右的历史，商业化 产品的推出也有4 5 年的时间，目前其己经形成了一个行业。特别在金融、保险 等行业系统、e r p 、电子商务以及专家系统方面有广泛的应用，但是针对一般信 息系统及故障诊断系统的应用还较为少见。 此外，为了协调不同厂商规则引擎之间在接口和a p i 调用方面的不同，提高 规则引擎之间的互操作性，在i l o g ，b e a ，b l a z e 等公司的发起下，j c p 于2 0 0 4 年8 月正式发布了j a v a 规则引擎a p i 规范，即j s r 9 4 。这是规则引擎领域的第一 个正式标准【l o 】。 1 3 研究内容和本文的工作 自从s t a n d f o r d 大学于1 9 6 8 年开发出第一个专家系统d e n d r a l 以来， 专家系统由于其广泛的应用范围和能产生巨大的经济效益而得到快速发展，现已 成为人工智能的研究前沿之一。故障诊断专家系统作为专家系统中的一个分支， 其研究得到了学术界和工程界的高度重视，并相继在各行各业中得到成功应用。 在电力系统中，庞大的设备设施网络中的故障时时出现，依靠工作人员实时 检测各个故障信号并做出相应的应对策略决定，对于工作人员的工作强度和精神 高度集中要求很高。其次，基于规则的故障诊断系统应用还处于起步阶段，将规 则分离出来，可以使得诊断过程变得灵活可变。 出于这种考虑，本文希望可以做出这样的尝试：在构建电力设备故障诊断系 统时，将诊断过程中的业务规则分离出来，达到在电力设备更新或者规则有所变 更时，使变更管理变得更为简单易行，变更时间尽量缩短，效率提高。提供给用 户有效的规则维护界面，帮助用户将新录入的规则进行初步的冲突检测，提示用 户解决可能产生的冲突问题，使用户可以部分完成规则的维护。 本文的主要研究工作有： ( 1 ) 对业务规则方法原理、规则引擎理论以及业务规则管理系统进行了 第一章绪论 深入研究。 ( 2 ) 结合业务规则方法原理和规则引擎j b o s sr u l e s ，针对电力系统中 输变电系统的主要设备的故障诊断，进行业务规则管理系统的设计与实 现，利用录入的规则完成基于业务规则方法的实验诊断系统。 ( 3 )对规则冲突进行研究，提出规则冲突的初步检测算法，并在系统中 实现。 1 4 论文的结构安排 第一章，主要介绍了课题的选题背景，研究现状，本文的主要研究内容和文 章的主要结构。 第二章，首先介绍了业务规则方法的基本原理，其次介绍了业务规则方法的 核心规则引擎的相关理论，第三，介绍冲突相关理论，最后介绍关于业务规 则管理系统的相关思想。 第三章，针对变压器故障诊断的需求，提出变压器故障诊断实验系统的总体 设计架构以及提出基于此系统的业务规则管理系统的总体结构的设计。 第四章，对第三章设计的变压器故障诊断实验系统的总体设计架构的详细设 计、对相应的业务规则管理系统的详细设计。详细阐述业务规则管理系统中的几 个关键功能的实现，包括对与冲突规则的初步检测算法的介绍。 第五章，对全文进行了总结，并对下一步需要完善的工作进行了展望。 第二章相关理论和技术研究 2 1 业务规则 第二章相关理论和技术研究 实际上，业务规则在我们的现实生活中无处不在。从销售的角度看，业务规 则就是一个产品的折扣情况，包括打折的条件，折扣是多少，折扣期有多长；从 管理的角度来看，业务规则或者就是什么情况下给出怎么样的激励惩罚措施，不 同的产品采取的不同的推广策略：而在立法的观点上，规则的表现更是特别突出， 这也可以称为十分典型的业务规则。 作为一种新的软件设计思想，业务规则方法在2 0 世纪9 0 年代中期被提出， 经过十余年的发展，其理论方法已经被业界认可并走向成熟。与之相关的技术和 方法论已经在2 0 世纪末和本世纪初得到验证，结果表明其理论是完全正确的【l l 】。 2 1 1 业务规则的概念 有关业务规则的定义有很多，女l j g u i d eb u s i n e s sr u l e sp r o j e c t t l 2 】将业务规则定 义为“对业务中某些定义和限制的描述，用于维持业务结构或控制和影响业务的 行为”。而h h e r b s t 1 3 认为“业务规则就是关于业务是如何开展的描述，如组织 中有关状态转变和过程处理等的准则与限制”。 业务规则是一组准确凝练的语句，用于描述、约束及控制企业的结构、运作 和战略。具体地说，业务规则有两个层面的意思：从企业的角度看，业务规则是 一种原则，包含在特定活动或范围内关于指导、操作、实践或过程的行为规范； 从信息系统的角度看，业务规则是一个定义或限制业务某些方面的声明，旨在用 来断言业务结构，或者控制或影响业务行为 1 4 】。 业务规则还可以形式化定义：规则可以表示成为五元组( e ，c ，a t ，a f , l ) 。 e 是触发规则的事件，c 是为了执行动作进行校验的条件，a t 是在c 为真时的动作， a 缇在c 为假时的动作，l 是规则的优先级【l6 1 。 2 1 2 业务规则的表现形式 业务规则在面向用户的表达方式和面向系统的表达方式上是迥然不同的 1 8 】。 对于用户来说，可能的表现形式包括决策树、值域和一定的计算、结构化的自然 语言表达等等，但是在系统中，这样的表达方式无法被识别。 第二章相关理论和技术研究 对业务规则的表达源于人工智能领域的知识表示。知识表示方法种类繁多， 分类的标准也大不相同，通常的方法有直接表示、逻辑表示、产生式规则表示、 语义网络表示、框架表示、脚本表示、过程表示、混合型知识表示、面向对象的 表示等方法【19 | 。在这些方法中，由于产生式知识表示方法容易描述事实、规则以 及它们之间的不确定性度量，因此可以用于方便地表示业务规则。 在产生式知识表示方法中，事实和规则这样表达：( 1 ) 事实可看成是断言 一个语言变量的值或是多个语言变量间的关系的陈述句，通常用三元组( 对象， 属性，值) 或( 关系，对象l ，对象2 ) 来表示，其中对象就是语言变量。 ( 2 ) 规则用于表示事物之间的因果关系，以i fc o n d i t i o nt h e na c t i o n 的单一形式来描 述。其中c o n d i t i o n 部分称作条件式的前件或模式，a c t i o n 部分称为动作、后件或 者结论1 2 0 j 。 ， d r o o l s 是一个使用基于规则的方法实现的专家系统的规则引擎，更准确的说 属于产生式规则系统。本文是基于d r o o l s 规则引擎的，并且要对业务规则进行 管理维护，因此，详细介绍一下d r o o l s 规则引擎所支持的规则表达方式是十分 必要的。 在d r o o l s 规则引擎中使用的规则指定“w h e n ”作为一系列条件的集合( 称 为l h s ) ，然后在“t h e n ”中指定一系列操作( 称为i m s ) 。使用“w h e n ”来 取代“i f ”是因为i f 表示的是在程序的运行过程中某一特定时刻对条件进行判断， 而w h e n 则表示不约束在特定的评估顺序或时间点，在引擎生命周期的任何时候 “w h e n 都可以执行。规则以关键字r u l e 开头，紧跟着这一条规则的规则名， 在同一个规则文件里不能有重复的规则名出现。l h s 紧跟在w h e n 后面，r h s 则 紧跟在t h e n 后面，每一条规则使用e n d 关键字作为结尾。在规则中不支持嵌套 规则。 2 2 规则引擎 规则引擎是基于规则方法的软件系统中的核心部分，随着基于规则的编程方 法迅速的在行业内发展起来，计算机业内对于规则引擎的研究和开发实现的热情 也快速的高涨。很多商业规则引擎出现在市场上，更有很多有兴趣的人们进行了 许多有益的研究，开源的规则引擎产品也十分优秀。本文是基于d r o o l s 规则引 擎，d r o o l s 就是一个开源的规0 l u l l 擎产品。 2 2 1 规则引擎的定义 到目前为止，规则引擎还没有十分一致的定义。j s r 9 4 是这样描述它的： 第二章相关理论和技术研究 一个规则引擎可以被看作一个完善的i f t h e n 语句的解释器。这里的i f t h e n 语句一 般被称为规则。规则引擎的输入是一个规则集和一个初始数据对象集合，输出则 是当初始数据对象符合某些规则之后规则的执行结剁1 0 】。 j a v a 规则引擎起源于基于规则的专家系统。规则引擎实现了关键业务规则从 程序源代码的分离。它被集成到了业务规则应用程序中，用来执行组合在规则集 中的业务规则。规则引擎将事实与规则集中的各个规则的条件匹配，找到匹配上 的规则，执行该规则指定的操作。 2 2 2 规则引擎的工作原理 图2 1j a v a 规则引擎工作原理 j a v a 规则引擎对于提交给j a v a 规则引擎的数据对象进行检索，根据这些对象 的属性值和它们之间的关系，从加载到规则引擎的规则集中发现符合条件的规 则，创建这些规则的执行实例。这些实例在接受到执行命令的时候，按照某种优 先顺序依次执行规则。般来讲，j a v a 规则引擎内部由下面几个部分构成：工作 内存即工作区，用于存放被引擎引用的数据对象集合；规则执行队列，用于存放 被激活的规则执行实例；静态规则区，用于存放所有被加载的业务规则，这些规 则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据 工作区中的对象现状，调整规则执行队列中的规则执行实例。当引擎执行时，会 根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可 能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变 而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规 第二章相关理论和技术研究 则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形成规则的推 理机制。这种规则的“链式”反应完全是n - f _ 作区中的数据驱动的【2 1 1 。 2 2 3 规则引擎的推理方法 产生式规则系统有两种执行方法一正向推理和逆向推理，两种方法都使用 的系统称为混合型产生式规则系统。理解这两种操作方法是理解产生式规则系统 之所以不同和怎样从中选择最合适的系统的关键。 正向推理是数据驱动的，事实被传递到工作空间中，在那里有一个或多个规 则与这些事实匹配，并由a g e n d a 安排执行从一个事实开始，传递事实，最 后得到一个结论。d r o o l s 是基于正向推理的规则引擎。 逆向推理是由目标驱动的，这意味着从一个引擎需要满足的结论开始进行推 理。在这个结论不能满足时，将搜索一些能够满足的结论来推理，称为子目标， 这些子目标将帮助完成当前目标的某些未知部分一引擎持续这个过程，直到最 初的结论被证明或没有可证明的子目标。 2 3 冲突 2 3 1 冲突的概念 首先举一个例子： r u l e l ：瓦斯气流速大于0 m s ，设置警告信息轻瓦斯报警 r u l e 2 ：瓦斯气流速大于l m s ，设置警告信息重瓦斯故障 当瓦斯气流速为1 5 m s ，从这两个规则中推理出的结果就依赖于规则执行 的顺序。在推理引擎中，当使用模式匹配选择出应该执行的规则后进入代理，此 时当被选择的规则不只条时，就会出现规则冲突的问题，即不同的执行顺序所 得出的结果不同。 第二个例子，并发情况造成的冲突： r u l e l ：瓦斯气流速大于0 m s ，设置警告信息轻瓦斯报警 r u l e 2 油温大于3 0 0 ，设置警告信息负载过大 当两种情况同时发生时，警告信息因规则执行的顺序不同而改变，也会导致 冲突的发生。 2 3 2 冲突产生的原因 在一个规则库的建立过程中，通常是按自然语言的描述来分解规则，不可避 第二章相关理论和技术研究 免的造成前后规则的冲突。而在系统运行过程中，由于基于规则的系统的应用价 值，系统维护人员需要按照现实中规则的变化对规则集中的规则进行增减和修改 来满足需要，于是，也会带来规则间的冲突【”】。特别是在为系统开发了相应的规 则管理系统之后，规则的修改变得简单易行，操作人员可能是新接替工作的业务 人员或者i t 人员，因此规则的更改产生冲突的可能性也会相应增大。 2 3 3 冲突解决的策略 ( 1 ) 一般的冲突解决方案 按知识库中的规则顺序执行规则。 激发优先级最高的规则。在简单的应用中，可以通过将规则在知识库中 以适当的顺序放置来设置优先级。一般这种策略适用于大约有1 0 0 个规则的 专家系统。在一些应用中，数据也应该按照重要性进行处理。 激发最具体的规则。也称为最长匹配策略。它基于的假设是具体的规则 比一般的规则处理的信息更多。 激发那些使用数据库中最近录入的数据的规则。这种方法依赖于数据库 中每个事实的时间标签。在发生冲突时，专家系统首先激发的规则是使用数 据库中最近录入数据的规则。 上述的冲突解决方法都比较简单并且易于实现。在大多数情况下，这些方法 可以得到满意的结果【l7 1 。 ( 2 ) 元知识 元知识可以简单的定义成知识的知识。元知识是在专家系统中使用和控制领 域知识的知识。在基于规则的专家系统中，元知识用元规则来描述。元规则定义 了专家系统中使用任务相关的规则的策略。 知识工程师将领域专家的知识传递到专家系统，学习如何使用与问题相关的 规则，并且逐渐在自己脑中建立新的知识体系以及专家系统行为的知识。这种新 的知识，或者说是元知识，很大程度上是独立于领域的。例如： 元规则1 ：专家提供知识的优先级高于初学者提供的知识 元规则2 ：控制营救人类生命规则的优先级高于关心清理电力系统设备 超载的规则 有些专家系统为元规则提供了单独的规则引擎。但大多数专家系统不能分辨 规则和元规则。如果是这样，应该在现有知识库中赋予元规则最高的优先级。一 旦被激发，元规则便向数据库“置入 一些重要的信息，以改变其它规则的优先 级。 当一个程序规模很大和很复杂时，知识工程师管理和检查知识库中的规则就 第二章相关理论和技术研究 变得日益困难。专家系统自身必须分担一些职责并理解自己的行为。此时，就需 要给系统提供元知识以提高其处理问题的能力1 1 7 】。 ( 3 ) d r o o l s 规则引擎中的冲突解决 d r o o l s 采取的冲突解决策略有2 种，按照优先级排列如下：s a l i e n c e ，l i f o ( 后进先出) 。最易懂的策略是“s a l i e n c e ，即优先级，用户可以为某个r u l e 指定一个高一点的优先级( 通过赋给它一个比较大的数字) 。高优先级的r u l e 将会被优先激发。l i f o 的优先级基于分配给w o r k i n gm e m o r y 操作( a c t i o n ) 的 计数值，从同样的a c t i o n 建立的多个规则具有相同的值，相同值的规则执行顺 序被看作可任意进行。 2 4 业务规则管理 2 4 1 业务规则管理系统的提出 在信息和技术日新月异的今天，企业为了紧随时代节奏和增强竞争力，对本 身的业务规则的调整也在加速，势必提高信息化系统中业务逻辑的更改频率，凸 显出以下几个问题： 首先，修改业务逻辑是牵一发而动全局的事情，任务繁重，修改周期长，增 加了原系统的不稳定性；其次不精通编程的业务人员无法对业务逻辑进行修改， 因此，变更带来的代价是昂贵的。 针对以上问题，提出了将业务规则像提取数据信息一样从具体的程序代码中 剥离出来，以结构化的业务规则数据来表示企业的业务行为，业务规则存储在规 则库中，完全独立于数据与程序。业务人员可以像管理数据一样对业务规则进行 管理【6 1 。 2 4 2 业务规则管理的生命周期 企业中的信息系统能否针对实施环境的变化而做出适当反应的能力是衡量 该系统成功与否的关键因素。显然，应对业务逻辑变更的能力对于系统的效率和 功能方面有着深远的影响。因此，对于业务规则的解释与管理要贯穿于起初的需 求分析阶段、用户理解阶段、系统组件设计和维护等整个系统的生命周期之中【2 3 1 。 因此，在软件开发过程中，业务管理生命周期应与软件开发生命周期并行存 在，同时为系统的设计实现提供整体的规划和控制。其中，软件开发生命周期针 对i t 人员，偏向于技术流程，而业务管理生命周期则更注重业务逻辑的提取和 变更。 第二章相关理论和技术研究 图2 - 2 业务规则管理生命周期 图2 2 说明了业务规则管理生命周期的组成阶段： ( 1 ) a l i g n ；在这个阶段，由业务部门和i t 部门的高级管理人员将有影响 的业务划分为多个业务逻辑模块，并进行业务驱动的分析。其产出是一个宏观上 的业务规则部署计划，包括业务规则的优先级、顺序和时间点等。 ( 2 ) c a p t u r e ；分析在开发过程中对于逻辑分区有影响的潜在的业务规则， 参加人员包括i t 和业务人员以及领域专家等。其产出是一个冗长的对于已选择 的业务模块有影响的潜在业务规则的列表。 ( 3 ) o r g a n i z e ：分析抽离出有用的业务规则在这一阶段，参加人员包括 i t 和业务人员以及领域专家。其产出是可以正式使用的规则集。这一步的关键 在于去掉那些业务模块外的或者无效的规则。 ( 4 ) a u t h o r ：将隐式的已抽取出来的规则转变成显示的规则数据。要求参 与的人员为业务部门人员和组织的决策者。其产出是可以投入使用的已授权的规 则集。 ( 5 ) d i s t r i b u t e ：顾名思义，这一阶段主要由i t 相关人员完成，包括与组织 合作开发的商家，组织内的i t 人员以及i t 管理部门。在这一阶段，将可以使用 的规则集转化为可以执行的规则集。 ( 6 ) t e s t ：保证对于已经完成的规则在规则集和应用环境的互相交互中运 转正常。这一阶段的参与者包括j t 人员业务人员和领域专家。测试主要分为 单元测试、集成测试以及可接受性的测试。这一阶段的测试要区别于对业务规则 逻辑性的测试，业务规则逻辑性的正确与否应该在规则授权阶段予以确定。此阶 段的产出为铡试报告。 ( 7 ) a p p l y ：将运转正常的规则集投八到正常的使用中圭。 ( 8 ) m a i n t a i n ：维护是一个贯穿始终的行为，它更像是一个监管员，在每一 个大阶段都会不停的检查该阶段任务的完成情况。比如在a l i g n 阶段，m a i n t a i n 第二章相关理论和技术研究 的任务就是检查逻辑分区的正确性，不断调整分区，检测其上下文逻辑是否合适： 而在规则管理阶段，m a i n t a i n 的任务是对于不断修改的规则进行检查，并且保证 规则的复用；在实现阶段，则保障计算机系统对于规则集的使用顺畅和快速部署。 这三个阶段八个步骤与软件开发生命周期是从不同的角度来分析系统开发 的过程并给予监控管理，在本文的实验工作中，因为是一个实验的系统，所以除 了第七步骤没有完成以外，基本按照这几个步骤进行。 2 4 3 业务规则管理系统的功能 首先，定制业务规则。规则定制器为定制业务规则提供友好、直观、快捷的 界面，开发者与业务人员均可用之来定制业务规则文件和业务数据对象。 其次，业务规则的部署。结合规则引擎，把业务规则和业务数据对象部署到 系统中，构成业务逻辑层。 第三，管理业务规则。对规则集进行维护，也可提供按用户和角色分配基本 的规则管理功能【6 j 。 2 5 本章小结 本章主要介绍了与本文相关的知识和技术背景。其中包括了业务规则和规则 引擎的相关概念，表现形式和工作原理，这对于本文工作的设计实现给予了理论 支持和启发。对于冲突的产生与介绍有助于本文工作中对冲突的初步检测提出解 决方法。而对于业务规则管理系统的相关介绍为本文整个开发过程的开展有着十 分重要的指导意义。 第三章变压器故障检测系统和相关b r m s 的总体设计 第三章变压器故障检测实验系统和相关b r m s 的总体设计 3 1 项目背景 在当前的电力系统设施中，变压器是输变电系统中重要的电力设备。变压器 容易由于各种原因产生故障。当前对于变压器的设计使得变压器本身可以应付一 部分不影响生产工作安全的小故障，或者，延缓故障对变压器自身的影响，争取 到时间使工作人员可以到现场进行处理。但是，仍然需要对其进行密切的关注， 需要对各项参数值进行掌握和了解，以防故障超出了变压器自身调节的范围。因 此，对于变压器的故障检测相应地成为十分重要的活动。 当前的变压器故障监测站系统网络架构如图3 1 所示。 历史数据服务器 调度员工作站 w e b 服务器 图3 1 故障监测站网络结构 r t u 是电厂现场采集数据的装置，它将模拟信号传给调制解调器，由调制 解调器转换为标准数字信号之后，传输给服务器进行数据处理。该系统中的数据 分为多种，包括实时数据，警报数据，控制数据，历史数据，系统维护数据等等。 历史数据服务器记录所有这些数据；调度员工作站对实时数据和警报数据进行显 第三章变压器故障检测系统和相关b r m s 的总体设计 示，要求工作人员做出反应，产生控制数据；w e b 服务器提供类似信息管理系 统的功能，可以对各种数据进行查看。 由图3 1 中可以看出，每一个监控站要对大规模数量的电厂进行数据采集和 控制等监控动作，在调度员工作站中，信息量十分巨大，显示的数据不停刷新和 滚动翻页。当前的系统中，对于警报信息，在屏幕下方用醒目的颜色进行提示， 然而，由于庞大的数据信息量，造成警报信息刷新和滚动的速度也十分迅速，后 一条警报信息很容易将前条覆盖。工作人员在处理警报信息时，还要参考很多 相关的参数值来确定警报信息产生的可能原因，以便做出适当的反应，给出控制 信息。因此，工作人员很难对每一条警报信息都迅速地做出反应，并且，由于信 息的快速更新，也可能导致工作人员漏掉一些重要信息。 故障检测系统是故障诊断系统的一个简单的模型，或者说，一个简单的应用 实现。故障诊断系统是专家系统的一个重要的分支，它模拟了专家对于一个问题 的推断过程，对问题做出原因或者结果的推理，最终将推理结果提供给用户。故 障诊断系统是基于知识库的。业务规则方法来源于专家系统，它将知识库表达成 规则集，推理的动作交给规则引擎来完成。 基于以上所述，本文希望可以对当前输变电系统中变压器的故障检测实现自 动化和智能化，针对变压器可能发生的故障报警给出分门别类的报警信息，而对 于开关或者刀闸的控制也实现自动化控制。在这个过程中，尝试使用业务规则的 方式来完成简单的故障原因推理，并且为规则集的维护也进行设计，使得系统日 后的维护和扩展工作能够变得简单易行。采用这样的方式可以自动对每一条警报 信息做出迅速的反应，不会产生漏掉信息的情况，自动推理也减轻了工作人员的 工作强度。 3 2 变压器故障检测实验系统 3 2 1 变压器故障检测的逻辑分析 由图3 2 可以看出，变压器的故障大致可以分为三类：瓦斯气，油压，油温。 下面，基于图3 2 对于这三类故障的产生原因和需要做出的处理反应给出相关说 明和解释。 ( i ) 瓦斯气：从图中可以看出，产生瓦斯气的原因大致有两种，在瓦斯气 流量没有达到变压器的安全参数时，属于瓦斯故障，而瓦斯气流量迅速增大时， 会产生油压增高，此时可能发生的就是油压方面的故障。这两者可能会同时出现， 因此图中使用并列的形式列出。 第三章变压器故障检测系统和相关b r m s 的总体设计 工作人员 图3 2 变压器故障逻辑分析图 变压器 负载过大 丁一 企 a 值 上y 俞 2 小时 y 皇 加强风冷 n 油温达到 三二 通知 - i - _ 作人员 n 变压器是 _ 絮岁 土二 通知 工作人员 水冷降温 ( 2 ) 油压：油压过大会产生防爆阀破裂的警示，轻微的瓦斯气的产生不会 造成油压增大到使防爆阀破裂的程度，因此，防爆阀破裂时，通常是由于油压过 大造成的。 ( 3 ) 油温：变压器不同的型号所具有的配置是不一样的，很多变压器没有 水冷装置，因此需要对变压器的配置进行设计以满足需要。另外，图中给出的a 和b 两个参数值是根据不同情况设定的，但是显然b 是大于a 值的。在本文的 设计中，暂时使用符号来代替具体数值。 通知工作人员这一动作虽然在图中使用了同样的表达方式，但是在实际的应 第三章变压器故障检测系统和相关b r m s 的总体设计 用中，不同的故障通知给不同的工作人员，或者报出不同的警告信息。 3 2 2 变压器故障检测实验系统的总体结构 变压器故障检测实验系统事实上是基于业务规则的专家系统的一个简单应 用，因此，它基本上与基于规则的专家系统的总体结构是一致的，由规则集、工 作区和推理区组成。如图3 3 所示。 图3 3 基于业务规则的专家系统 对于规则集的维护将在下一小节中详细介绍。这里，需要对于工作区的结构 加以描述。 工作区在本文的实验系统中是一个接口，它接受从现实环境中得到的各种属 性参数的数据值，并将从规则引擎得到的运行结果反馈给用户。工作流程为取得 属性值，初始化对象，提交给推理引擎，由推理引擎做出推理运算，将结果返回 给工作区，工作区再将结果分别反馈给用户。 3 3 基于变压器故障检测的规则管理系统 3 3 1 规则管理系统的需求 采用基于业务规则方法对变压器故障检测进行实验系统的开发，其中一个出 发点在于，当系统交付使用后，对于系统的维护工作可以大部分交由用户来完成， 或者，将i t 人员对系统的维护工作的复杂度尽量降到最低。 在第二章已经介绍了d r o o l s 规则引擎采用的规则表达方式和规则文件的格 式，可以看出，对于完全没有计算机编程经验的用户来说，仍然无法理解规则的 表达方式，从而无法真正的脱离i t 人员对规则集自行维护。同时，即使未来的 维护工作交由i t 人员来完成，对于规则文件的修改始终不方便，而且无法保证 修改是正确的。因此，需要一个友好的用户接口保证用户可以方便快速的对规则 第三章变压器故障检测系统和相关b r m s 的总体设计 集进行维护操作。 规则管理系统与普通的信息管理系统有相似之处。可以将规则看作需要处理 的信息，对于规则的管理也包括对规则的增加，修改，删除等维护操作。但是， 规则管理系统有特殊的需求，即冲突的检测。由于提供给用户这样一个友好的接 口来对规则集进行维护，用户不可避免的会对已有的规则集进行增删改的操作， 当然，这也是提供给用户接口的目的，但是，用户对于整个规则集的逻辑无法完 全掌握，有可能在对规则集进行维护的时候造成规则冲突的产生，因此，需要为 规则管理系统提供一个冲突检测的功能。 3 3 2 开发平台的选择及系统的层次结构 由于规则管理系统与一般的信息管理系统功能相似，而对于一般的信息管理 系统来说，j 2 e e 的架构是非常好的处理结构。j 2 e e 具有j a v a 的所有优点，包括跨 平台、安全、开源免费等特性。j 2 e e 提供了一种基于组件的方式来进行设计、 开发、组织和发布企业应用系统。各个组件分布在多层次的分布式应用模型上发 挥作用。在j 2 e e 的体系结构中，一般分为客户层，w e b 表示层，业务逻辑层和企 业集成层【2 2 j 。 在j 2 e e 层次模型中，客户端表达从服务器端逻辑和业务逻辑中分离出来， 以w e b 浏览器、a p p l e t 或者应用程序的方式呈现，这样为客户的使用带来了方便， 客户不需要再安装客户端软件就可以获取服务。服务器端表达通过j s p 或者 s e r v l e t 实现，业务逻辑层通常由b e a n 组件完成，企业资源层则以数据库或者其它 数据资源形