（计算机软件与理论专业论文）面向监控与应急指挥系统的实时数据中心.pdf

摘要 y8 2 8 2 9 7 随着应急指挥概念在国内的广泛应用，基于监控系统的应急指挥系统逐渐被 应用于大量而广泛的领域中。例如：环保、排水、化工、交通、地震等都是监控 基础卜- 的应急指挥地应用领域。面向监控与应急指挥系统的实时数据中心就是在 这样的背景下进行研究和开发的。 本文主要介绍了监控与应急指挥系统的发展，并设计和实现了面向监控系统 与应急指挥系统之间数据交换的实时数据中心。首先讨论了传统监控系统的监控 方式，分析了应急指挥系统对于监控系统的新的数据要求，提出了实时数据中心 来解决监控系统和应急指挥系统的数据交换问题。另外提供了针列不同的应急指 挥系统需求面相对象的二次开发接口，这使得数据中心在监控与应急指挥系统巾 的应用更加完善也更加实用。本文也描述了数据中心在岭控与应急指挥系统中的 具体实现，重点设计和实现了实时数据缓存中缓存结构、实时数据组织形式、事 务并发性、实时数据压缩算法和实时数据同调等关键问题，并针对目前存在的一 些不足提出了解决的思路。 关键字；监控与应急指挥系统，数据中心，面向对象数据中间层，实时数据缓存 2 a b s t r a c t a st h ed e v e l o p m e n to fe m e r g e n c yc o m m a n d ，e m e r g e n c yc o m m a n ds y s t e m b a s e do ns u p e r v i s i o ns y s t e ma r ew i d e l yu s e di nm a n yf i e m s t h e ya r ee n v i r o n m e n t a l p r o t e c t i o n ，d r a i n a g e ，c h e m i c a li n d u s t r y , c o m m u n i c a t i o n ，e a r t h q u a k ea n d s oo n t h i si s t h eb a c k g r o u n do ft h er e a l t i m ed a t ac e n t e rf o rs u p e r v i s i o na n de m e r g e n c y c o m m a n ds y s t e m t h i sd i s s e r t a t i o ni sa b o u tr e a l 一_ n m ed a t ac e n t e rf o rs u p e r v i s i o na n de m e r g e n c y c o m m a n ds y s t e m ，i tf i r s tg i v e so u tt h ea p p l i c a t i o na n dd e v e l o p m e n to fs u p e r v i s i o n a n de m e r g e n c yc o m m a n ds y s t e m ，d i s c u s s e st h em o n i t o rt y p eo fu a d i f i o n a l s u p e r v i s i o ns y s t e m , a n a l y s e st h ed a t ar e q u i r e m e n to fe m e r g e n c yc o m m a n ds y s t e m a n dr e s o l v e st h ep r o b l e mo f d a t ae x c h a n g eb e t w e e ns u p e r v i s i o ns y s t e ma n d e m e r g e n c yc o m m a n ds y s t e mb yr e a l - t i m ed a t ac e n t e r t h e nt h e a r t i c l ep r o p o s e s o b j e c to r i e n t e ds e c o n d a r yd e v e l o pi n t e r f a c e sf r o mr e a l - t i m ed a t ac e n t e ra n dw i t h t h e s ei n t e r f a c e s ，r e a l t i m ed a t ac e n t e rt u r n si n t om o r ep m c t i c a la n dp e r f e c ti nt h e a p p l i c a t i o n o fs u p e r v i s i o na n de m e r g e n c yc o m m a n ds y s t e m i ta l s oi n t r o d u c e s d e s i g na n di m p l e m e n to fd a t ac e n t e ra n dr e a l - t i m ed a t ac a c h e ，t h em o s ti m p o r t a n t p a r to fd a t ac e n t e r a tl a s ti tc o n c l u d st h ea d v a n t a g e sa n dd i s a d v a n t a g e so fd a t a c e n t e r , a n ds o m e t h i n gt h a tc a nb ei m p r o v e di nt h ef u t u r ei sp u tf o r w a r d k e yw o r d s ：s u p e r v i s i o na n de m e r g e n c yc o m m a n ds y s t e m ，d a t ac e n t e r , o b j e c t o r i e n t e dd a t am e s o s p h e r e ，r e a l t i m ed a t ac a c h e 3 、 引言 1 1 监控与应惫指挥系统简介 从设备故障检测技术的诞生到现在的几十年中产生了许多监控程序和系 统。计算机监控系统是以监测控制计算机为主体，加上检测装置、执行机构与被 监测控制的对象( 生产过程) 共同构成的整体。在该系统中，计算机实现了生产过 程的检测、监督和控制功能。在现代工农业的生产和管理中，大量的物理量、环 境参数、工艺数据、特性参数需要进行实时检测、监督管理和自动控制。 监控系统是建立在现代的计算机技术、通信技术、控制技术以及图形技术上 的一个的应用。【lj 远程监控的监视点与控制中心分别位于两地，打破了地域的界 限，需要通过网络来连接传递信息。它采用多元的信息传输、监控、管理和一体 化的集成技术，实现了信息、资源和任务的共享，达到了监控的实时、快速和有 效，并能够跟其它的计算机网络系统互连，向人们提供了一个高效、全面、安全、 快捷的服务模式。 随着国民经济的迅速发展、社会生产力的迅速提高、社会分工的细化和相关 基础设施的不断完善，整个社会呈现出结构越来越复杂、关联越来越密切的趋势。 某一节点的故障和处理不当，往往会带来全社会的灾难。随着我国政府改革的推 进和职能不断调整，政府从参与到国民经济具体环节到通过相关职能部门，进行 宏观调控，处理紧急突发事件，保障社会的稳定。突发紧急事件对于社会的危害 之大、涉及到的方面之广，已经不是单个政府职能部门可以解决得问题。需要在 各级党和政府的统一领导下，协调个方面的力量和职能部门，积极行动。 基于以上的考虑，为了保障政府在紧急事件的处理过程中做到快速、及时、 准确的收集到相关的资料、通过多种方式进行及时的沟通、为领导提供科学的辅 助决策信息，基于先进的信息系统的应急指挥和辅助决策系统必然会在各级政府 单位发挥必要和强大的作用。然而传统的监控系统只将监控数据提供给监控者， 由监控者人为进行分析、解决的方式已经不再满足应急指挥的需要。因此，更符 合时代发展需要的应急指挥系统诞生了。 所谓应急指挥系统，是针对事件应急所开发出来的一套软件系统。应急指挥 系统是建立在监控系统之上的，该系统集成了一种或多种突发性事件行之有效的 应急预案，通过这套软件系统可以在危机事件发生时为决策人提供紧急的决策支 持，并通过多种高科技通讯手段进行指令信息传递和布达的一种控制系统。吲 此类产品在国外应用较为普遍，在国内尚在初级阶段。 应急指挥系统，针对突发性紧急事务处理的应急系统，其主要作用体现在危 机事件预警、危机决策支持和危机全程监控。 大多数危机事件突发性很强，本身带有很大的不确定性，很多现象人们从未 见过，事先也很难预知。因此，判定紧急突发事件的真实性和严重性在危机暴发 初期就显得非常重要，而全面和及时地信息汇总则是作出判断的唯一依据。应急 指挥系统本身采用多元化信息采集网络，可以在第一时间收集到该系统所管辖的 所有信息，及时给主管人员提出预警。在2 0 0 3 年“非典”暴发初期，由于信息的 不通畅，很多医护人员都被感染。如果当时这些信息能及时地传递，大部分医护 人员就可以及时采取防范措施，从而避免类似的感染。 当紧急事件信息有效传递到决策层时，为了保证决策的准确性，避免延误， 在“应急指挥系统”中，还建立有功能强大的专家库和方法库以辅助决策。简单地 说，就是“应急指挥系统”中的辅助决策模块可以给决策者提供紧急事件的信息收 集辨别信息的可靠性，同时还可以通过这个平台进行系统内部的信息交互、联动 指挥、实时沟通，从而为决策者提供准确的决策参考，也就是各种权威的紧急预 案。比如“非典”危机过后，如果再次面临类似的疫情时，决策人员就可以参照根 据“非典”疫情而作出的预案，从而提出行之有效有针对性的解决措施。 本文讨论的是基于监控系统的应急指挥系统，也就是基于大量实时数据的监 控与应急指挥系统。 1 2 监控系统的发展 监控技术是一门集计算机技术、通讯技术、网络技术及自动化技术于一体的 综合性技术，它是随着其他技术的发展而迅速发展起来的。设备监控模式经历了 从单机监控系统到分布式监控系统，再到基于i n t e m e t 的远程监控系统这样一个 发展过程。监控网络系统可以认为是第三代设备监控系统。 在现有的实时监控系统中，较为普遍的是s c a d a 系统。s c a d a 系统即监 督控制与数据采集系统，是集计算机技术、网络技术、通讯技术、传感技术于一 体的工业自动控制系统，它可以实时采集现场数据、对工业现场进行本地或远程 控制、对工艺流程进行全面实时监视，为生产调度和管理提供必要的数据，并可 借此运用控制论算法提供更进一步的辅助分析和生产调度决策。 s c a d a 系统一般采用分散式测控、集中式管理的方式。整个系统由监控中 心，若千个分散的远程测控终端r t u 氓e m o t et e r m i n a lu n i t ) 和通信介质三部分组 成。监控中心又称主站，是s c a d a 系统的核心，负责控制管理整个系统的运行； r t u 又称外围站点，是采用微处理器或d s p 的可独立运行的智能测控模块，完 成各种远端现场数据的采集与处理，现场执行机构的控制以及与远程控制中心的 通信，具有易扩展性和易维护性特点；通信介质根据实际需求和应用对象的不同 有多种实现方式。 监控系统经过了半个多世纪的发展已经相当的成熟了。对于监控系统采集的 大量的实时数据的管理，实时数据库应运而生。有关实时数据库的研究始于8 0 年代，1 9 9 2 年美国贝尔电话实验室的d k b a r c l a y 等人研制了第一个专用实时数 据库管理系统。随十多年来，各国的学者就有关实时数据库系统的设计和蜜现技 术、崩溃恢复、荠发控制、事务调度等方面作r 一些研究。左国内。华中理丁大 学现代数据库与信息系统科研组提出了r t d b s 与a d b s 的结合机制并开发出一 个原型系统a r t s i 。把主动机制加入实时数据库，即嵌入e c a 规则，事件一条 件一动作( e v e n t c o n d i t i o n - a c t i o n ) 规则。l j 1 3 问题的提出 传统的监控系统的监控模式只是将监控到的实时数据反应给监控者，或者将 这些实时数据保存。而应急指挥系统对于监控系统的数据需求不仅仅是简单的存 储、查询，还需要对这些数据进行智能的选择、处理。例立u ：对于监控设备的告 警，应急指挥系统需要监控系统能在监控设备发出告警信号的同时反馈给应急指 挥系统，而不是简单的存放之后由应急指挥系统主动的查询。因为大型的应急指 挥系统可能自成千上万个监控设备，要求应急指挥系统对于每个监控设备的告警 信息都采用查询方式明显是不可行的，而且这样同时会降低告警事件的实时性， 也增加n 节急指挥系统的开销。由于廊急指挥系统发展的时间并不长，在g o o g l e 和万方数据资源系统中，均套询不到有关监控系统与应急指挥系统之间数据交换 的资料。 因此如何通过对监控系统采集到的文时数据的智能处理结合案例推理和专 家系统满足廊急指挥系统的需要，成为一个新的课题。 1 4 本文的工作与创新 本文创新的设计了监控系统与应急指挥系统之间的实时的面向对象数据中 间层，并采用了n e t f r a m e w o r k 框架技术使用c # 语言实现了这一套数据中问层。 实时数据中间层既保证了监控系统的实时性，义满足了应急指挥系统对实时数据 的智能处理需求。本文的研究内容具体包括以下几个方面： 1 ) 刺于监控系统：提供了对于监控设备采集的实时数据和发出的告警信息 的保存接口，并提供接u 对监控设备进行控制。 2 ) 对于应急指挥系统：提供了面向对象的二次开发接口，二次开发人员可 根据不同的需求在数据中问层的基础 开发不同的应急指挥系统。设计和实现了 应急指挥系统中静态数据的缓存。 应急指挥系统中静态数据的缓存。 9 3 ) 对于监控系统与应急指挥系统之间的实时数据智能交换：数据中间层可 根据应急指挥系统不同模块对于不同实时数据的需要智能的传输。 4 ) 对于实时数据的管理与组织：采用分组分集合的方式管理实时数据；对 于实时数据缓存采用了多级锁、虚拟锁、只读锁等技术的解决事务的并发性问题； 对于不同模拟量的实时数据采用不同的压缩算法。 1 5 本文的内容与组织 本文第二章对数据中心进行了总体设计，包括监控与应急指挥系统的整体架 构、数据中心在监控与应急指挥系统中的作用，定义了核心数据模型、数据交换 中心、数据共享中心和数据源的功能，描述了数据中心中的数据流程和数据中心 中运用的关键技术，使读者能对监控与应急指挥系统的实时数据中心有一个大概 的了解。 在第三章中，我们介绍了数据中心的设计和架构。对于核心数据模型、应急 数据源、数据源、解析模块和数据中心服务进行了详细的设计和接口的实现。另 外还详细的设计和实现了对于监控与应急指挥系统中静态数据缓存并描绘了数 据中心的库表结构和类图。 第四章主要介绍了实时数据缓存的设计和实现，深入探讨了实时系统的特 点，设计了实时数据缓存的整体结构，定义了实时数据组、实时数据集合和实时 数据缓存元等数据结构，深入分析了实时数据缓存中的事务并发控制、实时数据 回调机制和对实时数据的压缩算法，并实现了实时数据缓存的接口。 最后，本文总结了数据中心在监控与应急指挥系统应用中的特点，并提出了 其今后还需要进一涉改进的问题和相关解决思路。 1 0 二、 数据中心概述 2 1 层次软件体系结构的基本概念 在软件体系结构的各种风格中，层次结构是一种经常使用到的设计风格。在 层次结构中，每一层完成一项确定的功能。它们都为各自的上层提供一定的服务， 同时又作为它们各自的下层的客户，使用下层提供的服务。在层次结构中，各个 层次只能和它们的相邻层相互作用，而这些相互作用应该遵循一些给定的规则。 目前，层次结构被大量地用于各种通信协议中。 层次结构具有多个良好的特性。首先，它支持基于不断增长的抽象层次的设 计。设计者可以将一个复杂的问题分解为一系列抽象层次不断升高的子问题，通 过分别解决各个子问题可以更容易地解决整个问题，提高软件系统的可靠性和软 件质量。其次，由于在层次结构中，每一层只能和它的相邻层相互作用，这种受 限的相互作用允许设计者更方便地改变某一层的功能。如果这些改变能保持接口 不变的话，它的相邻层甚至也不需要做任何改变。层次结构的这种特性能够很好 地支持软件升级。最后，如果层次结构中各个层次间的接口是标准化定义的，开 发者就能够独立地实现不同的层次，而同一个层次的不同实现之间可以方便地互 换，只要它们的接口是符合标准的。 三层软件体系结构是层次结构的一种，它起源于传统的两层客户服务器( c s ) 模型。在八十年代中期，随着微处理器的发展和| 决速局域网络的兴起，分布式计 算机系统开始在计算机界流行起来。在商业界，基于客户服务器模型的分布式 计算环境逐渐地成为了主流。使用客户n 务器模型主要有如下优势：( 1 ) 优良的性 能价格比。客户n 务器模型允许用户使用一组便宜的微处理器来代替一个主机 系统。在价格上，这两种系统通常要相差数十倍至数百倍。( 2 ) 高度的可靠性。 在客户服务器模型中，计算在多个服务器和多个客户之间分享。因此当某一个 服务器或者某一个客户出现错误时，整个计算环境并不会因此而崩溃。系统可以 以较低的吞吐率继续运行。( 3 ) 支持面向构件的开发方法。在客户j g ! i 务器模型中， 服务器以业务的方式为客户提供服务。这些业务可以很自然地被组织成一个个构 件。使用面向构件的开发方法，可以提高系统的开发效率和软件的可靠性。( 4 ) 良好的工具支持。目前有很多很好的可视化工具能够用来支持基于客户，服务器 模型的软件开发。 随着时间的推移，基于客户，服务器模型的计算变得越来越普及，软件设计人 员开始把客户n 务器模型应用到一个更广的领域。在这个过程中，客户，服务器 模型的一些不足之处也就慢慢地显露出来。这些不足之处有：( 1 ) 不能很好地支持 异种网络协议和异种数据库。由于管理上的原因，或者是由于公司重组或合并， 一些大公司的各下属部门往往拥有不同的网络，不同的数据库产品。在建设新系 统时，为了保护已有的投资和已有的数据( 这些都是在工程领域需要考虑的问 题) ，新的系统必须能将这些已有的设备和数据包容进来。客户，服务器模型不能 很好地处理这种情况。( 2 ) 不能很好地支持数据关键性应用。在客户n 务器模型 中，由于客户能童接访问数据库中的数据，使系统的安全性受到威胁。用户有可 能绕过系统的安全性机制而直接操纵数据库中的数据。另外，对于数据完整性， 虽然传统的数据库系统都提供了事务管理，或者更进一步地，通过两阶段提交协 议支持多个数据库之间的数据完整性，但是对于不同的数据库产品，以上两种方 法都不能提供一种很好的解决方案。( 3 ) 系统性能问题。在客户i n 务器模型中， 每一个客户都使用单独的连接同服务器通讯。一般每一个客户都要消耗若干个文 件句柄，一至两个进程句柄和几十个千字节的内存。如此大量地消耗系统资源， 将会使大多数服务器的性能急剧一f 降口 为了处理这些问题，三层软件体系结构应运而生。三层软件体系结构中的三 层分别指的是如下的三层：( 1 ) 客户，它实现图形用户接口( g u d 。( 2 ) 应用服务器， 它实现业务逻辑。( 3 ) 数据库或者遗留系统，它为应用服务器提供数据服务。不 同于三层软件体系结构，传统的二层客户朋务器模型中的业务逻辑并没有在一 个单独的层中实现。一般来说，! 眦务逻辑和g u i 一起在用户端实现，这样的客 户被称为肥客户；有时业务逻辑通过存贮过程可以在数据服务器上实现，这样的 结构被称为二层半结构。在三层体系结构中，由于业务逻辑在中间层实现，客户 端只需要实现g u i ，这使得三层体系结构中的客户成为瘦客户。因为大部分代码 运行在服务器上，三层结构满足了大型网络应用的对管理和配置的灵活要求。中 问件一般可分为以下几种类型：基于r p c 的中间件，消息中间件( m e s s a g e - o r i e n t e d m i d d l e w a r e ，简称m o m ) ，事务处理监控器( t p - m o n i t o r ) 等。在这些种类的中间 件中，t p - m o n i t o r 是中间件发展的高峰，它实际起到了一个事务管理器的作用， t p m o n i t o r 能保证不同的应用服务以a c i d ( a t o m i c i t y , c o n s i s t e n c y , i s o l a t i o n ， d l l r a b m t v ) 方式结成统一的服务n 。通过在客户端和数据库系统之间的介入，下 p m o n i t o r 能管理事务，帮助它们确定网络上的处理路由，平衡它们在运行中的 负载分配，以及对数据库端的失败进行处理【l4 1 ，从而提高了系统的处理能力。 随着w e b 应用变得越来越普及，人们逐渐提出基于w e b 的三层软件体系结 构。基于w e b 的三层软件体系结构的三层分别为浏览器，w 曲服务器，数据库服务 器。由于w e b 的基础结构的限制，在w e b 上开发应用程序往往会遇到各种各样 的问题，例如：( 1 ) 如何最大限度地提高系统- 9 n p 交互的能力；( 2 ) 如何在数据传送 协议h t t p 是无状态的情况下在客户端保持系统的状态；( 3 ) 数据的安全性，如何 保证数据只被合法的用户使用。三层软件体系结构很好地解决了这些问题。通过 在客户端使用j a v a a p p l e t 或者是插件( p l u g - i n ) ，用户可以摆脱浏览器带来的交互 能力上的限制，以多种方式同系统交互。由于业务逻辑在中间层实现，客户端以 事务方式向中间层请求服务，系统状态可以由客户端单独保持。这种业务请求方 式很好地适应了h 7 丌协议是无状态协议这一特点，特别地，这种业务请求方式 能很好地支持断连操作，特别适用于移动计算环境。在三层体系结构中，客户端 不再直接访问数据库，而是向中间层请求服务。中间层可以根据需要限制用户对 数据的访问，提高了数据的安全级别。 x m l 规范的提出更进一步地为w e b 上的三层系统提供了一种更加规范的数 据描述方式。由于h t m l 在描述数据能力上的缺陷，以往的w e b 上的三层系统 往往采用各自的数据描述方式。由于数据描述方式的不同，这样开发出来的系统 很难被重用。使用x m l 描述数据很好地解决了这个问题：并且使用x m l 描述数 据可以允许x m l 处理器根据d t d 来进行数据合法性验证，将非法数据排除在 系统之外，提高了系统的可靠性。因此可以这样说，x m l 技术使得基于w 曲的 三层系统变得实用起来。 而本文实现的实时数据中心正是一一个实时数据中间层，是三层系统中的中间 层系统，是基于三层体系结构的。数据中心采用的运行框架的关键技术也正是遵 循x m l 规范实现的。 2 2 数据中心概述 数据中心是面向对象的实时数据中间层，是支持二次开发的基础数据模型。 数据中心是监控与应急指挥系统的心脏，它负责控制和管理整个监控与应急指挥 系统中的数据。 数据中心在整个方案当中充当了数据存储者，数据交换者和数据管理者的角 色。数据中心将分布在不同位置的监控设备所采集的实时数据和告警等信息进行 存储；当某些模块需要实时数据时，数据中心负责将采集到的信息提供给这些模 块，例如告警中心需要判断实时数据是否超标，数据中心则会将实时数据传送给 告警中心；由于监控与应急系统的庞大性，可能整个系统会有成千上万的监控设 备，将所有这些设备的数据都存放在一个数据库或者一台服务器上是不可能的， 数据中心会根据用户配置将所有的监控设备数据存放在不同数据库中并对其管 理。 数据中心跟其他系统之间都可能存在服务关系，通讯方式分主动发送和被动 发送两种，如告警服务就是数据中心主动发送，而一些数据查询等服务就是数据 中心接收请求，被动发送。 数据中心所提供的服务根据是否需要应答可分为同步执行模式和异步执行 模式。所谓同步执行模式，是指语句在同步执行模式下，将始终保持对程序流的 控制，直至程序结束。例如查询操作，客户机上的应用程序在向服务器发出查询 操作的指令后，将一直等待服务器将查询结果返回客户机端后，才继续进行下一 步操作。所谓异步执行模式，是指语句在异步执行模式下，各语句执行结束的顺 序与语句执行开始的顺序并不一定相同。例如查询操作，客户机上的应用程序在 向服务器发出了查询操作的指令后，将立刻执行查询语句的下一条语句，而不需 要等到服务器将查询结果返回客户机端后，才继续进行下一步操作。 数据中心的核心数据模型和应急数据源作为接口提供给二次开发人员进行 二次开发。二次开发的作用在于用户可以针对自己需要应用的应急系统开发出不 同的应用系统。例如环保项目可以在数据中心的基础上开发环保数据中心，对于 数据中心提供的核- i i , 数据模型进行扩展，从监控设备中继承派生出噪音监控设 备，而排水项目可以开发排水数据源，从监控设备中继承派生出流量监控设备。 这样就可以更有效的保证了代码的重用性和系统的多样性。 数据中心的核心数据模型是面向对象的数据模型，数据中心提供给二次开发 者的接口均以对象方式出现。二次开发者对于数据中心内部的组织结构可以完全 不了解而轻松的运用对象的方式进行开发。 数据中心除核心数据模型之外其他都作为插件功能来实现。核心数据模型作 为应急指挥框架的元数据( 相当于c + + 中的i n t ) 一样，对于整个应急指挥都是公开 的接口。 1 4 2 。3 监控与应急指挥系统整体架构 监控与应急指挥系统框架的技术路线提供全开放式的系统框架，允许用户自 定义服务，允许其他系统的接入，来实现实时监控数据的共享，以及按入应急指 挥系统和专家系统等。 开放式的系统框架的优点：允许用户定义插件接入，影响系统在各个环节的 功能，实现用户定制功能；多业务系统的集成。 图一为系统的整体架构图： 图一、监控与应急指挥系统结构图 2 4 关键技术 2 4 1 运行框架 2 4 1 1 技术关键和技术路线 监控与应急指挥系统框架的技术路线提供全开放式的系统框架，允许用户自 定义服务，允许其他系统的接入，来实现实时监控数据的共享，以及接入应急指 挥系统和专家系统等。 开放式的系统框架的优点： 。允许用户定义插件接入，影响系统在各个环节的功能，实现用户定制功 能。 多业务系统的集成 运行框架的技术关键是设计开放式的系统框架，这个框架是整个系统设计的 一个运行平台，系统提供的所有功能都作为这个运行平台的外挂插件方式来实现 具体的业务功能。 网络传输协议的定义是本系统的另外一个技术关键，将不同功能的系统按照 同一的方式来进行消息传递是实现开放性系统的一个重要保障。 2 4 1 2 网络分布和硬件拓扑 鉴于运行框架具有高度的灵活性，对于实际项目实施，这些服务可以集中式 分布或者采用分布式设计。 系统运行框架是下面所有子系统的运行环境，其他子系统的业务功能都通过 运行框架的插件方式对运行框架的功能进行配置。 2 4 1 3 功能 系统运行框架的功能是将各个子系统业务模块联系起来，负责网络协议的定 义，数据的传输和业务功能的调度分配。 系统运行框架的另外一个重要功能是系统功能的定制，在同样的框架下面可 以实现实时数据交换中心，数据共享中心，告警中心等等。实现这种差异的根源 在于插入运行框架的功能子模块的区别。 系统运行框架可以很好的跟别的系统进行集成。 2 _ 4 - 1 4 网络协议 定义与运行框架的客户端之间的关系，可能是保持连接的客户端或者是无连 接的客户端等。 网络模块提供的接口主要进行网络通讯，接口为 i n ts e n d m s g ( s t r i n gd e s ti p ，s t r i n gc o n t e n t ) ； i n tr e c e i v e d m s g ( s t r i n gc o n t e n t ) ； 网络模块可能还会涉及到客户端( 另外一个运行框架) 的管理。 2 4 1 5 传送报文定义 系统可以定义某些关键字，比如c m d ，m e s s a g e 等等，主要作用供请求调度 模块进行对应的功能调度等。 报文整体上采用x m l 格式定义，例如一个查询请求 p ：a r a ) 对应回答响应为 每份报文都包含着这么几块信息，供网络层使用的 ，供调度层使用的 以及供插件具体函数使用的输入和输出部 分 2 4 1 6 运行配置 运行配置完成框架启动时对服务功能的定制，可能实现方式如下： 系统需要装入的功能模块，计划采用x m l 定义装载例如： 系统启动时自动装载x m l 文档描述的相应d l l 2 t i 1 7 请求调度 请求调度接受网络层输入的请求报文，根据请求报文的内容和插件对于请求 的支持进行对号入座的方式进行调度。 如果出现没有对于请求的服务存在，调度系统直接回复请求的客户端，说明 没有此项服务。 请求调度模块还可以提供查询该运行框架可以对那些请求进行服务，比如说 是否可以查询数据，是否具有告警服务，是否支持水利模型和智能决策服务等等 请求调度还会存在一些多线程，请求管理等方面的设计。 请求调度模块完成请求的管理，调度策略，以及效率优化的问题。 2 4 1 8 插件接口标准 异步回答 接受请求 i n te x e c u t e c m d ( s w i n gc m ds t r i n g ) 被动做出回答 i n tc m d a n s w e r ( s t r i n ga n s w e r ) ； 同步回答 主动做出回答的方式可能是向外面抛出事件或者是下面的做法 i n te x e c u t e c r n d ( s t r i n gc m d _ s t r i n g ，o u t s t r i n ga n s w e r ) ； 接受回答 i n tc m d a n s w e r r e c e i v e ( s t r i n ga n s w e r _ s t r i n 酌； 查询可执行的请求 i n tq u e r y c m d l i s t ( o u ta r r a y l i s tc m d _ l i s 0 ； 2 。4 。1 9 运行框架的客户端 运行框架的客户端从设计上来说应该也同样使用该运行框架，目的是为了保 持系统之间传输协议的统一，在某些具体应用当中，两个运行框架可能互相作为 客户端来交流。 2 4 1 1 0 运行框架执行流程 用户请求 回复 启动 配置网络连接 加载功能插件 网络模块开始服 务磊调! 赢 回复投有此服 请求调度结束此 次请求发回答案 图二、运行框架执行流程图 判断是否找到对应的 服务插件 做出回答 调用插 件服务 2 4 1 1 1 服务集群 运行框架可以很好的集成，组成提供某种服务的集群，拓扑图如图三 图三、服务集群示意图 实现关键就是为中心服务器提供插件，该插件的作用可以看作一个代理服 务，它将用户请求转交给具有相应服务功能的网络服务器。 2 4 1 1 2 类圈结构 图四、运行框架类图 2 0 2 4 1 1 3 运行协作 国阜囤囤囤 图五、运行框架运行协作图 2 l 2 4 2 插件技术 运行框架加载运行插件后使得框架具有插件的服务功，因此下面的任务将是 编写一大堆的运行插件。 运行插件的要求是满足框架对插件的接口约束，必须提供框架规定的接口。 图六、插件运行流程图 插件实际上是若干功能组合体，然后封装在一个模块里面，该模块提供框架 指定的接口，插件内部分析接口请求，然后分配对应功能函数进行执行。 对于本系统开发的插件对外公开接l j ，方便开发人员和用户对插件进行定 制，插件之间会互相通讯，以获得插件工作所必须的数据信息和决策方案等。 三、 数据中心总体设计 3 1 核心数据模型 3 0 1 1 数据模型定义 数据中心的此次设计注意针对应急指挥，因此核心数据模型是应急指挥的数 据模型。包括危险源，保护对象，应急资源，监控点等组成。 各个模型之间的关联如图七所示： 图七、核心数据模型关联图 核心数据模型是数据中心的原子数据，它对所有插件公开，在插件内部可以 直接使用这些模型。 核心数据模型还包括应急预案，突发事件等。 核心数据模型建立应该参照一些标准，如危险品就有国家标准。 3 2 对象模型的功能定义 3 2 1 对象： 对象是面向对象数据中间层中受应用程序之托而进行存储、修改和提取的元 素，对象可以像数字和串那样简单，也可以像电路的完整说明那样复杂。对象可 实现多种数据类型，包括图形、声音和视频，面向对象数据中间层优于传统数据 库的主要功能之一是它们能够把真实世界中几乎所有的实体部表示为对象，另 外，面向对象数据中间层可把数据安排到不相连的表中，对象可以包含其他对象。 这在定义新对象类型方面提供了很大的灵活性，对象使得应用程序的编写很简 单，因为特定实体的所有数据库都能在一个地方找到。对象除了能存放数据之外， 还能存放关系及行为，关系被表示为到其他对象的链，行为被表示为方法。 对象还可以加快应用程序的运行速度。因为有关一个实体的数据是逻辑相关 的，面向对象数据中间层具有优化这些数据的物理存贮的方法。应用程序可只读 取较少的文件，便能提取所有的相关数据。例如，在传统的c a d 系统中，通常 把设计的各个组件存放在各个独立的文件中，并用一个数据库来存放这些文件的 名字，要访问所有的设计，c a d 应用必须打开和关闭文件表中的所有文件。而 在面向对象数据中间层中，全部组件设计可以存放在一个对象中，这大大地减少 了访问设计所需的操作量。 3 2 2 方法： 面向对象数据中间层中的每个对象都可以包含作用于其数据的大量方法。当 应用程序发送消息给对象时，该对象中的方法就被激活。 把方法和数据封装在对象中的方法减少了程序员的许多程序设计负担，并把 数据提取和修改的任务留给了数据库本身。另外，虽然应用软件可执行数据完整 性检查，但若让数据库来处理这个问题会更简单，出错的可能性也会较小。如果 应用软件负责检查这些限制。则每个相关的应用程序都必须包含这些条件检查的 代码”并月，每次条件变化时，所有的应用程序都必须修改。相反，面向对象数据 中间层则不同，它把检查条件的方法和对象本身放在一起，这保证了每次有应用 程序访问数据对都进行完整性检查。另外，面向对象方法局域化了条件代码，因 而当限制条件改变时可以很容易地更改数据库。 3 2 3 继承性： 继承性提供了便于数据中心开发和维护的手段。更为重要的是它使得数据中 心具备稳步增长的能力，若使用得当，继承可以把新的特征和新的数据类型加到 数据库中，而只需进行局部的修改，关系数据库只有有限的内部数据类型集( 如 整数、串等，也只有有限的作用于这些数据类型的内部操作( 如提取一个域的值， 设置一个域的值) 。一个关系数据库设计者可以通过线性组合基本类型而建立较 复杂的数据结构，如记录中的域，但由于没有办法建立作用于这些新类型的新操 作，因而，对它们的操作仅限于为基本类型所定义的操作。面向对象数据中间层 把操作与类结合起来。新类可以通过予类化和重载所继承的方法从现有类中建 立，这就使得任意复杂的数据类型和操作在生成后就可取得与原来的类同等的地 位，这对于数据库的扩充和维护是非常有利的。 继承性不仅有助于定义存储在数据库中的数据的类型和关系的过程，而且它 还有助于方便地协调数据库的修改，用于类化技术能够方便地增加新的数据类 型，并能保证已有数据类型和方法不受这种改变的影响。由于数据库层次结构的 改变没有影响数据的逻辑相关性，因而继承机制可以方便地支持锁住、授权和查 询这样的数据库功能。 3 2 4 类： 预定义类库由核心数据模型本身提供，类库使得设计人员可以重用经常要用 到的数据结构，如数组、字典、表和日期等，而不用熏新定义它们。类库还包含 方法，如线性遍历或杂凑等。与面向对象语言进行编程类似，数据库开发人员可 以采用添加新方法、重载旧方法以及增加新的实例变量来修改类库和类层次等手 段来满足特定应用的需要。 3 2 5 持久性： 如一个对象在应用程序结束之后还继续存在，则该对象被称为具有永久性 的，对象永久性与对象标识的概念紧密相关，对象标识要求每个对象都有一个与 之惟一对应的、无论对象是否改变都不会改变的东西，对象标识使各对复杂关系 的有效处理能够进行。若对象相豆间的引用都是通过其唯一的对象标识实现的。 那么，即使对象的状态域位置改变了，也不会影响到对象之间的关系，对象标识 与基于值的数据库( 如关系数据库) 不同，在关系数据库中，实体是通过它们的 属性标识的，因而可能随时改变，换句话说，对象标识对于对象关系的永久性维 护是很有用的，这种对象及其之间关系的永久性需要种不同于关系数据库中所 用的对象删除机制。若在一个面向对象关系数据库中将一个对象简单地删去，则 别的对象可能还引用着该被删去的对象，这将导致错误，核心数据模型中一般的 做法是数据库不立即删除对象，而是删除对该对象的引用。当所有对被删除对象 的引用都被删除之后才删除该对象，然后收回该对象所占空间。 3 2 6 对象模型与关系数据库的映射 面向对象的模型跟结构化的关系数据库之间的映射是大部分企业应用都会 碰到的问题，这方面的应用非常成熟，在具体实施的过程中可以采用对象关系数 据库采用的技术，第一阶段计划实现简单的映射。 3 3 数据交换中心 数据交换中心处理实时数据的采集和存储，包括数据采集和数据消费模块。 3 3 1 数据采集 数据采集基本上分两部分：硬件的接口，一般产商会提供获取原始数据的接 口；另外就是对于配置采集数据的重新组合。 数据采集应该是对于每种采集设备做一个采集模块。 数据采集模块和数据消费模块之间通过协议配置定义一些采集数据的格式。 采集模式主动采集数据，被动采集数据，根据采集器具有的功能，可以配置采集 模式( 如g p s 采集，水、电、气表采集) 。 3 3 2 数据消费 数据消费模块主要完成对于接受到的数据进行处理，这个处理可以包括直接 存入关系数据库，部分存入g i s 服务部分存入关系数据库。用户可以通过自定 义插件来如何处理这些实时发送回来的数据。 数据消费模块可以根据消费的地点( g i s 或者r d b ) 等的不同做一些模块或者 按照用户特定的需求做一些模块即可，不需要对每个设备都做一套消费模块。 数据消费同时包括数据的粗粒度化等对采集数据的分类。 3 4 数据共享中心 数据共亭中心在二次开发人员和最终用户看来相当于一个面向对象的实时 数据库。 实时数据库是数据库系统发展的一个分支，它适用于处理不断更新的快速变 化的数据及具有时间限制的事务处理。实时数据库技术是实时系统和数据库技术 相结合的产物，研究人员希望利用数据库技术来解决实时系统中的数据管理问 题，同时利用实时技术为实时数据库提供时间驱动调度和资源分和应用特点，对 实时数据模型、实时事务调度与资源分配策略、实时数据查询语言、实时数据通 信等大量问题作深入的理论研究。实时数据库系统的主要研究内容包括： 实时数据库模型； 实时事务调度：包括并发控制、冲突解决、死锁等内容； 容错性与错误恢复； 访问准入控制； 内存组织与管理： f o 与磁盘调度； 主内存数据库系统； 不精确计算问题； 放松的可串行化问题； 实时s q l ： 实时事务的可预测性； 实时数据库系统最早出现在1 9 8 8 年3 月的a c ms i g m o dr e c o r d 的一期专 刊中。随后，一个成熟的研究群体逐渐出现，这标志着实时领域与数据库领域的 融合，标志着实时数据库这个新兴研究领域的确立。此后，出现了大批有关实时 数据库方面的论文和原型系统。 3 4 1 实时数据发布 对于某些实时监控点可以设置一些规则，对于某些数据的改变需要及时的通 知一些客户端。 中心推出数据，客户端被动接受。 实时数据发布也解决数据中心主动发送的问题。 实时数据发布通过各个需要实时数据的客户端在数据中心定义触发器，该触 发器定义了在什么情况下实时数据需要发布给该客户端。 3 4 2 实时数据查询 查询实时数据，客户端主动来获取数据。 实时数据查询获得的数据是经过系统重组，这些数据来源可能是关系数据库 当中，也可能是g i s 地理对象服务，或者是两者结合体的数据。 实时数据查询同样可以为客户定义查询，允许用户进行智能化和业务化的组 合。 若处理的是大量的数据，那么关键的问题是如何尽可能高效地搜索数据库。 在关系数据库中，查询优化利用了关系操作的代数特性和关系的物理结构。在一 个面向对象的系统中，没有针对所有数据的标准操作集，这是由于操作或方法是 根据各类型来定义的，更进一步说，无法普遍地确定任意两个操作是否可交换， 因而，标准查询优化技术是不可用的。在面向对象数据库申，可以采用”显露” 技术来解决这个问题。显露技术允许优化器检查类定义内部并询问有关它们原先 隐蔽的实现细节。虽然这一策略违反了类实现的私有性的面向对象规则，但由于 这一技术不对应用开放，所以不会造成全局性的副作用，另一方面，在面向对象 模型中，有时会存在涉及两种对象的组合查询。在关系模型中则需要一个链接， 并进行复杂的查询优化。在面向对象数据库中，有些优化是不必要的，因为每个 对象与其所有的成分信息都是存放在一起的。 3 4 3 数据压缩算法 当实时数据经过一段时间之后将成为历史数据，历史数据的对于智能决策的 帮助作用是不言而喻的。而实时数据的量相当之大，将其直接保存成为历史数据 对于存储的空间要求很大，因此是不现实的。这时就要引入了数据的压缩算法， 将大量的实时数据按照某种方式进行压缩。 3 5 数据源 数据源在系统当中充当对于应急核心数据模型的存储，访问和删除等的接 口，同时在数据源当中有高速缓冲的设计考虑，可以提高各个客户端的查询效率。 数据源的另外一个功能是同步多个存储媒介：如g i s 地理数据服务和r d b 关系数据服务，如g p s 的数据可能一部分存储在地理对象服务当中，另外一部 分会存储在关系数据库当中。 数据源作为一些插件提供数据服务功能。 3