软平台集成系统

软平台集成系统篇1

2009年2月6日收到随着航空发动机技术的不断进步,航空发动机控制系统也变得日益复杂。对航空发动机控制系统进行仿真一直是国内外研究的热点[1]。但从国内外资料来看,对航空发动机控制系统的仿真分析多是单独进行的,以数字电子控制或机械液压系统为切入点,很少涉及到数字电子与机械液压的协同仿真。目前,国内处于从机械液压到数字电子过渡的过程,既要通过传统的机械液压装置保障装备的可靠性,又要通过数字电子改善装备的性能,这就迫切要求搭建一个可以综合分析数字电子和机械液压控制系统的平台。使用该仿真平台既可以对既有机械液压控制系统进行改进改型,以挖掘潜力提升性能;又可以对数字电子控制系统的设计积累经验,降低试验成本。

1 仿真框架

对于航空发动机控制系统仿真,存在以下几个难点:控制系统的建模难度大;控制系统涉及多个学科,多学科协同仿真集成度高;基于高精度仿真模型的各种应用需求多,但目前的仿真功能实用性不强或过于复杂;各种模型和应用的可重用性低。为了解决上述问题,仿真框架按照MVC设计模式进行,整个仿真框架为三层,包括模型层、数据库层和应用层,其基本框架如图1所示。采用MVC设计模式,可以使整个仿真框架具有以下优点:

(1)低耦合性

模型层和应用层分离,这样就允许扩充模型层而不用更改应用层代码,只需要在数据库中加以配置即可。同样,一个新的应用模块的产生也不会对模型层产生影响。模型层与应用层的分离,使得可以单独扩展仿真平台的仿真模型和仿真应用。

(2)高重用性和可扩展性

高精度控制系统仿真模型是整个仿真平台的基础。在模型层的基础上,针对同一模型,可以开发不同的应用模块,满足不同的应用需求,仿真模型的重用性好,应用模块的可扩展性好。

(3)有利于软件工程化管理

整体软件仿真框架分层,每层完成其特定的功能,有利于仿真平台的工程化管理和工程应用。

1.1 模型层

模型层是整个仿真框架的基础,该层主要包括航空发动机控制系统的多学科联合仿真模型。航空发动机数字电子—机械液压控制系统涉及电子、机械、液压、气动等多个学科,单一的建模软件无法满足如此复杂系统的需要,因此需要采用多学科联合仿真的方法搭建系统的完整仿真模型[2,3]。模型层采用AMESim、Simulink和VC建立系统的多学科联合仿真模型,其结构框图如图2所示。

Simulink主要对控制算法进行建模,包括机械液压装置中完成计算功能的机械模块;AMESim主要用来对液压系统进行建模[4];VC主要用来建立航空发动机的模型。模型层中各模块通过软件接口建立联系,因此各个模块之间的联系不是一成不变的。整个模型层是一个开放的软件协作平台,是一个充满弹性的建模框架。例如使用EASY5或者HOSPAN代替AMESim建立液压系统的模型;使用C或者FORTRAN建立航空发动机的模型,但基于以下几点考虑,采用Simulink作为模型层的基础:

1)Simulink建模简洁,m语言使用方便,易于实现复杂数字电子控制算法的编程;

2) Simulink在仿真领域的领先地位使各个主流的专业仿真软件都提供了与Simulink 的接口,方便实现软件间的协同仿真[5];

3)可以通过S-function扩展Simulink的功能,与使用其它编程语言建立的航空发动机模型建立联合仿真。

1.2 数据库层

数据库是仿真平台的核心。在数据中主要存储并管理三类数据,仿真相关,管理相关,配置相关。仿真类数据存贮了每次仿真的相关信息,包括仿真模型信息,仿真参数信息,仿真M文件信息,仿真报告信息等。管理类数据主要用于管理仿真模型、各个仿真模型的仿真参数,以及用于用户管理的基本信息。配置类数据配置仿真平台,完成MVC仿真框架中controller的功能。通过在配置类表格中合理配置仿真平台相关的数据,可以组合不同的应用层模块,从而展现不同的应用功能以满足用户的多种需求。即对于同一个模型,面对不同的应用需求,可以生成相应的定制应用程序。

1.3 应用层

应用层提供了一组功能模块的集合,通过组合这些功能模块可以完成用户的定制应用需求,完成仿真框架中View层的功能。为了灵活展现不同的应用界面,方便仿真平台拓展应用功能,应用层的设计采用组件对象技术,将各个主要功能以组件的形式编写出来,降低各功能模块之间的耦合,各模块之间的联系通过数据库中的配置类数据加以管理。整体的应用层框架是松散的,各个子模块的功能是高度内聚的。图3展示了应用层结构以及完成控制系统联合仿真的一些基本功能组件。

1.4 仿真平台的功能

由于组件对象技术的良好扩展性,可以通过开发各种基于模型的应用组件,拓展仿真平台的应用功能。通过组合不同的应用模块,从而使仿真平台

满足多种应用需求:

(1)一键式仿真

由于多学科协同仿真模型涉及多个应用软件,每个应用软件都有各自的设置方法,各个软件的接口都有特定的接口设置流程,为了简化繁琐的参数设置和仿真设置步骤,我们通过数据库配置这些参数和仿真设置,再把相关的设置功能通过图形用户界面友好的提供给用户,使用户可以轻松设置各参数,完成一键式仿真。

(2)性能优化

对控制系统的优化可以通过两种方式完成。一种是基于模块级的,完成模块级别的优化,例如对于液压模块,AMESim 提供了NLPQL 和遗传算法两种优化方法;一种是基于整个仿真框架的,借助于Matlab/Simulink强大的运算功能和优化工具箱, 编写优化算法,完成对整个控制系统的优化。

(3)基于高精度仿真模型的自动调试

在复杂机械液压控制系统的生产过程中,调试是一个非常重要的过程,传统的调试方法主要参考调试大纲,凭借调试经验,调试工序复杂,调试难度高,调试成本昂贵。在控制系统高精度模型的基础上,一方面我们可以分析系统关键零/部件的参数变化对系统整体性能的影响,另一方面我们可以在仿真模型中考虑单个产品的生产加工差异,输入实际的加工尺寸,通过联合仿真获得产品的实际性能。在得到产品的实际性能和重要零部件对产品性能影响的基础上,可以通过仿真平台模拟这个调试过程,完成计算机辅助调试。

(4)数控/备份切换研究

针对航空发动机的数字电子—机械液压控制系统,对控制系统的切换研究一直是难点。通过在模型层中建立完整的数字电子控制器模型,机械液压控制模型以及切换部件模型,可以方便的在应用层加入切换研究模块,完成数控/备份切换系统的仿真研究。

2 仿真平台的实现

仿真平台的实现采用VB软件和ActiveX自动化技术:

2.1 VB软件支持组件对象技术

可以使用VB软件方便的建立各种COM组件对象,快速的建立应用层模块。VB可以作为组件容器,黏合各个功能组件。

2.2 VB软件对数据库编程支持较好

可以方便建立基于数据库的应用程序,有利于仿真平台应用层和数据库层的数据交互。

2.3 VB软件支持ActiveX自动化技术

可以方便和联合仿真模型的Matlab/Simulink平台建立ActiveX自动化服务器关系[7]。从而通过仿真平台应用层模块控制联合仿真模型的运算。

由于仿真框架的开放性和扩展性,仿真平台应用程序不是一成不变的,仿真平台根据数据库中的配置文件表现不同的图形化应用程序,但运行仿真功能是该平台的基础功能。图4以运行仿真为例介绍仿真平台的实现结构。一次基本的仿真运算涉及模型选择、参数设置、仿真设置、M文件生成、执行仿真、仿真报告等功能组件。上述功能组件均与数据库建立联系,一方面从数据库中读入数据或向数据库中写入数据,一方面按照数据库中的配置数据运行基本仿真流程。其中执行仿真组件作为控制端通过ActiveX自动化技术控制Simulink平台下联合仿真模型的运行,完成一键式仿真。

3 仿真平台应用实例

下面以某型涡扇发动机数字电子—机械液压控制系统为例,在该仿真平台的基础上,建立联合仿真模型,通过仿真平台运行NLPQL算法寻找加速过程的控制系统优化参数。

3.1 NLPQL算法

NLPQL算法是由Klaus Schittkowski提出的非线性优化算法,其解决如下形式的非线性带约束优化问题:

$\min_{x \in R^{n}} f (x)$

s.t.gi(x)≥0,i=1,...,m;

hj(x)=0,j=1,...,n;

xl≤x≤xu。

式中所有函数都是连续可微的,其中f(x)为目标函数,g(x)和h(x)为约束函数。NLPQL算法使用方便,鲁棒性强,适用于航空发动机控制系统的性能寻优。

NLPQL的内部算法是序列二次规划算法(SQP),其基本思想:构造非线性优化的拉格朗日函数如下:

$L (x, μ, λ) = f (x) + \sum_{i = 1}^{m} μ_{i} g_{i} (x) + \sum_{i = j}^{n} γ_{j} h_{j} (x)$ 。

用二次函数近似L(x,μ,λ),将非线性优化转化为二次规划子问题。通过在每个迭代点x(k)构造一个二次规划子问题, 以这个子问题的解作为迭代搜索的方向d(k), 沿该方向按照迭代格式x(k+1)=x(k)+akd(k)进行一维搜索, 使x(k+1)(k=0,1,...)最终逼近约束优化问题的解x*。

针对航空发动机的加速过程,需要尽可能短的加速时间,同时要求在加速的过程中不超温不超转。传统的加速性能寻优主要涉及加速供油量的理论优化,而忽视了加速供油量实现装置的优化,可操作性不强。通过该仿真平台,我们既可以优化加速供油量,也可以完成加速供油量控制装置参数的优化,具有较强的实用性。

3.2 联合仿真模型的建立

按照模型层的定义,完整的发动机控制系统联合仿真模型包括控制算法、液压执行机构和控制对象三个模块。图5为在Simulink中建立的控制算法模块,图6为使用VC建立并打包为S-function的控制对象模块。上述两个模块通过各软件之间的接口形成联合仿真的完整模型。

3.3 通过应用平台完成加速过程优化

通过分析该型加速控制器,确定影响加速性能的主要部件参数包括加速活门开度d1,压力传感器弹簧初始预紧力F0和转速传感器杠杆比kl。通过仿真平台设置上述三个参数的初始值和取值范围,运行NLPQL优化算法,完成加速过程控制系统部件参数的优化。通过计算,控制器部件参数设置为d1=-0.1 mm,F0=65 N和kl=2.2时,控制器可以正常工作保障加速过程不超温不超转,且具有最短的加速时间。图8显示了在该组部件参数设置下发动机从慢车推到最大状态加速过程的仿真结果。图7(a)显示了加速过程发动机供油量曲线,图7(b)显示了加速过程高压转子转速曲线,从图7上可以看出,转速平缓上升,加速时间短。

5 结论

针对航空发动机控制系统仿真分析遇到的问题,为了解决国内航空发动机控制系统数字电子与机械液压控制系统混合仿真的难题,搭建航空发动机控制系统集成仿真平台。仿真框架遵循MVC设计模式,降低了仿真模型和仿真应用的耦合,增加了模型的可重用性和应用的可扩展性。模型层以Simulink为基础,结合AMESim和VC建立联合仿真模型。应用层采用组件对象技术以方便拓展仿真应用功能。仿真平台的实现采用VB和ActiveX自动化技术。以某型航空发动机数字电子—机械液压控制系统为例,通过仿真平台运行优化算法寻找加速过程的控制系统部件参数。建模仿真分析过程表明该仿真框架显著降低航空发动机控制系统建模难度,可以完成复杂控制系统的高精度建模。仿真平台工程化程度高,可以满足航空发动机控制系统的产品调试、改进改型、性能提升等工程应用。

摘要：针对航空发动机控制系统仿真模型难以建立,仿真集成度不高,仿真功能不易用的问题,搭建航空发动机控制系统集成仿真平台。仿真框架遵循MVC(Model View Controller)设计模式分为模型层、数据库层和应用层。以Simulink为模型层的基础,结合AMESim和VC建立控制系统的联合仿真模型。以ActiveX自动化技术为基础,使用VB软件实现该仿真平台。以某型航空发动加速过程为例,建立联合仿真模型,完成仿真优化案例,验证仿真平台。仿真过程表明该仿真框架降低了建模难度,模型可扩充性好,仿真平台可以应用于航空发动机控制系统的集成仿真和工程应用。

关键词：航空发动机,控制系统,联合仿真,应用平台

参考文献

[1]缑林峰,王镛根.航空发动机控制系统故障检测仿真平台研究.计算机仿真,2007;24(12):74—76

[2]Larsson J,P.Krus,Palmberg J-O.Modeling,simulation and valida-tion of complex fluid and mechanical systems.ICFP2001,paper No.4.19

[3]王海伟,刘更,杨小辉,等.机械产品协同仿真环境及其关键技术.计算机仿真,2008;25(7):294—297

[4]卢宁,付永领,孙新学.单神经元在液压系统中的应用与电液联合仿真.系统仿真学报,2006;18(11):3180—3182

[5]黄先祥,马长林,高钦和,等.大型装置起竖系统协同仿真研究.系统仿真学报,2007;19(1):1—2

[6]宁芊,殷国富,徐雷.机电系统虚拟样机协同建模与仿真技术研究.中国机械工程,2006;17(13):1404—1407

软平台集成系统篇2

【摘要】提出了基于客户/服务器结构的地理信息系统集成平台总体结构，探讨了基于元数据的地理信息系统数据集成平台以建立物理上分布而逻辑上集中的分布式地理信息系统数据库，提出了应用符合3NF范式的关系数据库进行模型管理的模式，在此基础上探讨了地理信息系统可视化建模工具。

【关键词】地理信息系统 集成平台框架结构 GIS数据集成平台 GIS模型集成平台可视化建模工具

1 引言

近年来，随着GIS应用的广泛和深入建立了一大批地理信息系统。随着网络技术的发展和实际的需要，这些分散的系统要求集成运行，以实现信息共享，提高运行效率。在国家“八五”攻关中就开展了这方面的研究[1，2]，在“九五”攻关中对系统实用化和运行业务化提出了更高的要求。地理信息系统集成的重要性得到普遍的认识[3，4]。

地理信息系统集成可以分为两个层次，一个是地理信息之间相互关系的概念层次集成，侧重于地理信息的空间分析;另一个是不同数据和模型之间组织和管理的技术层次集成。本文所指的地理信息系统集成主要指后者意义上的集成。

在计算机集成制造(Computer Integrated Manufacture System， CIMS)领域，集成基础结构或集成平台的概念得到广泛的应用，集成平台被认为是实现企业信息集成、功能集成所需的基本信息处理和通信公共服务的集合[5]。IBM公司基于系统使能器(Enabler)的集成平台在企业应用中获得极大成功[6]，中国在CIMS应用中也广泛使用集成平台技术[7]，收到巨大的经济和社会效益。

文献[8] 中作者论述了地理信息系统集成的概念、内涵和必要性，地理信息系统集成平台的功能和特点。本文借鉴CIMS的经验，结合信息技术的新发展，提出了基于客户 /服务器的地理信息系统集成总体结构，基于元数据的地理信息系统数据集成平台和基于关系数据库的地理信息系统模型集成平台和可视化构模工具方法。

2 地理信息系统集成分析

回顾地理信息系统的发展过程，可以看出地理信息系统的集成在技术上可以分为如下几种形式：

(1) 同一GIS软件系统不同模块之间或不同系统之间采用Import/Export的文本文件交换形式。这是最简单也是效率最低的一种方式，它适用于任意系统之间的数据和模型集成。

(2)大型商业GIS软件如ARC/INFO具有一致的数据模型和数据结构，提供二次开发语言，构成软件开发平台。不同模块之间可以采用二进制进行数据交换(如 Arcedit和Arcplot)，具有密切关系的不同GIS软件系统之间也可以采用这种方式(如ARC/INFO和ERDAS)。在这种模式下用户除了在操作系统的基础上开发应用模型被宿主系统调用外，其它所有的操作只能建立在这个商业软件平台基础上，不同的商业软件平台一般无法直接进行数据共享和功能互补。

(3)采用应用程序接口(API)的形式进行集成。如ARC/INFO提供RPC接口实现客户端与服务器端的通讯，提供ARC/INFO与ARCVIEW的集成。同时用户可以遵循RPC规范开发应用模块以实现系统集成。ESRI提出的分布式计算环境(Distributed Computation Environment)也是基于API的思想。

(4)对象连接与嵌入(OLE)的自动化功能(Automation)提供了对象之间的互操作功能，一些最近开发的商业GIS软件如Mapinfo公司的 MaplnfoProfessional和Golden Soft公司开发的Surfer，都提供OLE Automation，用户可以将该软件作为一个对象嵌入自己的系统。

(5) 最近发展起来的对象―关系数据库技术(ORDBMS)将空间数据作为一种数据类型直接集成进入数据库系统，用户可以在这种平台上直接管理矢量空间数据、遥感图像数据和普通关系数据，可以利用这种数据库平台的API开发GIS应用系统。

(6) OPENGIS组织采用COBRA标准，发布了其简单特征规范(Simple Features Specification)1.0版本作为开放地理信息系统的基础，这无疑是地理信息系统软件向开放和互操作发展的重要方向之一，但这种方式需要从底层重新开发GIS软件，在短期内很难直接应用于工程实践。

在以上地理信息系统集成的各种形式中，都存在如下的问题需要解决。

(1) 地理信息采集和应用的分布性特点决定了地理信息系统的分布性，地理信息系统集成需要一种分布式空间数据管理和分析模型的相互通讯机制。这种机制既可以适应在目前比较成熟的基于数据文件交换形式(如(1)和(2))，又可以为以后基于API(如(3)和(5))面向对象的地理系统集成(包括(4)―(6))提供发展余地。

(2) 地理信息涉及不同的时间、空间和属性，需要有一种有效的地理数据管理的机制，并提供数据融合的能力。

(3) 地理分析模型与多种地理数据发生联系，不同模型之间有复杂的串并联关系，模型的组织与管理是需要解决的另一个重要问题。

基于以上的分析，本文提出了基于客户/服务器机制的地理信息系统集成总体结构，基于元数据的数据库集成平台和基于关系数据库管理系统的模型集成平台，以及在系统总体结构和数据库集成平台、模型集成平台的基础上进行可视化建模以辅助空间决策的方法和技术。

3 基于客户/服务器的地理信息系统集成总体结构

近年来，客户/服务器(Client/Sever，C/S)体系结构在分布式系统中得到了广泛的应用。尽管这种模式至今还没有一个完整的权威性定义，但人们对这个概念的基本看法是一致的。在C/S结构下，一个或更多个客户机和一个或更多个服务器，以及下层的硬件网络、操作系统和支撑平台进程间通信系统，共同组成一个支持分布式计算、分析和表示的系统，在该模式下，应用分为前端的客户部分和后端的服务器部分。客户方发出请求，网络通信服务系统将请求的内容传到服务器，服务器根据请求完成预定的操作，然后把结果送回客户。

地理信息系统集成平台引入客户/服务器机制后，可以将地理信息系统集成定义为两层C/S结构(图1)。前端用户和数据库集成平台、模型库集成平台、应用模型构成第1层C/S结构，集成平台和应用模型与商业软件构成第2层C/S结构。客户端负责引导用户输入数据源、功能要求和模型选择，以及有关输入输出选择项，将这些信息提交模型集成平台服务器和数据集成平台服务器。模型集成平台服务器负责在模型库中检索符合用户功能要求的模型，并支持模型的组合和建立新的模型，然后将这些模型(包括模型库中已有的和通过宏语言或API新建的)对数据的要求提交数据集成平台服务器，其功能请求转化为RS服务器、GIS服务器、RDBMS服务器可以实现的基本操作并提交给这些服务器。数据集成平台服务器、RS、GIS、RDBMS服务器操作结果将返回给模型集成平台服务器，进而返回给客户端。

当客户端有特殊的显示、制图要求时，模型集成平台服务器将负责根据用户的要求调用其它服务器来实现;如果客户端要求将模型运行的结果进入数据库时，模型集成平台将向数据集成平台服务器发出请求，完成在数据库中的`注册。数据集成平台服务器除了接收模型集成平台发出的请求外，还可以直接响应按照时间、空间和属性信息数据查询的要求，在空间框架的基础上实现多元数据的融合，数据集成平台的功能也是调用RS、GIS、RDBMS服务器的功能来实现的。模型与数据库之间、模型与模型之间即可以采用IMPORT/EXPORT的文件交换形式(如ARC/INFO的E00格式等)，也为将来全部过渡到API的内存交换形式(如DLL，OLE，ActiveX，COBRA等)提供可能。

这种设计使得系统只考虑软件的功能而不会过分依赖于具体的软件平台，因此系统具有良好的可扩充性，无论采用商业软件还是采用国产软件，只要具有该项功能可以作为服务器，服务器软件类型的变化都不会影响系统结构，便于将来采用国产软件和系统的升级换代。

4 基于元数据的地理信息系统数据集成平台

地理信息系统数据库集成平台的目的在于形成物理上分布而逻辑上集中的整体数据视图。实现方式可以采用基于元数据的方式，也可以采用基于空间开放数据库连接(Spatial Open Database Connectivity， S-ODBC)的结构化查询语言(Structure Query Language， SQL)和动态连接库(Dynamic Link Library， DLL)方式，以及基于面向对象的方式，如分布式公共对象模型(Distributed Common Object Model， DCOM)和公共对象请求代理结构(Common Object Request Broker Architecture)等方式[8]。由于大型业务化运行的地理信息系统大都建立在商业软件的基础上，很少全部从底层开发，而目前绝大部分商业软件都不支持这些软件协议机制。从实用角度出发，基于元数据的集成平台是一种行之有效的地理信息系统数据集成模式。

软平台集成系统篇3

〔关键词〕知识管理；知识管理系统；XML；面向集成

〔中图分类号〕G35 〔文献标识码〕B 〔文章编号〕1008-0821(2009)04-0210-04

XML-based Integrating-Oriented Knowledge Management System PlatformQiu Zhijun1，2Deng Yong2

(1.Graduate School of the Chinese Academy of Sciences，Beijing 100049，China；

2.Chengdu Branch，National Science Library of Chinese Academy of Sciences，Beijing 100049，China)

〔Abstract〕Traditional knowledge management tools and system often only focus on one special aspect，so its difficult to integrate them into a whole knowledge solution.This paper proposes the concept of XML-based integrating-oriented knowledge management system.This system can integrate kinds of existing knowledge management tools to construct knowledge management platform on demand.Thanks to XML relative skills，its possible to integrate knowledge acquisition，storage，communication，and display into a union architecture.

〔Key words〕knowledge management；XML；Integrating-Oriented

1 知识管理系统

知识管理是通过一组问答序列，即解决方案的集合寻找和识别与问题有关的关键性信息，并将这些信息进行提取，形成对某一问题的专门知识，作为决策的依据。知识库是企业知识管理系统的核心，它按照一定的知识表示方法，如基于规则的知识表示、基于逻辑的知识表示、基于语意网络的知识表示等，集中存放关于企业内部各专业领域的知识和与企业有关的外部环境的相关知识。

知识库管理系统是管理知识库的一组软件，包括知识发现获取系统、知识储存分类系统和知识创新利用系统，主要实现企业知识的获取、储存、分类、搜索等功能。知识可分为外显知识和内隐知识。在知识库管理系统中，企业的外显知识主要来源于业务数据仓库，是由企业信息管理系统收集、传递、储存、加工、维护和使用的数据或文件等信息，也有部分来源于知识专家的总结、归纳及知识管理人员由知识互动系统中的提取。企业的内隐知识则主要来源于知识互动系统。

对于知识管理系统(KMS)目前还没有统一的定义，学者各自基于其对知识管理的认识提出了一系列的不同观点，大体上可以分为两种观点：(1)技术与工具观，(2)系统观。技术与工具观认为KMS是实现知识管理的工具、知识管理技术或知识管理系统软件，或上述几项的集合，也可以称之为狭义的知识管理系统观。系统观将系统的观点引入知识管理的研究中，认为KMS不仅仅是工具、技术和软件等的集合，而是将知识管理的几个要素如：技术、企业文化、人和知识运动的过程等集成考虑的综合系统，也可称之为广义的知识管理系统观。

2 XML和XML Schema

XML(eXtensible Markup Language)意为可扩展标记语言，它包含了一组定义语义标记的规则，可以定义特定领域内标记语言的语法结构。作为元标记语言，XML允许开发者生成自己需要的标记，这就使得标记的含义可以很灵活，可以满足不同开发者的需求。XML Schema则是W3C XML模式工作组创建的模式语言，是当前创建特定领域内标记的两种主要方式之一。

Schema与XML是紧耦合的，用于协作完成具有一定语义表示能力的结构化的XML文档，二者之间的关系如图1所示。图中，XML规范定义了用于描述标记语言必须遵循的元语法结构，它描述的是底层语法结构的规则。如何区分标记和内容，如何将属性附加到元素上之类的规则，而不是描述这些标记、元素和属性是什么或者它们的含义是什么。Schema规范则主要用于描述XML文档中的标记、元素和属性是什么，或者它们的含义是什么以及必须遵循什么样的约束等，即用Schema模式语言描写的模式文档(一个模式文档即定义了特定领域的一种具体标记语言，又可称为词汇表或XML应用)定义了可用在XML文档中的元素、属性、实体和标记的表示方法，以及这些内容之间可能的相互关系，它描述的是一种语义结构。同时，书写模式文档本身的元语法结构遵循的是XML规范，即模式文档本身也是一个XML文档，只是该XML文档所用的标记是由Schema模式规范定义的而已。

3 基于XML的面向集成知识管理框架

3.1 国内外研究

国内学者李克胐在2001年提出了一种基于XML的知识管理系统模型。该模型由智能代理、多文档转化接口、内容管理、知识发布与共享工作流协同、决策支持、XML与数据库接口、知识管理数据库8部分构成。基于XML的知识管理系统与其他知识管理系统相比，具有如下优势：统一、良好的文档结构；易于统一存储，便于分类管理；采用Web浏览器；通过XML在Web上实现知识发布与共享；具有基于元数据的快速搜索，检索效率高的特点；能较好地实现异构系统的传递；具有技术上的先进性，代表未来的发展方向。由于基于XML知识管理系统的这一系列优点，国内外学者、研究人员对基于XML知识管理系统的研究日益深入。

在国内，比较有代表性的是中国科学院计算技术研究所智能科学实验室研制的知识管理系统KMSphere。KMSphere系统主要采用OWL、RDF、语义网等XML技术作为知识的表达、存储、展现基础，并提供通过本体的相应推理机制，从现有信息、文献中自动挖掘出相关知识的机制，大大简化了知识本体的构建。

在国外，早在2000年初，德国GMD-IPSI(德国国家信息技术研究中心集成出版和信息系统研究所)的研究小组，联合西班牙、法国、奥地利等国的研究机构，开发了XML-KM(IST-12030)系统。图2就是经过了简化的XML-KM(IST-12030)系统结构。可以看出，信息的采集(集成)、知识的发现和抽取、知识的发布，3个层次较为分明地体现在系统中。该结构基本概括了以XML为基础的知识管理系统的主要内容，因此在业界有着一定的影响，在一段时间以来成为研发知识管理系统的重要参考。

最近几年，由于XML技术的发展、成熟，涌现出一批成功的商用XML知识管理系统(主要针对企业用户)。国外的有，加拿大的IXIASOFT公司在北美市场推出的相关知识管理产品，美国IPEDO公司在美国和亚太地区推出的KCP(知识协同平台)产品，国内的产品中，较有代表性的有长沙麓谷数码科技公司的基于 XML的企业协同工作与知识管理平台。图3显示了当前商用XML知识管理系统的基本框架。

这些商用基于XML知识管理系统的特点主要有：(1)异构数据源的集成：通过各种适配器集成各种数据源。(3)知识建模和整理加工：应用在XML数据库基础上的知识建模和知识发现过程，大量应用了XML相关技术、规范。(3)企业级应用的中间件组件库。(4)基于XML的门户系统：一个企业或单位的XML知识管理系统的统一对外窗口就是门户(Portal)系统，门户中集成了各种形式的知识展现形式。本文关注XML知识管理系统对外围应用的集成，为构建可适应性知识管理平台提供保证。

3.2 基于XML面向集成的知识管理系统

知识管理的核心在于知识表示和知识库的创建，通过对当前基于XML知识管理系统的调研，可以发现它们都存在一个集中的知识库和一个统一的知识表示形式。本文创新性的提出构建一个知识管理框架，用以集成现有应用，如Xwiki这样的wiki系统，这样新的系统在获得稳定性的同时能够随知识管理的需求不断扩展。面向集成的知识管理系统只需要关注知识管理的核心功能——知识表示、知识库，并通过提供XML文档形式的集成入口提供外围系统集成。

3.2.1 基于XML的知识表示

在XML中，数据对象使用元素描述，而数据对象的属性可以描述为元素的子元素或元素的属性。XML文档由若干个元素构成，数据间的关系通过父元素与子元素的嵌套形式体现。在基于XML的知识表示过程中，采用XML的DTD来定义一个知识表示方法的语法系统，通过定制XML应用来解释实例化的知识表示文档(图4)。

3.2.2 基于XML数据库的知识库

近两年来，随着XML数据库技术的不断发展和成熟，基于XML的知识管理系统的研发和推广日益深入。知识管理中初始文档大多是半结构化和非结构化的文档，例如Word格式、E-mail、Web页等，而对于半结构化的知识表示，XML是一种很好的描述语言。在对知识管理系统中的知识进行表示时，一方面要考虑用户的习惯和差异性，另一方面要考虑到知识源的多样性和对已有系统的利用。而XML技术的诸多特点适用于知识管理系统中知识的表达、集成与传播，为分布、异构的软硬件环境下的知识管理提供了一个全新的思路。在知识利用过程中，通过维护数据字典和XML解析程序把特定标签所标注的内容解析出来，以“标签”+“内容”的格式表示出具体的知识内容。知识表示是构建知识库的关键，知识表示方法选取得合适与否不仅关系到知识库中知识的有效存贮，而且也直接影响着系统的知识推理效率和对新知识的获取能力，图5中给出了基于XML的知识库的创建过程。

3.2.3 基于XML的知识集成

在对知识管理系统中的知识进行表示时，一方面要考虑用户的习惯和差异性，另一方面要考虑到知识源的多样性和对已有系统的利用。而XML技术的诸多特点适用于知识管理系统中知识的表达、集成与传播，为分布、异构的软硬件环境下的知识管理提供了一个全新的思路。因此，一个面形集成的知识管理系统的核心在于建立一个统一的基于XML的知识表示，和通过各种适配器将各种来源的数据统一转化成特定模式并构建出一个中央知识库。图6给出了基于XML的知识集成过程：

3.3 系统总体架构方案

在解决了底层的知识表示、和知识库的构建问题后，本论文提出一个更高层的系统总体架构形式。如图7所示，新的系统架构将主要包括以下4个模块：

(1)知识集成模块设计

(2)知识存储(知识库)模块设计

(3)知识表示模块设计

(4)上层应用基础接口API

在集成层我们采用了灵活的注册数据源提供模式，只要针对特定的数据源格式做相应的适配即可实现知识的有效集成，同时由于遵循一致的知识表示形式，使得知识的利用也极为方便。

4 在面向集成知识管理系统中集成常见的Web2.0工具范例Web2.0是涵盖Blog(博客，包含声音、文字、图像、视频、让个人成为主体)、Wiki(维基)、RSS(简易聚合)、Tag(分类分众标签)、Social Bookmark(网摘)、SNS(社会性网络系统)等应用元素以及XML-RPC、Web Service、开放式APIs(开放式应用程序接口)、Folksonomy等技术范式，围绕用户参与、共享与协同而实现的新一代互联网模式。本论文选取开源wiki系统Xwiki为集成研究示例。

Wiki指一种超文本系统。这种超文本系统支持面向社群的协作式写作，同时也包括一组支持这种写作的辅助工具。我们可以在Web的基础上对Wiki文本进行浏览、创建、更改，而且创建、更改、发布的代价远比HTML文本要小；同时Wiki系统还支持面向社群的协作式写作，为协作式写作提供必要帮助；最后，Wiki的写作者自然构成了一个社群，Wiki系统为这个社群提供简单的交流工具。与其它超文本系统相比，Wiki有使用方便及开放的特点，所以Wiki系统可以帮助我们在一个社群内共享某领域的知识。XWiki是一个强大的Java开源的Wiki引擎。它支持一些受欢迎的特性如：(1)内容管理；(2)版本控制；(3)全文本搜索；(4)RSS输出与显示外部的RSS feeds；(5)提供XML/RPC的API；(6)WYSIWYG HTML编辑器等。

由于Xwiki提供RSS输出功能，因此我们可以很容易的将Xwiki集成到我们的知识管理系统中。如图8所示，通过构建适当的XSLT转换程序我们就能将采集到的RSS装换成系统内部的基于特定XML Schema的知识表示形式，然后存储到XML知识库实现Xwiki数据源的集成。

5 结语

本论文通过基于XML的知识表示的核心概念，实现了一个知识管理的基础平台，该平台仅关注知识管理中最核心的知识表示和知识存储功能。通过给该平台提供一个统一的数据源适配集成层，实现平台同各种外围数据源的有效集成。最后本文给出了一个集成Xwiki系统的集成范例。面向集成使得我们能够从特定领域的细节中解脱出来，为构建一个通用的知识管理框架提供了基础。同时，由于框

架本身的抽象性，系统获得了更大的适应性，能够适应各种特殊的复杂应用环境。

参考文献

[1]邱均平，段宇锋.论知识管理与信息管理[J].中国图书馆学报，1999，(6)：12-18.

[2]王珏，袁小红，等.关于知识表示的讨论[J].计算机学报，1995，18(3)：212-224.

[3]吴胜，刘玉.基于XML知识管理的研究[J].福建电脑，2003，(11)：9-11.

[4]鲍军鹏，等.基于XML的知识融合与知识库组织[J].计算机工程，2003，29(3)：56-57.

软平台集成系统篇4

为了解决以上问题,之前也进行了一系列研究,希望寻需求一种能够解决以上所有问题的单一解决方案,但答案是否定的。目前, 虽然系统之间的数据共享在数据交换层面解决了信息孤岛问题,但对于患者来说,在医院所产生的各种数据还是分散存在于门诊、住院、LIS、PACS、体检等系统中。虽然电子病历系统整合了患者在院就诊的大部分数据, 但若想全面了解患者就诊的各种信息,还需分别通过不同系统来查询。对医院各级管理者来讲,要想了解全面的医院运营信息,也要通过综合不同系统的信息来完成。信息孤岛的问题还没有得到真正的解决。

现在市场上针对部门级系统的互联及协同工作有许多不同的解决方案,互联协同工作是从供应商的角度来看问题。从信息科主任的角度看, 仅仅通过系统互联消除信息孤岛是远远不够的。理想的方案是在不同应用系统之间,根据需要进行数据传递的同时,在整个医院(甚至更大范围,如分布在不同地理位置的多个院区或区域医疗集团)进行信息共享。这样可以在一次数据传输的同时完成全部有价值数据的采集和抽取, 便于下一步进行数据深层次的挖掘及利用。但目前的大多数互联或协同工作方案还无法满足这个层次上的信息共享需求。鉴于此,也进行了大量的市场调研, 最终发现联众的数据集成平台, 并与之合作。

2联众数据集成平台的方法和技术

2.1集成平台构成

该平台由一个基础支撑平台以及在此之上提供的一系列加速器、适配器、基础服务组成;接入平台的系统符合现有的技术标准(MLLP、Web Services等),平台之上传输的信息符合HL7标准并兼容IHE相关标准。其主要的功能组件如下:

基础支撑平台(ESB):为信息集成平台提供基础的运行支撑平台,提供服务定义、服务发布、服务注册、服务发现、服务绑定、服务协作、事务协调、服务质量管理等主要功能。

HL7 Accelerator:HL7加速器 , 该加速器负责将各个系统发往信息集成平台的数据格式化为HL7标准, 并根据需要转化为特定的目标格式 ; 并提供消息的路由功能 , 可以根据HL7 Message的MSH标识将消息路由到目标系统。

Process Manager: 流程服务 , 现有应用程序与更新的应用程序相集成,以便它们透明地协同工作,实现在业务逻辑层支持业务流程集成、业务流程再造、业务流程自动化和业务协同。

适配器: 提供了一系列的接入适配器, 主要包括MLLP、 Web Services、MQ、MSMQ、Socket、SMTP、FTP等接入方式 ,以满足不同厂商的产品快速接入到信息集成平台。

2.2平台遵循标准

联众医院信息集成平台采用了业界公认的相关标准, 方便第三方应用以标准方式接入,主要分为以下两类:

2.2.1技术标准

该平台的技术标准主要采用了MLLP标准, 同时由适配器提供对Web Services、MQ、MSMQ、Socket、SMTP、FTP等标准的支持。 MLLP(Minimal Lower Layer Protocol,MLLP)是由HL7标准化组织提出的一个通讯标准,该标准是在TCP / IP协议之上的一个符合医疗信息传输需要的通讯标准。

2.2.2数据标准

该平台的数据标准主要采用了HL7 v2.3.1标准, 同时兼容IHE标准 ,由于HL7并没有对信息域部分进行定义 ,因此数据域部分大量采用了国标(GB系列)。 HL7(Health Level Seven)是由美国ANSI组织批准实施的医疗卫生标准,该标准参考了国际标准组织(ISO),采用开放式系统互联(OSI)的通讯模式,将HL7纳为最高的一层,也就是应用层。自其2.1版正式颁布以来,在医疗卫生机构,特别是医院的影响力日益广泛,目前在全球HL7标准已有很多厂商及医院支持与使用。中国也于2000年初建立了HL7中国协作中心。

3数据集成平台的效果

全面的优化和整合医院内部的资源以及医院外部全社会的信息资源;为医院临床,管理服务,运用所有的信息资源为患者提供先进的,便捷的,人性化的医疗服务; 同时建立全院科研教学的信息平台和数据仓库;以提高医院服务水平,技术水平及管理水平,提高医院的整体经营效益。

建成后的质量监测平台应用上能涵盖医院内部客户资源、资金资源、物流资源、医疗信息资源、人力资源的管理以及与外部资源的整合和优化,统计分析医院精细到个人的工作量、业务数据等,使医院各个科室、部门以及病人可以在各自的权限内取得需要的信息或输出必要的信息,实现信息实时交流,同时通过对大数据的挖掘钻取,提升整体的医疗科研分析能力,从而实现全面的数字化管理,促进医院两个效益的全面提高。

4建设体会

建筑 设备管理系统集成平台的优化篇5

建筑设备管理系统 (BMS) 是将建筑物内的空调与通风、变配电、照明、给排水、热源与热交换、冷冻与冷却、电梯与自动扶梯、停车库等建筑设备以集成监视、控制和管理为目的, 与公共安全系统等实施联动管理而构成的综合系统;主要通过网络将分布在各监控现场的区域智能分站连接起来, 以分层分布式控制结构完成集中操作管理和分散控制, 确保建筑物内所有设备处于高效、节能、安全可靠的最佳运行状态。

与此同时, 建筑设备管理系统应与公共安全系统实现联动管理, 即对相关的公共安全系统进行监视及联动控制, 包括消防报警子系统和安全防范子系统中相应的视频安防监控 (录像、录音) 系统、门禁系统、停车场 (库) 管理系统等对火灾报警的响应及火灾模式操作等。例如发生火灾时系统自动报警, 启动并控制自动灭火系统、紧急广播、事故照明、电梯、消防给水、排烟系统、空调系统、其他联动控制系统, 以及消防电话系统等。

建筑设备管理系统 (BMS) 的功能应符合下列要求:

(1) 应具有对建筑机电设备的测量、监视和控制的功能, 确保各类设备系统运行稳定、安全可靠, 并达到节能和环保的管理要求。

(2) 宜采用集散式控制系统。

(3) 应具有对建筑物环境参数的监测功能。

(4) 应满足对建筑物的物业管理需求, 实现数据共享, 生成节能及优化管理所须的各种相关信息分析数据和统计报表。

(5) 应具有良好的人机交互界面且采用中文界面。

(6) 应共享所须的公共安全等相关系统的数据信息资源。

2 常用系统集成模式存在的主要问题

智能建筑设计的核心是“系统集成”, 它包括三个层次的含义:功能集成、技术集成和信息集成。其中信息集成是主要目标, 通过具体的信息技术与建筑环境的结合实现建筑智能化, 具有开放性、可靠性、容错性和可维护性等特点。

建筑智能化集成系统把所有子系统集成到统一的信息共享集成平台上来, 为各个子系统的维护和运行管理提供一个管理中心;目的是建立整体的信息管理和信息流动机制, 建立全局的互动机制, 建立统一的管理界面, 完成信息的收集、控制、存储和整理工作。通过对建筑物和建筑设备的自动检测与优化控制, 实现信息资源共享、优化管理和为使用者提供最佳的信息服务功能, 使智能建筑达到投资合理、适应信息社会需求的目标。

建筑智能化系统集成分狭义系统集成 (BMS) 和广义系统集成 (IBMS) 两类。狭义系统集成包含两个层次:第一层次为独立子系统纵向集成, 目的是在BMS这一层实现各子系统具体的功能;第二层次为横向集成, 主要体现于各子系统之间的联动和优化组合。广义系统集成是一体化集成, 在横向集成的基础上, 建立综合集成管理系统 (IBMS) 。一体化集成 (IBMS) 通常采用以建筑设备管理系统 (BMS) 为核心的集成模式, 通过开发与各种第三方系统的网络通信接口, 将各种子系统集成到建筑设备管理系统 (BMS) 中。目前国际上常用的系统集成模式主要分为以下两种类型:

(1) 基于网关路由器等硬件接口的系统集成模式:

(1) 通过干触点连接。

(2) 将其他厂家的系统或设备直接连到现场控制总线上。

(3) 使用兼容控制器等设备。

(4) 利用厂家提供的BACnet网关集成BACnet系统及设备。

(5) 利用厂家的Network Port网关路由器集成其他工业总线如Modbus, AB Bus、EIB Bus等。

这种集成模式的主要特点是通过简单的硬件I/O触点来简单联动, 因而集成深度不够, 功能单一, 无法实现复杂的集成应用, 同时系统稳定可靠性差, 很难满足用户实际需求。特别是当需求发生变化后系统无法适应, 便不得不由专业公司进行改造, 但建成后很难使用, 导致系统综合效应无法发挥出来。

(2) 基于Windows软件接口的系统集成模式:

采用企业网络系统中的计算机平台。通过使用一些通讯协议如DDE、OLE、OPC、ODBC方式, 可以将IIS、OA、CA的主要系统进行集成, 前提是所有子系统都提供较高层次的互联方法。

这种集成模式的主要特点是通过电脑工作站的Windows软件接口 (如OPC接口等) 来集成, 由于很多子系统均是通过串口与子系统管理工作站连接或与设备管理工作站的串口服务器连接, 如果其中任何一台工作站没开机或发生了故障, 造成启动接口驱动软件或操作失误, 那么系统集成功能就无法实现, 因此, 集成系统的实际可用性极差。在Windows环境下还容易受到病毒的攻击, 系统的稳定性和安全性也难以保证。

更重要的是, 通过工作站 (上位机) 进行集成, 各子系统的控制域数据交换是在不同系统平台之间通过数据接口转化并协同工作, 速度特别缓慢, 不能达到实时性要求, 如报警系统产生报警, 信号从底层传到服务器的数据库, 系统根据报警信号的产生点, 通过一套制定好的程序查找闭路电视监控系统数据库, 再启动闭路电视监控系统, 将报警产生点的监视画面放大到全屏幕, 这个过程至少需要数秒钟。

3 建筑设备管理系统中全局事件的分类

集成管理的目的不是为了把各子系统联结, 而是为了确保建筑设备管理系统 (BMS) 功能的实现, 以及在较为明确的管理需求下, 为事件处理提供自动化操作系统和规程。把那些与管理需求相关的子系统集成起来, 达到为业务管理而集成的目的, 从而实现整个系统对全局事件迅速响应的能力。

从建筑设备管理系统功能需求的角度上来看, 不论是狭义系统集成 (BMS) , 还是广义系统集成 (IBMS) , 系统集成涉及的范围可以划分为控制域和信息域两部分。其中控制域中的系统特点是系统所采集的信息均来自现场, 控制信息针对于现场, 要求信号实时性强;信息域中的系统特点是信息量大, 系统信息来自于数据库、终端录入设备或其他系统, 信号要求交换能力强, 传递速度快, 但对实时性要求不强。对于整个建筑智能化系统而言, 控制域是它的基石, 信息域是它的灵魂, 两者通过计算机网络有机地结合在一起。

在建筑设备管理系统中全局事件分为三类:

(1) 与控制系统相关的控制域全局事件。当某些事件发生后, 建筑智能化系统中多个子控制系统作出反应, 具体体现在子系统的联动上。如安防联动、消防联动、主要设备突发故障的全系统联动等。

(2) 与业务管理需求相关的信息域全局事件。当业务管理上发生某种请求后, 需要读取多个管理子系统的数据, 形成一组具有具体业务含义的数据, 并以图表等形式表达出来。如内部资金管理、设备管理、能源管理、信息汇总等。

(3) 既与业务管理系统相关又与控制系统相关的全局事件。当业务管理上发生某种请求后, 需要读取多个子系统的数据, 在对这些数据处理的基础上, 对控制系统的设备动作产生影响, 如身份识别等。

4 建筑设备管理系统集成的优化设计

为了对建筑设备管理系统中发生的全局事件进行自动化处理, 以往智能建筑系统集成最常用的方式大都是单纯采用信息域系统集成平台的总体结构, 虽然应用的案例不少, 但真正成功的案例并不多。其主要缺点首先是控制信号实时性差, 其次是系统可靠性差、稳定性差、故障率高。所以采用这种集成模式的智能建筑在建成之初, 集成系统的运作似乎是正常的, 但过不了多久, 随着系统故障的频率越来越高, 问题便越来越多, 导致物业管理操作人员对其逐渐失去使用的兴趣, 弃而不用, 改为手工控制。

为了克服单纯采用信息域系统集成平台总体结构的缺点, 建筑设备管理系统集成优化设计根据控制域和信息域的不同特点, 选用不同的技术手段, 采用“既分别处置又协调一致”的处理原则, 将系统控制域、信息域的功能与实施技术手段相结合。系统集成平台由控制域系统集成 (物联网) 和信息域系统集成两层平台组成, 中间通过以太网连接。如图1所示, 上层的信息域系统集成平台主要负责系统数据处理, 实现系统综合管理和增值应用;底层的控制域系统集成平台以物联网方式连接, 通过底层控制总线网络互联, 联动控制功能以及控制域全局事件处理集中在控制域处理, 通过底层控制总线网络互联和技术融合实现跨总线、跨网段、跨子系统的总线级的无限联动控制, 系统联动不依赖电脑工作站和服务器, 反应速度达毫秒级, 高度可靠和稳定。控制响应完成后, 响应结果再从底层控制域经由以太网传送到上层的信息域系统集成平台进行存储、分析、统计和处理等综合管理。系统的联动设置人性化界面、采用“傻瓜式”操作, 极大提高了系统的可用性、可调整性和可维护性。

信息域系统集成平台重点实现综合管理和增值应用, 重点实现各子系统的运行状态、故障状态、报警信息、运营信息、设计档案、安装档案的搜集、整理和分析, 为设备管理、运营、维护、决策提供科学的技术手段和决策依据;同时提供建筑智能化集成系统与其他信息化系统 (如OA等) 的标准接口, 为建筑智能化系统与其他系统的信息沟通与远程控制提供必要条件。

通过物联网技术使得大楼内的各个智能化控制子系统的硬件资源、传感资源互联、共享与无缝集成, 可以轻易实现各子系统的协同运行, 它以“身份识别”为核心自动完成大楼内各机电设备的控制, 用户进入大楼只需要进行简单的身份识别, 系统就可以根据用户身份自动完成各种控制, 比如通过刷卡身份识别, 电梯自动到达指定楼层, 报警系统自动撤防, 开启电梯厅与通道照明, 开启办公区空调、工作区照明并保持工作区照明的恒照度;人离开时系统自动关闭其所在工作区域的空调和照明灯光;当办公室所有人员离开时, 办公室所有照明 (工作区照明与公用照明) 自动关闭、报警系统自动布防、空调系统自动关闭。人进入大楼只需要进行简单的身份识别与认证, 然后大楼所有设备就会根据访问者的身份与其所在工作区自动完成设备的启停与控制, 访问者身份不同则受控对象与运行模式不同, 大楼好像是为每一个人量身定制的一样, 大楼内所有设备均在进行自我控制, 节能操作也在用户不知不觉中进行, 并可由物业管理人员用“傻瓜式”平台快速完成需求变化后的功能调整, 不需要专业公司现场服务, 这是智能建筑系统集成其他模式所难以达到的。

基于物联网核心技术的建筑设备管理系统集成平台以物业管理和运营管理为重点, 强调以高效、便捷的软件体系来协调用户、物业管理人员、物业服务人员三者之间的关系, 对物业管理中的设备、服务、公共设施、工程档案、各项费用及维修信息资料进行数据采集、传递、加工、存储、计算等操作, 反映物业管理的各种运行状况。它不是以往单纯信息域的系统集成, 而是不同子系统的高度融合并产生协同效应, 从而实现智能建筑精细化控制、精细化管理。

5 结束语

软平台集成系统篇6

关键词：数据集成平台,权限管理,审批流程,医院信息系统,OA

0 引言

我国医院信息化建设大都经历了以财务为核心到以临床管理为核心的历程,由于医院信息系统自身的复杂性,医院信息化建设往往不是一家医疗软件公司所能全面覆盖的,因此医院面临少则几家、多则十几家的医疗软件公司的信息系统。这导致系统之间信息不能充分共享和交换,形成了“信息孤岛”和“信息烟囱”,严重阻碍了医院信息化的发展[1]。医院必须要考虑院内各种信息系统间的医疗数据共享与交互,这也成为了医院信息化迫切需要解决的问题。2011年,卫生部印发了《基于电子病历的医院信息平台建设技术解决方案(1.0版)》,明确了医院应建立以电子病历为核心的医院信息系统,将“医院数据集成平台”定义为“以患者电子病历的信息采集、存储和集中管理为基础,连接临床信息系统和管理信息系统的医疗信息共享和业务协作平台,是医院内不同业务系统之间实现统一集成、资源整合和高效运转的基础和载体”[2]。

医院数据集成平台的引入,将医院内信息系统N(N-1)/2(N为医院信息系统的数量)的网状关系简化成医院信息系统与医院数据集成平台间的N关系,因此建立一个标准化、耦合度低的集成平台是医院信息化发展的必然趋势[3]。由于数据集成平台处于医院信息系统数据交换的中心位置,改变了原有医院信息系统点对点的数据交互方式,整体设计应参考HL7 RIM模型,遵从CDA、IHE等国际标准进行开发[4]。因此需要对全院所有信息系统的接口进行修改,涉及软件修改的工作量巨大,医院对数据集成平台的应用需要采取循序渐进、逐步应用的方式。我院自2013年引进Orion Health公司的Rhapsody集成平台,对院内各子系统进行了数据集成[5],将门诊记录、门诊处方、诊断信息、手术记录、入院记录、住院病案首页、出院小结、转诊记录、检查、检验、健康体检记录、收费记录、医嘱记录、会诊、输血记录、治疗处置、体征信息、医药卫生用品监管等42个CDA数据集上传至区域卫生平台,累计上传了800多万条CDA记录,并在电子病历系统中实现了对区域平台中居民健康档案的调阅。

1 需求分析

院内数据集成平台的应用主要有基于患者主索引(master patient index,MPI)的健康档案的数据集成、基于单点登录的界面集成、基于应用程序之间实时或异步交换信息及相互调用的应用集成[6,7,8]。由于常熟区域卫生平台的建设相对完备,本地居民参加医疗保险的人群比例高达99%以上,以身份证为主索引的条件完备,且所有常熟市范围内的医疗机构都实现了医疗数据向区域卫生平台的上传,并能在院内电子病历系统中直接调阅居民的健康档案,因此基于区域患者主索引的健康档案集成在常熟市已初具规模。而基于应用程序之间实时或异步交换信息和相互调用的应用集成,由于涉及软件修改的工作量巨大,因此需要逐步完善。因此,我院当前应用数据集成平台的重点在于基于单点登录的界面集成。基于单点登录的界面集成的基础之一在于院内所有信息系统的统一权限管理,一个功能完善、易于扩展与使用的权限控制系统是企业级信息系统不可缺少的部分[9]。表1为医院信息系统及权限管理表。

由表1可以看出,医院信息系统的权限对应主要是以岗位来确定,而一般医院人员的岗位变动由科室或人事部门发起申请,经人事部门负责人确认,并经过院领导签字后确认生效,最后人事部门通知医院信息部门的工作人员做岗位变动。整个人员岗位变动并不是信息化的管理流程,尤其是在医院信息部门的工作人员调整信息系统岗位权限的环节,往往凭信息部门工作人员对医院信息系统的熟悉程度,自行调整岗位变动人员在医院各个信息系统的权限,容易造成岗位权限设置错误与遗漏。我院数据集成平台通过前期的应用,已实现了对院内各个信息系统的数据交互,只要明确各个系统的岗位权限表的结构,完全能实现对各个信息系统的岗位权限调整。

2 流程设计

医院内部人员岗位变动属于医院行政管理的范畴,因此人员岗位变动在办公自动化(office automation,OA)系统中设置人员岗位变动的审批流程,当整个审批流程完成后,通过触发器将人员信息库中岗位的变化情况插入岗位变化任务表,数据集成平台通过结构化查询语言(structured query language,SQL)监听,发现岗位变化表的任务记录,然后通过数据集成平台更新相应医院信息系统的权限,流程如图1所示。

3 关键表结构设计

3.1 岗位权限对应表(OA_HIS_Job)

岗位权限对应表(见表2)设置在OA系统中,其功能是将OA系统中的岗位信息与医院信息系统中所有子系统的岗位做好对应关系,在OA系统发起人事岗位变动的审批流程时,便于岗位变动发起的科室选择相应的人事岗位,而不用关心医院信息系统中各个子系统的岗位情况。

3.2 岗位变动任务表(Job_Task)

岗位变动任务表(见表3)设置在OA系统中,由OA系统中人员岗位变动流程审批完成后,人员岗位变化时,通过触发器将员工OA系统岗位对应医院信息系统的岗位的变化生成至岗位变化任务表中。

4 医院数据集成平台对岗位变动处理

医院数据集成平台进行SQL监听时,为保证岗位权限的及时更新,设置监听的时间间隔为500 ms,轮询岗位变动任务表中“Flag”字段标志为0的记录,按照“HIS_Sub Code”字段的内容,按照不同的条件进入各个子系统岗位更新的路径,并按照“Change Type”字段的内容,删除或增加相应的岗位权限。医院数据集成平台的岗位变动处理流程如图2所示。

以修改HIS岗位变动为例,在Rhapsody数据集成平台的“修改HIS岗位权限”的“Database Lookup”控件中,执行了如下更新语句,实现了对HIS的权限的变更。

5 应用效果

本文提出通过OA系统的岗位变动的审批流程来触发院内医疗信息系统的权限变更,由医院数据集成平台通过数据库的监控,轮询岗位变动的任务表,一旦发现岗位变动的任务,立即触发针对医院各个信息化子系统的权限变更,从而实现医院信息系统权限统一管理。基于数据集成平台的统一权限管理系统投入使用后,主要的优势体现在:(1)由OA系统行政审批流程触发的医院信息系统权限变动符合医院管理流程;(2)将人工逐个修改各个系统权限的方式转变为系统化、标准化的自动触发流程,避免了人工修改的错误与疏漏;(3)对院内信息系统的人员权限的修改更为高效;(4)对院内信息系统权限的修改,能在数据集成平台内留下修改记录,满足管理需求中对信息系统权限变动的追溯;(5)通过建立基于数据集成平台的统一权限管理规范,有利于后期引进信息系统时权限管理的集成。

6 结语

通过应用数据集成平台,实现了院内信息系统的统一权限管理,虽然取得了较好的应用效果,但是对于医院数据集成平台的应用还处于初级阶段,由于未对现有的医院信息系统做应用集成的改造,还不能实现医院信息系统向数据集成平台推送并接收标准化的消息,未能提供基于CDA标准的资源信息内容上的互联互通[10]。因此在下一步工作中将以应用集成为目标,逐步改造现有医院信息系统,与数据集成平台实现基于HL7标准的实时消息交换。

参考文献

[1]刘博,夏新,陈彦东.基于信息集成平台的业务整合与数据共享方案[J].医疗卫生装备,2013,34(7):46-48.

[2]中华人民共和国卫生部.基于电子病历的医院信息平台建设技术解决方案(1.0)[EB/OL].[2011-03-29].http://www.moh.gov.cn/publicfiles/business/htmlfiles/mohbgt/s6694/201103/51091.htm.

[3]黄秋花,蒲立新.基于HL7 V3标准的集成平台的初步研究[J].中国数字医学,2013,8(6):102-104.

[4]缪姝妹,王忠民,刘云,等.基于医院信息系统集成数据平台的建设研究[J].中国数字医学,2014,9(5):72-74.

[5]仲晓伟,张杰.基于医院集成平台的区域医疗交换CDA的设计与实现[J].中国数字医学,2013,8(6):13-16.

[6]沈家敕.区域医疗信息平台建立与探讨[J].中国数字医学,2010,5(11):56-57,60.

[7]胡志坚.集成平台在医院信息系统建设中的应用[J].中国卫生信息管理杂志,2012,9(4):61-65.

[8]孟庆崧,戴鲁男.基于SOA的医院信息系统集成平台研究[J].中国数字医学,2012,7(6):51-53.

[9]王科,纪姗姗,刘芳,等.企业级信息系统权限控制机制设计与实现[J].计算机工程与设计,2011,32(11):3 582-3 585,3 663.

软平台集成系统篇7

“信号与系统”是电气工程专业的专业基础课,被广泛应用于自动控制、信号处理、电路与系统等领域[1,2]。由于该课程理论性强,内容抽象,学生普遍感到理解困难,学习吃力。

通常通过基于硬件或软件的实验加深学生对所学知识的理解[3,4,5]。硬件实验利用示波器、波形分析仪、选频电平表等器件观察、测试、分析信号的波形及各种特性,这种方式投资大,维护、更新难。软件实验是利用软件编程对信号进行分析处理,常用软件是Matlab[6,7,8],具有简单易用,集成度高,处理能力强,仿真效果好等特点。但Matlab软件直观性差,无法快速、高效、实时地处理信号,不能完全满足实验教学的需要。

为了进一步提高教学质量,在“信号与系统”实验教学中,需要使用更具优势、更切合课程实际特点的软件。LabVIEW是一款主要应用于计算机数据采集和数字信号处理的软件,采用图形化编程语言,具有形象、直观、数据处理能力强等特点,符合实验教学的要求。基于LabVIEW设计“信号与系统”教学软件,对于提高该课程的教学效果具有重要的意义。

本文首先介绍LabVIEW的特点,针对课程的主要内容,特别是重点内容[9],分析构建实验软平台的可行性,确定了贯穿整个教学计划的典型实验。另外,根据设计目标,规划设计了软件框架。最后,介绍了频谱泄露、时域卷积运算、典型信号频谱分析等具体知识点的LabVIEW实现。

1 LabVIEW的特点

LabVIEW具有图形化的仪器编程环境,内置程序编译器,拥有强大的资料分析软件工具箱,能支持多种系统平台,并提供了开放式的开发平台。尤其是它脱离了具体的电路结构,能从外界采集信号并进行实时处理,运行效率高。另外,其图形化的程序框图和逼真的前面板设置,能激发学生的兴趣,特别适合“信号与系统”实验仿真。

LabVIEW软件含有数量巨大,内容丰富的函数库,特别是针对信号采集和分析,开发了整套的函数包,给信号与系统实验软平台的构建提供了极大的便利。另外,运用LabVIEW软件编程时,基本上不写程序代码,直接用数据流框图表示,大大节约了时间,提高了效率,是其他软件所不能比拟的。

因此,利用LabVIEW软件构建“信号与系统”实验软平台是合适可行的。

2 信号与系统中的难点分析

“信号与系统”公式众多,内容抽象,难以理解。分析发现课程的难点如下:

(1) 连续信号与离散信号的转换。实际中经常遇到A/D,D/A转换的情况,由于信号时域和频域特性的差异,在转换中需要应用信号采样理论,以及连续时间信号数字化等内容。

(2) 信号的卷积运算。在信号的时域分析中,对于线性时不变系统,系统零状态响应Y(t)就是系统的激励X(t)与系统的单位冲激响应H(t)的卷积,因此卷积运算在“信号与系统”理论中占有重要的地位。卷积运算量大,计算繁琐,是学生学习中的难点。

(3) 信号的频域分析。信号的频谱是分析信号的重要工具,通常会应用到数学中傅里叶级数与傅里叶变换的相关知识,其公式繁多,计算量大,并且不易画出图像,学生难掌握。

(4) 离散傅里叶变换中遇到的问题。由于计算机只能处理数字化信号,在实际工程中,对连续信号进行频谱分析时应利用离散傅里叶变换做近似处理。这种近似处理除了会使结果存在一定误差外,还会带来频域混叠、信号截断与频谱泄漏、栅栏效应、频率分辨率低等问题。这些内容比较抽象,难度较大。

3 软件的结构和规划

3.1 软件结构

LabVIEW软件结构主要包括程序结构和文档结构。

LabVIEW程序由各种不同的模块组成,根据模块执行方式的不同,程序结构分为三种:顺序结构、并发结构、分布结构。其中,顺序结构是最基本的,程序中的各种模块按顺序执行;并发结构的程序则由若干个可以同时执行的模块组成;分布结构程序中的模块可以彼此隔离,独立运行。

LabVIEW文档结构的基本组成就是VI型文件。其中,包括主VI和各级子VI,层次分明,一目了然,可以对整个文档进行快速浏览和定位。

3.2 软件规划

“信号与系统”实验软平台主要由虚拟信号发生器、各种实验功能模块、信号观察与分析模块、信号处理与保存模块组成。

其中,虚拟仪器发生器主要根据实验需要提供各种信号源。实验功能模块用于实现各种实验内容,比如信号频域分析、卷积运算等。信号观察与分析模块则主要通过示波器、频谱分析仪等实现对信号的实时观察、分析。信号处理和保存模块用于对实验数据进行保存、传输等操作。实验软平台主界面如图1所示。

另外,为顺利达到实验目标,对软件应用做出如下要求:

(1) 在实验室中安装最新版的LabVIEW软件,为学生提供最新、最完备的软件编程模块和函数库,以满足实验需要。

(2) 选取“信号与系统”课程中的重难点作为实验内容,鼓励学生应用LabVIEW软件编程实现,以强化对知识点的理解。

(3) 定期由教师向学生介绍LabVIEW中常用的函数和模块,使学生快速、熟练地掌握LabVIEW软件,以提高效率,加快教学进度。

4 典型知识点分析及LabVIEW实现

在“信号与系统”实验教学中,教师可以通过LabVIEW的界面把数学函数和波形联系起来,使教学直观易懂。学生也可以通过LabVIEW更好地学习“信号与系统”这门课程。

4.1 离散傅里叶变换中的“频谱泄漏”

为了能对无限长的离散化序列进行离散傅里叶变换处理,必须对序列进行加窗截短处理。由于窗口序列频谱函数的旁瓣总是存在,导致截短后序列的频谱产生失真,使信号的频谱向两旁扩展,即原信号的频率成分从原有的频率处“泄漏”到其他频率处,产生了“频率泄漏”。

“频率泄漏”概念较为抽象,不直观具体。为了能让学生理解其产生的原理,在实验教学中可使用具有很强可视化前面板的LabVIEW软件对“频谱泄漏”进行编程,其前面板和程序框图如图2和图3所示。

图2中可以任意设定信号的采样点数、幅值、相位、周期,在示波器上显示加窗前信号波形及其频谱图像,同时加窗截短后的信号波形和频谱图也可以直观地看到。

4.2 时域卷积运算

对于连续信号,卷积运算定义为:

$y (t) = f (t) * h (t) = \int f (x) h (t - x) d x$

此卷积称为卷积积分。对于离散信号,卷积运算定义为:

$y (n) = f (n) * h (n) = \sum_{m = - \infty}^{\infty} f (m) h (n - m)$

此卷积称为卷积和。由以上公式可以看出卷积运算很繁琐,通过LabVIEW软件编程能够更加形象地展示卷积运算,更易于学生掌握。基于LabVIEW卷积运算的前面板和程序框图如图4和图5所示。

图4中的信号类型有正弦、单位冲击、单位阶跃三种选择,通过选择按钮确定X信号与Y信号的类型,便可在示波器中显示出待卷积运算的两种信号图像,以及卷积运算后的最终结果。

4.3 典型信号的频谱分析

频谱的获取需要借助数学上傅里叶级数及傅里叶变换,公式较多,计算繁琐。应用LabVIEW软件编程可以轻松解决这一难题,部分典型信号频谱分析的前面板和程序框图如图6和图7所示。

图6中选择了部分典型信号,包括正弦、三角、方波、阶跃、冲击五种类型,并在模拟示波器中显示了信号的波形及其对应的频谱图,使得信号的频域特性一目了然,加深了学生对典型信号频谱的认识、理解。

5 结论

“信号与系统”这门课程公式多,计算量大,概念抽象且不易理解,学生学习起来难度较大。通过将LabVIEW软件引入到实验教学环节,构建实验软平台,可以将一些抽象概念转变成形象、生动、直观的图形和实例,激发学生的学习兴趣,从而加深对抽象概念的理解,提高其提出问题、分析问题、解决问题的能力。这是“信号与系统”实验教学上的新尝试,不仅能够提升学生的程序设计水平,而且可以解决课程教学中的实际问题,提高教学质量。

摘要：针对“信号与系统”课程教学中存在概念抽象、理解难等问题,构建基于LabVIEW软件设计实验教学软平台。首先,分析LabVIEW的特点,以及基于LabVIEW构建实验教学软平台的技术难点和可行性;其次,分析和归纳课程中的知识点和难点,研究贯穿课程教学的典型实验;再次,规划和设计软件框架,编程实现实验的目标;最后,介绍频谱泄露、时域卷积运算、典型信号频谱分析等具体知识点的LabVIEW实现。

关键词：信号与系统,实验教学,LabVIEW,教学软件

参考文献

[1]周雅,王红艳.LabVIEW在“信号与系统”教学中的应用研究[J].中国电力教育,2010(25):61-63.

[2]祁雪梅,潘冬明.LabVIEW在数字信号处理教学中的应用[J]现代电子技术,2006,29(14):152-153.

[3]胡惟文,曹斌芳.基于LabVIEW的虚拟实验室研究[J].中国科技信息,2005,2(23):18-19.

[4]李敏,陈兴文.基于LabVIEW开发数字信号处理综合性实验[J].实验科学与技术,2008,6(5):11-13.

[5]杨文龙.虚拟仪器及其在信号处理教学实验中的应用[J].实验室研究与探索,2007,26(12):297-301.

[6]梁辰.基于Matlab的FIR数字滤波器的设计[J].机械设计与制造,2010(12):87-89.

[7]崔红,常洋.基于Matlab的尾流图像数字化处理[J].光子学报,2010,39(12):2274-2278.

[8]陶桂宝,郭少波.Matlab与VC++混合编程在系统仿真中的应用[J].重庆大学学报,2007,30(7):26-29.

[9]夏伟杰.数字信号处理课程结构与难点分析[J].中国科教创新,2009(34):85.

软平台集成系统篇8

1.1 建设政务信息化平台的基本目标

本文旨在探讨建立以项目库、人员库和企业库三大基础数据库为基础, 以数据管理、质量管理、安全管理等工程质量监管系统为主干, 以政务OA为枢纽, 以电子政务外网为中心平台, 以企业信息化为重要补充的覆盖全行业的全省建设系统监管信息化体系。通过贯穿省、市、县三级的工程质量监督系统, 建立省级工程质量监督云计算中心, 实现省级工程质量监督工作联动, 并进一步建立工程质量监督管理评价体系。

1.2 现行系统存在的不足

信息化是时代发展的必然要求, 是现代化建设的必由之路。党的十六大提出了以信息化带动工业化, 以工业化促进信息化, 走新型工业化道路的发展战略。建设部明确了加快建设事业信息化发展步伐, 推进建设事业现代化进程的总体部署。

长期以来, 建设主管部门对各地工程质量监管主要依赖于各级地方工程质监机构手工进行数据层层上报, 难以做到对各地建筑工程现场的实时、动态监管。同时, 工程质监部门信息化手段仍比较落后、信息化应用水平和发展仍不平衡, 严重影响了建设行政主管部门对有关责任主体和工程的监管效率和监管力度, 难以适应新形势下对工程质量监督工作的新要求。

2 政务信息监管平台建设与应用系统集成要点分析

2.1 政务信息化监管平台

政务信息化监管平台是一个以建设工程安全质量的监督管理为核心, 按照安全质量监督检查的工作程序和工作方法, 通过实施完全信息整合的一体化解决方案, 以国家、部委和新疆自治区地方与建设工程安全质量有关的法律法规、行政文件、规程规范、强制性标准等为基础, 以WEB开发技术、无线通讯技术、数据库技术、多媒体影像技术、数据采集技术、移动互联网技术、嵌入式软件技术等, 实现工程报监、任务划拨分配直至工程安全质量信息的采集、存储、传输、管理等各个环节的全面信息化、自动化, 形成一个向导型、智能化的业务体系, 既可以方便快捷地完成具体监督任务, 又可有效进行全局的控制管理, 实现信息资源共享, 进而提高安全质量监督的工作水平和工作效率, 实现全面的质量管理。

2.2 政务信息化监管平台业务子系统

平台内容包含保障平台支持、行业数据中心、辅助工具及监管手段、数据交换及工作流、发布公示体系等内容。平台之上的业务系统采用当今先进的计算机网络技术及电子通讯技术进行建筑工程质量监督数据的动态管理, 以互联网作为信息收集与传输的通道, 通过网络发布最基本的质量监督管理信息, 起到社会监督的作用, 并建立起质量监督与行业的信息数据库。这些业务系统包括:

(1) 安全管理系统:安全监督动态管理系统、三类人员安全生产审核系统、起重机械备案登记管理系统、特种作业人员管理系统 (模块化) 、建设工程项目管理系统 (模块化) ;

(2) 质量管理系统:质量监督动态管理系统、保障性住房大检查系统、优质建设工程申报管理系统;

(3) 招投标管理:招投标监管系统;

(4) 单位管理:监督机构及人员管理系统、建设工程质量诚信信息系统、建设行业协同办公系统 (模块化) ;

(5) 检测管理:检测监督管理系统、建设工程检测数据上传监控系统、地基基础检测管理系统;

(6) 视频监督:建设工程安全质量远程视频监管系统。

2.3 建设行业基础信息数据库

标准数据库建设是信息化建设的基础及核心工作, 也是电子政务系统正常运行的核心保障 (如图2所示) 。按照“一数一源, 共建共享”的原则, 通过原始资料入库、基础数据核对、系统采集整合的方式逐步积累, 所有数据将实现全省建设主管部门共享。建设基础数据库应当注重数据库的结构优化处理和层次框架完善。以企业组织机构代码和人员身份证号为唯一ID号, 对企业、人员数据按指标分类进行层次框架完善, 确保数据分层次与平台系统的无缝衔接, 确保数据的跨平台同步和协同共享。

3 政务信息监管平台的系统集成

3.1项目整体架构

3.2 系统技术路线

3.2.1 采用 SOA 面向服务的软件架构

监管系统采用业内领先的面向服务的体系架构思想SOA进行系统设计, 它通过明确的定义和松散耦合来提升系统间的弹性。SOA利用开放的标准, 将软件资产展现为服务结构。将独立的软件资产封装为一个一个的“积木”, 可以像搭积木一样实现应用与平台之间的装配。同时, 接口封装可以重用, 降低开发成本;采用独立的实现接口描述, 容易整合用户原有、现有及未来的各种业务应用;明确定义的应用系统间接口, 容易实现应用流程模型。

使用SOA体系架构, 其强大的接口适应性、多协议支持性可兼容现有IT资产, 保护现有投资;支持未来的业务系统扩展, 并实现与外部业务系统之间的交互与共享。SOA的面向服务的思想, 将软件功能打包成用户平时日常使用的服务功能, 以用户的习惯来定义软件, 这样的做法可以打破业务与IT技术的鸿沟, 将业务与技术服务良好的接合;服务的“搭积木”特性, 可灵活优化或改变用户现有的业务流程;同时SOA的平台无关性可以良好实现新旧系统、异构系统或数据库之间的业务集成与数据交互。

3.2.2 采用 J2EE 体系架构

项目采用J2EE技术体系进行开发设计。J2EE (Java Platform, Enterprise Edition) 是一个构建和实施可移植的、高度可伸缩的企业应用程序的开放标准, J2EE定义了一个开发和部署多层应用程序的平台。这种分层的体系结构使得程序的重用、扩展变得容易, J2EE服务器以容器的形式为所有的组件类型提供后台服务, 业务逻辑被封装成可复用的组件, 使得开发人员不用自己开发后台服务, 可以集中精力解决业务问题。同时Java技术的跨平台性, 可以保护现有的IT资产、实现高效的软件开发、支持异构环境、实现高可伸缩性。故本项目采用J2EE作为软件开发技术。

同时, 为满足本项目的部署要求, 系统建设将采用集中部署、集中应用, 支持B/S或基于智能终端 (Smart Client) 分布式多层架构的多层应用体系结构。

4 结论

建立省、市、县三级建筑市场监督管理信息系统网络, 逐步完善三级数据交换体系, 形成实时监管信息系统, 实现对建设工程全面、及时、有效的监管, 以提高政府的管理效率和管理水平。实现政府宏观管理、宏观决策的科学化。提升工程质监业务管理能力, 方便企业办事, 加强职能部门服务水平, 推进企业数据直报制度, 掌握最真实的行业统计数据, 促进建设行业政务管理一体化, 加快建设领域信用体系建设, 促进建筑市场健康发展, 打造建设领域“权利阳光”政务平台

摘要：本文从省级政务信息监管平台和应用系统集成两个方面入手, 就如何在省级政务信息网上搭建一套标准统一、功能完备、性能先进、安全可靠的省级信息化监管系统软件进行研究。研究的目的在于规范业务流程, 提高工作效率和监管水平, 构筑更加公正、高效、规范、有序、开放的政务信息化平台, 从制度上防止建筑领域的腐败问题的产生。

关键词：政务信息化,监管,系统集成

参考文献

[1]胡容波;姚敏;范延平.基于SOA的国土资源应用系统架构设计[J].国土资源信息化.2012 (05) , 133-134.

[2]范延平, 面向SOA的国土资源综合信息监管平台架构设计与实现 (J) , 国土资源信息化, 2010.

[3]刘铁江, 组合Web服务选择、部署与执行的关键技术研究, 复旦大学, 2011.

[4]王志佳, 国有资产监管领域的电子政务系统构建, 复旦大学, 2010.

[5]柳纯录、刘明亮, 信息系统管理师教程 (M) , 清华大学出版社, 2008.

软平台集成系统篇9

随着IT行业的迅猛发展和信息化水平的不断提高, 当今的IT产业几乎涉及到社会发展的各个领域, 成为不可或缺的一部分。而在某些领域, 对信息的统一管理尤为重要, 集成的概念由此而产生。医院内信息的集成化程度在一定程度上反映了该医院在医疗信息化领域中的地位和发展水平。医院信息集成的开发涉及医疗行业的各个领域, 如检查、检验手术麻醉、血库、病理等。

IHE (integrating healthcare enterprise) 在实现医院内部信息系统数据交换的基础上, 更进一步地实现了医院工作流程的集成, 从医院整体医疗事务处理的层次上, 规范了医院的各种信息源所产生的数据、处理的步骤、方法和格式, 使多个信息系统能顺畅地按一定顺序完成医疗事务的处理, 是实现数字化医院向高层次发展的重要技术。

集成平台结合了IHE和HL7 标准, 为医院信息集成提供了一个高可用性和高扩展性的平台。

1 平台实施

1.1 整体系统构架

虽然目前医院在集成上有一定的集成程度, 但是由于其采用方式的固有问题, 存在相当大的提升空间, 采用集成平台方案将解决相应的问题。集成平台构架如图1 所示[1]。

1.2 整体实施计划

由于集成平台需要和放射、超声、病理等多个外围系统进行信息集成, 为了保证集成平台实施的稳定性, 主要将集成平台的实施分为5 个阶段, 分别是单系统科室试点上线、单系统全院上线、集成平台全部试点科室上线、集成平台全部全院上线、后期运维。

1.3 集成平台与各系统集成的工作流程

集成平台与各系统集成的工作流程如图2 所示。

2应用

2.1病理系统与集成平台的交互时序图

目前 , 我院通过集成平台接入了病理系统、内窥镜系统、心电系统。病理与集成平台交互时序图如图3所示。

2.2医生工作站、集成平台和病理系统之间的详细流程

(1) 医生工作站开检查申请 , 将申请信息发送给集成平台 , 集成平台将申请信息转换成HL7消息发送给病理系统。此时发送的HL7消息有ADT^A01 ( 住院 ) /ADT^A04 ( 门诊 ) 患者的基本信息和ORM^O01 (control code=NW) 检查申请信息。

(2 ) 病理系统对检查进行排班后, 通过HL7消息通知集成平台, 集成平台再将排班信息更新至HIS。此时发送的HL7 消息是SIU^S12 检查排班信息。

(3) 开始检查时, 病理系统发送HL7 消息通知集成平台开始检查, 集成平台更新HIS中该检查申请的状态。此时发送的HL7 消息是ORM^O01 (control code=SC, order status=SC) 检查申请信息, 状态为SC (已到检) 。

(4) 检查完成时, 病理系统发送HL7 消息通知集成平台:该检查已经完成并发送给集成平台, 集成平台更新检查申请状态。此时发送的HL7 消息是ORM^O01。

(5) 检查报告完成后, 病理系统发送HL7 消息通知集成平台: 该检查已经完成报告并将报告信息发送给集成平台, 集成平台更新检查申请状态以及检查报告信息。此时发送的HL7 消息是ORU^R01检查报告信息。

3 功能

在平台管理层提供业务日志、事件日志、业务规则日志、端到端的消息跟踪业务监控功能, 实现在开发期的有效调试以及运行期间的故障诊断分析。利用集成平台的故障可追溯机制, 管理员可快速定位导致异常的环节[2]。

3.1 提供强大的系统监控 (system monitor) 功能

图4 所示为集成平台系统监控界面。从图4中可以看出, 集成平台当前与哪些系统连接, 哪些是活动的, 哪些处于关闭状态等;可以查看消息队列与消息分布; 可以查看事件日志 (event log) , 如果有错误消息, 则会在列表中显示红色的错误日志[3]。

3.2 应用消息查看与管理 (message browser) 机制进行流程跟踪及错误定位

图5 所示为集成平台消息查看与管理界面。从图5 中可以看出, 集成平台对消息的管理非常严格。通过消息的查询可以快速、准确地定位到出错的消息以及系统, 而且, 只要是通过集成平台对接的系统, 消息引擎会记录所有的消息, 更加方便医院对各个系统的管理与维护[4]。

3.3 通过规则 (business rules) 机制管理处理业务需求

点击View查看规则内容, 将出现如图6 所示的界面。

3.4 增强了数据的有效性检查

检验、检查数据的时效性较强, 可根据相关的管理规定提供有效数据。对检验、检查中的数据进行过滤, 剔除垃圾数据;对于时间跨度比较大的检查项目 (如病理类的检查) , 通过控制使其能够全过程有效的接入[5]。

3.5 系统配置灵活易用

相关数据查询语句等通用, 错误校验严格, 方便现场配置。提供Web Service及HL7 标准消息接入方式, 降低了第三方接入的难度。

4 医院现行集成平台方式与以往数据集成方式相比较的优势

4.1 数据安全性高

由于平台下的各个系统相对独立, 某个系统故障不会影响其他系统运行, 不会产生数据的丢失。

所有的外围系统通过集成平台与HIS进行数据交互, 不能直接操作HIS库, 因此, 集成平台能够很好地起到数据保护作用[6]。

连接集成平台的外围系统的接入点有严格的限制, 如IP地址、端口、消息规范等, 不在允许范围内的系统无法连接集成平台, 更加不能操作HIS。

事务控制: 在HIS的业务数据写入与业务进程表的写入置于一个事务控制之下, 保证业务进程的有效性, 不会造成数据丢失;通过消息重发机制, 可以有效地避免数据的丢失。

集成平台的MIRROR可以实时地将正式服务器上的数据备份到备份机器上, 保证意外发生时, 备机能在第一时间接替主服务器工作。

4.2 接口适应性强

由于交换数据的配置存放在业务参数表中, 对于由于医院业务的扩充造成的交换数据的调整, 只需要修改业务参数表的相应记录即可, 而不需要对医院其他业务系统进行修改, 从而大大提高了集成平台的适应性, 降低了接口的难度, 减少了数据集成交换的阻力。

当有新的系统接入集成平台时, 如新接入了内镜系统, 则原有的放射接口都可以被内镜系统调用, 只要修改集成平台的配置即可与内镜系统进行集成。

由于规范了数据交换标准和系统接入方式, 确立以HL7 为标准的业务数据交换标准, 支持HL7 标准业务数据和非HL7 标准业务数据的转换机制, 形成一套规范的集成接入接口的设计要求规范指导未来的系统接入, 而不需与其他已存在的系统进行信息交互, 提高了接口的开发效率和稳定性[7]。

4.3 数据标准化

由于交换数据的转换是由集成平台系统完成医院的各个业务系统不涉及数据转换格式, 保证了转换数据的准确, 并为今后标准的变化提供了应变的可能。

所有的消息都由集成平台处理, 而且是统一的标准 (如HL7) , 因此, 在数据处理过程中, 若遇到非标准的数据, 平台会进行过滤, 从而确保HIS库中的数据的完整性和有效性[4]。

规范的业务数据交换标准也是未来医疗信息发展的趋势, 能够适应未来各种外围系统的接入。

4.4 项目总体控制模块紧凑

集成平台的总体分为2 个部分, 一部分是后台的代码开发, 另一部分是对项目模块的整体管理。项目模块的组合管理中, 项目关系一目了然, 可实时监控各模块的运行状态。

集成平台的接入模块包括TCP、FTP、SQL、WebService等多种接入适配器, 能够为外围系统提供多种接入方式, 有利于集成平台的扩展[8]。

集成平台的中间数据处理流程包括HL7 消息转换、消息路由、整个消息的处理等, 能够详细地展现各消息的数据走向。

集成平台的业务操作模块除包括多种外接适配器外, 还包括对消息的具体操作, 比如操作数据库、发送消息给外围系统等都在这个模块中实现。

5 结语

基于Ensemble的医院信息系统集成平台的应用效果从临床诊疗效率与质量、系统管理、医院管理3 个方面阐述如下。

5.1 临床诊疗效率与质量方面

实现了系统间的交互数据通过集成平台同步减少了数据的重复录入, 提高了效率。医技检查状态可及时更新, 医生站能够实时追踪患者的检查状态。医技检查结果可及时充分的共享, 在无纸报告的情况下, 电子报告由技师审核后医生即可在医生站中查看, 可为医生诊疗提供及时准确的依据。

5.2 医院临床数据整合方面

增加了系统数据的关联度, 为医院管理提供了更多数据查询统计功能。形成了以患者为中心的所有电子化的医疗临床信息的组织和以患者为核心的信息资源, 可对LIS、PACS、手麻、用血等信息系统进行信息集成, 以提供完整而准确的患者临床信息。

5.3 医院全面信息化建设方面

医院信息系统集成平台整合了异构信息系统最大限度地重用已有信息系统和快速按需进行服务开发。集成平台还松耦合实现了业务间的集成, 是一种可持续的集成模式。

摘要：目的:为医院各个系统与HIS的整合提供方便灵活的接入方式。方法:在现有信息通信标准 (如DICOM HL7) 的基础上定义一个技术框架, 来实现对整个信息系统的数据整合。结果:集成平台在实现医院内部信息系统数据交换的基础上, 更进一步地实现了医院工作流程的集成, 从医院整体医疗事务处理的层次上, 规范了医院各种信息源所产生的数据处理的步骤、方法和格式, 使多个信息系统能顺畅地按一定顺序完成医疗、事务的处理, 是实现数字化医院向高级层次发展的重要技术。结论:集成平台结合了IHE和HL7标准, 为医院信息集成提供了一个高可用性和高扩展性的平台。