集成实现（通用11篇）
集成实现 篇1
企业会计信息集成需要企业内部多个管理信息系统进行集成, 还需要和电子商务系统进行整合, 以实现将来自企业内外部的数据自动进行一体化处理, 并形成高度共享的数据访问平台。这里要涉及多个方面问题的建设:企业内部各个管理信息系统之间及其和电子商务系统的物理整合;数据传递与对接方式通道的建设;信息 (数据) 共享方案的建设等。目前, 这些方面的建设还有不完善之处, 有必要对其进行改进。本文拟从技术可行性和布局合理性两方面来探索企业会计信息集成实现模式的改进问题。
一、企业内部管理信息系统与电子商务系统物理整合框架
当前, 大中型企业启用的主要管理信息系统有ERP、SCM、CRM等, 并建有企业网站开展电子商务活动, 这些系统的物理集成有两个问题:接口问题和路径问题。其中接口问题又有两个:各管理系统之间及和共享数据库之间相连接的内部接口;各管理信息系统与企业终端用户及合作伙伴相连接的外部接口, 从发展来看, 内部接口要能向更多的数据库和集成系统进行扩展, 外部接口则要能向更多用户和合作伙伴扩展。路径问题是指这些系统整合中的秩序问题, 这里一般是按当前企业业务流程关系来确定, 即首先通过建立内部网 (intranet) 来实施ERP系统, 然后再以ERP系统为中心, 来整合连接SCM系统CRM系统及电子商务软件。在这种信息集成系统下, 客户通过CRM系统浏览商品的性能和价格, 并通过电子商务方式下订单, 企业则通过ERP系统下达采购计划和生产指令, 通过SCM完成物料的采购和支付。同时ERP系统提供由这一系统活动产生的财务信息及相关管理会计信息。管理信息系统框架如图1所示。如果再考虑和税务部门及结算银行的数据集成处理就需要将关系图再扩展。在这样一个整合的管理信息系统中, 还有前台系统和后台系统的建设问题, 前台系统主要是WWW服务器, 企业相应职能部门业务数据录入窗口等。作业者可以从这些登录窗口查看相关管理信息和商品信息, 并发出相关作业信息。后台系统一般包括数据库, 电子商务服务器和应用服务器, 数据库中记录有相关商品规格、价格、库存、用户档案、采购记录等海量记录, 商务服务器用来存放电子商务系统的作业数据, 处理结算、计算销售费用和销售税金业务, 并在需要送货时通知订单履行部门。应用服务器包括各种作业管理的服务器。这类服务器可能有多个, 具体如何设置也会因企业的不同而不一样。
二、数据传递与对接通道建设
会计信息集成的大背景是“网络会计”, 其信息交换系统的着眼点是会计工作的信息“取之于网”和“使之于网”。企业财务与业务所涉及到的数据一定要在网络中传递, 从传递的方向来看, 分成两个:纵向传递和横向传递。这些数据传递需要有规范的通道和对接方式来完成。
数据的纵向传递一般是指在企业内部由最下层作业点录入数据, 再通过信息管理系统的处理, 往上逐级传递, 最后由最上层汇总出整个企业的财务与业务信息。这些纵向传递的通道可能并不长 (如果企业是非集团公司) , 并不跨地区。也可能较长 (企业是大型集团公司, 跨地区有多层多级管理) 。但从会计数据传递的角度来看, 不管企业管理的层级有多少, 都应跨越掉中间环节, 使得最高决策层能及时掌握最基础、最完整和最原始的数据, 即整个企业通过网络 (局域网) 会计“信息交换系统”来实现财务业务数据一体化处理, 共同生成一套共享的财务信息和业务信息, 使各级机构和各个部门所掌握的数据和信息是完全一致的。防止个别机构做假账和虚报信息的现象出现。这种数据传递方式如图2所示。纵向传递由于在一个企业内部进行, 企业内部一般使用同一个ERP系统或相同的其它信息管理系统, 各系统及子模块间的数据通道是相同标准, 各个数据库的对接也是自然相容的, 目前对其改进是要使数据传递通道的流程设计更符合企业业务流程实际, 这个改进相ÁÁ对容易。
数据横向传递是指企业和外部单位发生的财务与业务数据的传递。这里有两类数据传递, 一是企业在采购和销售环节与外部系统的数据交换, 从会计信息集成的角度来看, 企业在采购和销售活动中, 会计信息系统应能自动获取并传递来自电子商务渠道的报价单、订单、结算数据及合同等电子数据。二是企业在经营过程中还会与其它机构进行数据交换。如采购结算时与开户银行交换数据, 因为每一笔向银行提取的付款请求都应马上得到确认, 并且可以实时地在银行与企业双方的系统中记录所发生的信息。又如在销售过程中, 要和税务机关交换信息, 使企业每一笔销售业务能立即在税务机关的系统中有体现, 使企业不能偷税漏税。另外在电子商务背景下的采购与销售业务中还要和认证机构中心交换信息, 以完成对采购合同和销售合同的认证。这一类数据传递中主要有电子发票、电子印章、电子货币和电子身份证等。
从横向数据传递的方式来看, 目前多以电子表单的形式传递为主, 也就是企业和外部单位的数据传递不是通过操作对方数据库的方式来进行, 而主要是通过电子商务软件将电子单据在网上传递, 或者是在网上发生订货或售货时由对方系统自动生成单据再通过浏览器直接下载到本地机器, 再把得到的电子单据中的数据导入到企业的数据库中, 这种传递方式要求对传递的电子表单进行规范化处理并将表单和对应的数据库对接起来, 以便能够方便、快捷地把单据上的原始数据导入到本地数据库中。这种方式的优点是:电子单据传递时方便, 不需要进行格式转换, 因而技术上不难, 又因为不直接访问对方的数据库, 使大家都不用担心数据安全与涉密问题。但从发展来看, 这种传递方式是不科学的, 数据对接太慢, (因为要先将电子单据下载, 再导入自己数据库) , 还容易形成多重下载, 造成数据重复。因此, 更好的数据传递方式是交易的企业之间数据库直接对接, 这样和对方企业发生的交易数据就能直接进入本方的数据库, 数据传递既快, 又没有数据冗余, 在本企业不形成信息孤岛。不过数据库对接方式对技术的要求很高, 首先, 要解决企业因启用不同供应商提供的信息系统而形成的数据接口不相容的问题。对这个问题目前有两种解决方法, 一是由权威部门制定会计信息系统的“数据接口标准”, 现在国家信息工业部制定了《信息技术、会计信息接口标准》 (GB-11985-2004标准) , 有些地方也制定了相应的地方标准, 如上海市在财政局主导下, 由市会计学会等单位制定了地方标准:“DB37/T270-2002信息技术会计核算软件数据接口规范”, 通过实施接口规范标准来解决不同软件的接口问题。这种方法比较容易实施。二是目前由美国等多个国家正在制定的开放性数据相互操作协议 (OGIS) 空间数据共享方案, 是要制定出一套各方面都能接受的空间数据操纵函数API, 然后各个系统供应商提供与这一API函数一致的驱动软件, 不需借助外部数据文件, 不同的软件就可以互相操作对方的数据。当然这一种方法涉及面太广, 要进入实施阶段尚需时日。第二是信息安全保护的技术问题, 企业核心数据库的数据, 既要保护其安全, 又要使之不能泄密。如和其它企业进行数据库对接, 就要有相应的保护技术, 目前主要是网络层安全, 应用层安全和数据可靠性保护等防范措施。网络层安全是保护网络不受攻击, 确保服务通道的可用性, 应用层安全是针对用户和系统应用资源的保护, 保证合法用户对信息资源的合法访问, 将信息资源按需求的安全等级进行规划, 并根据规划采取相应的安全管理手段来保证系统的实用和安全。包括:数据访问屏障、数据完整性保护、身份认证、访问授权、病毒防治等。正是由于应用层安全涉及到的面太宽, 防范技术要求很高, 太多企业对此有顾虑, 使得企业间直接数据库对接目前还不容易实现。数据可靠性保护主要是指采用RIAD5数据储存模式和双机备份等措施。总体来说, 直接数据库对接的数据传递方式是一种更好的方式, 目前其实施的主要技术条件已基本具备, 剩下的主要是观念上的一些障碍和合作中的非技术性障碍, 只要合作企业多沟通, 多探讨, 这种方式不久后便可实现。
三、信息共享基础条件建设
会计信息集成必然是会计信息在深度和广度上的全面拓展, 除了合适的信息系统整合体系和数据传递方式外, 会计信息集成的实现条件还有良好的信息共享基础条件, 包括制定企业信息交换标准、建立企业信息门户等方面的建设。
制定企业信息交换标准。共享信息分布于企业内、外不同部门的信息系统这中, 由于各部门信息系统的数据结构, 系统平台各不相同, 使得其在信息的组织, 描述方式上可能都不同。因此, 需要制定一套公共的信息标准, 各部门能在本地交换系统中, 对照公共信息标准。形成本单位信息系统和标准的映射关系。发送方在数据传输前, 按映射关系, 将信息按公共标准做重新组织。接受方收到信息后, 也按映射关系, 再将信息转换成本部门信息系统可接受的格式。目前, 在信息标准组织上, 采用XML语言作为信息描述的载体是比较合适的。自国家颁布GB/T19581-2004《信息技术会计核算数据接口》标准以来, 经过多年来的努力, 企业外部单位的数据对接, 特别是审计软件获取数据方面取得了较好的效果, 这里采用XML语言作为信息描述载体是重要的技术特征。随着新会计准则的实施和将来会计准则的可能再次变动, 都会导致原数据接口标准的一些部分失效。对接口标准适时修复和完善是必不可少的。由于XML语言能动态定义原数据, 用其描述信息标准组织就非常方便对数据的标准重新定义。
建立企业专用信息门户。建立一个统一的企业信息作业登录门户。通过门户入口后, 再接入企业内现有的各个信息管理系统和相应外部信息管理系统。这个门户能把企业内现有的各种系统和资源集成起来, 既为企业内各部门信息互访提供门户, 也能通过协议, 实现和企业外部的客户、供应商和合作伙伴信息链接互访。目前, 大多企业信息管理系统 (如ERP, 客户关系管理等) 都设有企业门户, 主要是企业内部各部门信息互访的入口。但要满足快速大范围的会计信息集成需要, 还要将企业信息门户处建立和相关外部单位数据库互访的链接入口, 以实现信息的直接集成, 而不是间接集成, 这个互访入口如何建, 可根据合作各方的具体情况来定。
参考文献
[1]杨周南等:《中国XBRL研讨会综述》, 《会计研究》2006年第8期。[1]杨周南等:《中国XBRL研讨会综述》, 《会计研究》2006年第8期。
[2]董文栋:《财务业务一体化系统特征研究》, 《中国管理信息化》2007年第10期。[2]董文栋:《财务业务一体化系统特征研究》, 《中国管理信息化》2007年第10期。
[3]艾文国等:《基于电子商务的供应链管理与ERP集成研究》, 《管理科学》2008年第6期。[3]艾文国等:《基于电子商务的供应链管理与ERP集成研究》, 《管理科学》2008年第6期。
[4]陈汉文、林志毅、严晖:《公司治理结构与会计信息质量》, 《会计研究》1999年第5期。[4]陈汉文、林志毅、严晖:《公司治理结构与会计信息质量》, 《会计研究》1999年第5期。
[5]刘立国、杜莹:《公司治理与会计信息质量关系的实证研究》, 《会计研究》2003年第2期。[5]刘立国、杜莹:《公司治理与会计信息质量关系的实证研究》, 《会计研究》2003年第2期。
集成实现 篇2
模拟电感与集成化混沌信号发生器实现研究
在基本有源模拟电感实现方法的基础上,以有源模拟电感代替理想电感元件,对混沌信号发生器的集成化进行研究.以著名Chua氏电路为例,给出了混沌信号发生器的实现方案,进行了集成化混沌信号产生电路的分析.PSpice软件的`仿真结果表明,使用模拟电感代替混沌电路中的理想电感,若设计合理,不会影响原混沌电路的非线性动态行为,可以实现混沌信号发生器的集成化.
作 者：高金峰 徐惠芳 GAO Jin-feng XU Hui-fang 作者单位：郑州大学电气工程学院,河南,郑州,450002 刊 名：郑州大学学报（工学版） ISTIC PKU英文刊名：JOURNAL OF ZHENGZHOU UNIVERSITY(ENGINEERING SCIENCE) 年，卷(期)：2005 26(3) 分类号：X522 关键词：模拟电感 蔡氏电路 运算放大器集成实现 篇3
摘要：为了削弱面向服务的应用系统中业务流程对服务模块的强依赖关系，降低系统集成测试阶段问题服务对集成过程的影响，提出了基于模拟服务的辅助集成测试方法，设计了面向服务的辅助集成测试系统模型，以缓解面向服务的体系结构下系统集成测试阶段面临的巨大压力。根据辅助集成测试系统模型中阐述的模拟服务生命周期以及构建模拟服务的关键过程，实现了系统原型研制并构建了SOAP类型模拟服务，验证了辅助集成测试方法有效性。
关键词：集成测试；模拟服务；SOAP服务；测试用例；服务生成
中图分类号：TP311.52
在面向服务的体系结构[1]（Service-oriented architecture，SOA）下，通过对业务单元进行服务封装，提高了系统中模块的复用率，也解耦了模块间的相互关系。虽然应用系统被拆分并封装成服务，但是系统业务流程依然对服务模块具有强依赖关系，随着服务的增多，导致服务集成过程变得缓慢而脆弱。首先，服务间通过网络进行通信，不但提高了集成测试环境的构建成本，而且增加了模块间的调试难度；其次，采用多团队或引入第三方单位的合作研制方式，加重了集成测试阶段的协调工作，通常会由于某个服务自身存在问题、研制团队失误或第三方研制单位的缺席而导致集成测试节点的延期，最终扰乱整个应用系统的研发过程，为集成测试带来巨大的压力[2]。
目前，面向服务系统的集成测试较多地侧重于单个服务的接口测试方面[3]，以保证服务接口功能的正确性，从而降低服务相互间集成时出现问题的概率，但无法从根本上解决集成测试过程中存在的问题。针对这一状况，本文从辅助服务间交互测试的角度出发，利用模拟服务配合被集成服务完成集成过程，有效地缓解了集成测试阶段的压力。
1 面向服务的系统集成测试定义
系统集成测试[4]，也叫组装测试或联合测试，即将程序模块采用一次性或增殖方式组装起来，对模块间的接口进行正确性检验的测试工作。面向服务系统的集成测试是在面向服务的体系架构下，对应用系统中的服务模块进行组装，以验证各服务间接口的功能正确性，确保应用系统中各服务间的互联互通互操作。
面向服务的系统集成测试将单个服务模块集成到应用系统中进行测试，可以是一次性的集成（非增量式集成），也可以是逐个的扩展集成（增量式集成），直到完成整个应用系统测试。服务的集成测试要求被集成的服务按照设计要求通过单元测试，保证单个服务的高质量要求，但经过单元测试的服务不足以保证整个系统的质量，有许多隐蔽的失效是高质量模块间发生非预期交互而产生的，所以服务集成测试的必要性在于保证能够单独工作的服务连接起来也能正常工作。此外，在某些开发模式中，如迭代式开发，服务的设计和实现是迭代进行的，在这种情况下，服務服务集成测试的意义还在于它能间接地验证概要设计是否具有可行性。
2 模拟服务辅助集成测试原理
模拟服务是一种服务真实存在的服务提供者，模拟服务存在一个或多个被模拟的目标服务，模拟服务对外提供与目标服务相同的服务接口，两者对于同一服务调用请求（接口调用参数相同）返回一致的响应结果。与真实服务不同的是，模拟服务不关心目标服务的业务逻辑，仅仅采用请求参数匹配的方法来得到应该返回的结果数据，这样模拟服务即可替代目标服务及目标服务依赖的所有服务，屏蔽了目标服务的实现细节。如图1所示，某示例应用系统中A服务依赖B和C服务，B服务又依赖于D和E服务。
通常在服务的集成测试过程中，若需对A服务进行测试，那么必须首先构建出A服务的整颗依赖树，即B、C、D和E服务的实例。采用模拟服务辅助集成测试方法，在A服务需要进行集成测试时，只需如图中构建模拟B服务替代B、D、E服务实例以及用模拟C服务替代C服务实例，如此测试环境中的实例数量缩减为A服务、模拟B服务以及模拟C服务三个。模拟服务的应用可以辅助和简化系统集成测试的整个过程，具体会体现在如下四个方面：
（1）简化集成测试环境，方便被集成测试服务组件依赖服务环境的部署与搭建；
（2）方便集成测试过程中问题的排查与定位，快速地应对突发情况；
（3）降低服务集成测试过程对关键服务的依赖程度，避免如第三方接口、在线集成组件等对测试过程的影响，提高测试的效率；
（4）缩短软件系统开发的生命周期[5]。
3 面向服务的辅助集成测试系统设计
3.1 辅助集成测试系统模型
辅助集成测试系统，用于生成、发布以及管理用于集成测试的模拟服务，本着自动化构建模拟服务的设计原则，为用户提供简易的操作方法，以应对系统集成测试过程中的频发状况。辅助集成测试系统独立于被集成测试服务，其存在的目的是为被集成测试服务提供依赖的服务环境，如图2所示，为辅助集成测试系统的模型设计图。
辅助集成测试系统负责管理模拟服务的整个生命周期，模型中主要阐述了测试数据准备、模拟服务生成以及模拟服务运行三个阶段的设计工作，测试数据准备阶段明确了集成测试前应准备的模拟服务接口用例样本和样本任务编排数据，模拟服务生成阶段指明了测试过程中模拟服务的构建流程，模拟服务运行阶段设计了模拟服务提供服务的关键过程。
3.2 测试数据准备
系统集成测试前，通常存在一定的准备时间，用于进行测试环境的准备工作。模型中的测试数据准备阶段设定在系统集成测试前，为集成测试过程准备必要的辅助集成测试数据，这些准备数据的目的是使得集成测试过程快速而有效，保障集成测试过程的可靠性，做到有条不紊地应对突发状况。
辅助集成测试系统主要包含两个方面数据的准备工作，一方面是准备被模拟服务的测试用例数据（图2中的服务接口用例样本），另一方面是准备模拟服务接口用例的任务编排数据。通常情况下，服务接口在执行请求操作时会按照参数处理、执行业务和返回响应数据三个步骤进行，如图3所示，在辅助集成测试系统中需对应准备请求样本数据、任务数据和响应样本数据。请求样本数据和响应样本数据为接口的测试用例数据，并以成对的方式出现，数据的来源可以是测试用例文档的提取数据、用户人员的录入数据以及自动生成工具的生成数据[6]。任务编排数据用于描述模拟服务接口在特定的请求样本数据下需要执行的一系列任务信息，如第三方服务调用、计时返回等，任务编排数据可以模拟目标服务的功能特性，这一过程需要通过特定的任务编排工具进行操作。
3.3 模拟服务生成
在模拟服务的生成阶段中，辅助集成测试系统需要为测试人员提供能够简单而快速地构建模拟服务的服务生成工具，负责根据测试数据准备阶段的准备数据创构建模拟服务。
服务生成工具从被模拟服务接口的用例样本出发，筛选出测试结果表现正常（能够反应被模拟服务正常情况下应具有的请求、响应数据特性）的用例数据作为模拟对象，并且从这些对象中提取模拟服务接口的元信息用于服务的构建依据。通常，由于一个服务接口往往存在多个用例样本，所以提取出的接口元信息需要通过归并操作来简化模拟服务接口的数量，这一过程会提高模拟服务的质量及执行效率。
辅助集成测试系统提供服务构建器用于根据提取出的接口元信息生成模拟服务的接口定义，再将接口的用例样本匹配逻辑以及任务执行逻辑注入至服务接口的实现中，即可完成对模拟服务接口的实现。最后，生成的模拟服务接口及其实现将经过编译与装载过程，等待模拟服务进入发布阶段。
3.4 模拟服务运行
模拟服务经过生成阶段被装载至内存中，而在模拟服务发布阶段，测试人员只需指定服务的发布地址以及绑定端口等部署信息，即可准备进行模拟服务的发布。由于辅助集成测试系统模型中设计集成了用于发布模拟服务的嵌入式服务容器，所以模拟服务可以快速地被部署和发布，嵌入式的服务容器也更加方便了对模拟服务的管理工作。
已发布的模拟服务由于没有真实的业务实现，当存在服务调用时，模拟服务执行注入的样本匹配逻辑完成响应数据的查询工作，同时在匹配目的用例样本后，根据植入的任务执行逻辑完成与用例样本关联的编排任务，最后将匹配的结果反馈至服务调用处。模拟服务的运行时序图如图4所示。
4 模型应用与原型系统实现
面向服务的体系结构下，基于HTTP协议的Web服务作为面向服务的一种实现方式，已广泛应用于企业的系统开发过程，而Web服务中当以SOAP（简单对象访问协议）服务技术历史最为悠久[7]。如图5所示，为辅助集成测试系统模型的原型系统部署图，下面将阐述系统中基于HTTP协议的SOAP模拟服务的自动构建和发布过程，介绍原型系统的实现细节。
4.1 模拟服务接口提取
SOAP服务以XML的形式封装服务请求消息[8]，如图6展示了用于用户添加请求的SOAP消息信封，通过协议绑定技术该消息将被映射为调用服务实现POJO（简单Java对象）的addUser接口。
辅助集成测试系统采用图中加黑片段XML数据作为服务接口的一个请求样本数据，构建名为addUser的POJO方法，其输入参数为User对象，对象包含name、age和married三个属性。理想状态下，User对象三个属性的类型分别为String、int和boolean，但是辅助集成测试系统识别三个属性均为String类型，得到一个拥有三个String类型属性的User对象，因为基于Document/literal实现的SOAP服务消息中并不携带数据的类型信息[9]，所以它不影响对象的数据绑定，如此简化了模拟服务的构建过程。同样，采用上述方法可以从响应样本数据中提取方法返回值类型，完成模拟服务接口元信息的提取过程。
4.2 模拟服务构建
模拟服务在接收到请求消息后，通过数据绑定技术将请求消息绑定至服务实现POJO的方法参数上，完成目标接口的匹配，这一过程采用CXF框架（Apache CXF服务框架）自动完成[10]。
模拟服务通过调用样本匹配引擎和任務查询引擎进行关联数据查询，二者采用独立运行的Web服务方式供模拟服务调用，下面为模拟服务的添加用户接口实现代码：
其中，Finder类封装了样本匹配引擎和任务查询引擎的查询接口，并提供了简单的调用接口findSample和findTasks，方便在创建模拟服务时植入统一的调用代码。在运行过程中，根据Java的反射机制finder实例可以明确当前服务的位置，再由接口的参数匹配确定具体的样本用例，用例样本匹配过程涉及Java基本类型和自定义对象类型的深度匹配，可以借助于规则引擎[11]，本文采用的是将参数对象顺序进行序列化后比较的方法[12]。最后，模拟服务顺序遍历查询出的样本编排任务信息，并依次执行任务，完成后将查询出的响应消息返回。
4.3 服务发布与管理
通过动态生成和编译后的模拟服务实体被载入至内存，测试人员在设定模拟服务的部署位置、发布端口等信息后，模拟服务交由CXF以反射的方式进行发布，即可为外部请求者提供服务。模拟服务运行时依赖的样本匹配引擎与任务查询引擎通过独立的Web服务方式运行，为集成测试过程中的模拟服务提供查询服务。最后，模拟服务的管理包含两个方面，一方面是模拟服务启停状态的控制，通过调用CXF的服务控制接口可以很好的完成这方面工作；另一方面是样本数据和任务数据的管理，由于两个查询引擎采用独立的服务方式运行，所以提供简易的数据管理工具即可。
4.4 实际应用效果
经实践证明，模拟服务在系统集成测试阶段能够有效地应对关键服务模块出现问题的情况，使得集成测试过程持续且快速。模拟服务屏蔽了应用系统下复杂的测试环境，同样为无法进行在线集成的线上接口提供了便利的解决方案。如图7所示，为辅助集成测试系统的主界面图。
5 结束语
本文从构建模拟服务的独特角度出发，提出了面向服务的辅助集成测试系统模型，通过模拟服务从容地应对了集成测试环境中服务数量多、服务环境复杂而带来的一系列问题，使得服务集成过程快速而可靠，有效地缓解了集成测试阶段的压力。文中总结了模拟服务创建及发布的整个生命周期，明确了模型中各模块的对于构建模拟服务至关重要的作用，然而尚未提及如接口归并、样本匹配等关键模块的高效实现方法，当样本数据量异常庞大时，这些模块将严重影响模拟服务的性能，为了能够提供高效并且可靠的模拟服务，这一方面仍需加以关注。
参考文献：
[1]凌晓东.综述[J].计算机应用与软件，2007（10）：122-124.
[2]杨利利，李必信.Web服务测试问题综述[J].计算机科学，2008（09）：258-265.
[3]冯细光，刘建勋.Web服务测试技术综述[J].微计算机应用，2010（01）：111-126.
[4]兰景英.软件集成测试技术研究[J].信息技术，2006（08）：102-105.
[5]Bobby Woolf.Streamline SOA Development using Service Mocks[J].IBM developerWorks，2005.
[6]马春燕，朱怡安，陆伟.Web服务自动化测试技术[J].计算机科学，2012（01）：162-169.
[7]沙为超.基于Web服务的SOA应用研究[J].安徽大学，2007.
[8]张仙伟，张璟.Web服务的核心技术之一——SOAP协议[J].电子科技，2010（03）：93-96.
[9]李海峰，杨小虎.基于风格与风格消息的服务性能比较[J].计算机应用与软件，2007（01）：80-117.
[10]彭邦伦.利用JAX—WS开发Web Service[J].电脑编程技巧与维护，2008（12）：21-23.
[11]刘伟.Java规则引擎——Drools的介绍及应用[J].微计算机应用，2005（06）：79-83.
[12]晏立，沈銳.Java序列化技术的探讨[J].红河学院学报，2011（04）：37-39.
[13]张羽丰.面向服务的Web服务测试框架研究与实现[J].国防科学技术大学，2008.
[14]罗作民，朱燕，程明.Web服务测试工具SOAPUI及其分析[J].计算机应用与软件，2010（05）：155-157.
[15]秦锋，李乔，郑啸.Web服务测试的一种实现[J].计算机技术与发展，2007（08）：239-242.
[16]严思静，常红春，刘钢，唐奋飞，冯国军.Web服务测试工具的设计[J].硅谷，2010（08）：60-64.
作者简介：徐亮亮，男，研究生在读，研究方向：军用软件集成；宋剑锋，男，博士；田飞，男，研究生，研究方向：军用软件集成。
利用EDI技术实现企业应用集成 篇4
物流信息系统是根据物流管理运作的需要, 在管理信息系统 (MIS) 的基础上形成的物流系统信息资源管理、协调系统。它是一种通过各种方式选择、收集、输入物流计划、业务、统计等各种有关数据, 经过有针对性、有目的的计算机处理, 即根据管理工作的要求, 采用特定的计算机技术, 对原始数据处理后, 输出对管理工作有用信息的系统, 具有实时化、网络化、系统化、规模化、专业化、集成化、智能化等特点。物流信息系统是由多个子系统组成的, 某企业物流信息系统包括需求计划子系统、库存管理子系统、比价管理子系统、订单管理子系统、结算管理子系统等。物流信息流转流程如下图1。
在整个流程中, 采购订单和采购发票是要和供应商进行交互的, 目前交互方式是, 采购人员打印出采购订单, 以传真形式发送给供应商, 供应商接到传真后, 按照订单明细送货, 并开具采购发票, 企业采购人员将发票录入物流信息系统制定采购报帐单。这种方式增加人工工时, 并浪费资源。于是提出了使用EDI技术实现企业物流信息系统与供应商信息系统的无缝集成。
2. EDI技术
2.1 基本概念
电子数据交换技术 (Electronic Data Interchange, EDI) 是20世纪80年代发展起来的, 集现代计算机技术与远程通信技术为一体的产物。它是电子商业贸易的一种工具, 利用计算机的数据处理和通信功能, 将商业文件如订单、发票、货运单、报关单和进出口许可证等, 按统一的标准编制成计算机能识别和处理的数据格式, 在计算机之间进行传输。EDI可以保证真实数据的传递, 特别适用于大量信息传递, 由于在传递过程中无须再输入, 从而使出错率几乎为零, 大大节省了时间和经费。通信网络是EDI实现的基础;计算机硬件、专用软件组成的应用系统是实现EDI的前提条件, EDI标准化是实现EDI的关键。这三方面相互衔接、相互依存, 构成EDI的系统框架。EDI系统模型如下图2所示。
2.2 EDI通信方式与安全机制
国际互联网是EDI传输的主要平台。EDI软件与互联网格式的软件结合起来, 由软件本身将相应的交易信息自动转换或翻译成EDI格式, 用户不会意识到EDI格式的翻译过程, 网络浏览器本身就会带EDI翻译器。Web是EDI消息的接口, 信息部门针对每个信息开发或购买相应的WEB表单, 然后把它们放到WEB站点上, 此时表单就成为EDI系统的接口。其他参与者登录到WEB站点上, 选择他们感兴趣的表单, 然后填写它, 将结果提交给WEB服务器后, 通过服务器端程序进行合法性检查, 把它变成通常的EDI消息, 此后通过EDI软件的翻译软件和格式转换软件将EDI消息转换成双方信息系统可以辩认的数据格式, 进入各自信息系统中。
由于电子文件在处理、存储和传输过程中容易被更改或伪造, 因此EDI系统需要提供报文内容完整、报文顺序完整、报文来源识别、不可否认接收、不可否认发送、报文的内容保密性的端对端安全服务功能。数字签名技术解决了这些安全问题, 每位EDI用户都有一对私有密钥与公开密钥, 私有密钥只有用户本人掌握, 而公开密钥可公布给其他EDI用户。数字签名是EDI用户以自己的私有密钥对要传送的文件内容进行加密, 接收方以发送者的公开密钥来验证该文件内容是否被篡改。
2.3 EDI软、硬构成
实现EDI需要配备相应的EDI软件和硬件。采用一台中型机平台以及专门化的EDI软件, 这个EDI软件把EDI活动和企业的计算机应用系统进行一体化。EDI软件将用户数据库系统中的信息, 译成EDI的标准格式, 以供传输和交换, 同时将接收来的外部报文通过EDI软件转换成企业内部信息系统可识别的文件。软件构成图如下图3。
3. 引入EDI技术后交互信息的方式
企业成功引入EDI技术后, 采购人员在企业内信息系统中制定订单后, 通过EDI软件将要发送的采购订单从企业物流管理信息系统数据库中提出, 由EDI软件将订单转换成标准的EDI报文, 并组成EDI信件。接收方通过EDI软件从EDI信箱中收取信件, 将EDI信件拆开并翻译成平面文件, 再将平面文件转换并传送到接收方信息系统中进行处理。供应商的信息系统接到订单后, 进行备货, 通过WEB站点的采购发票表单录入发票内容, 并通过EDI软件进行转换并传送到企业内信息系统中。
4. 引入EDI技术后的效益
企业使用EDI可以集成交互双方的信息系统, 使各种商业往来行为实现自动化, 使管理人员可以充分掌握信息并管理信息。完全避免了在双方交互信息过程中二次打印、传真的工作, 提高了信息系统的准确率和及时率, 实时掌握交易情况。降低了邮寄、电话及纸张费用, 提高了经营绩效。同时能够快速响应交易, 提高了服务质量。
参考文献
集成实现 篇5
关键词：ASP.NET；ADO.NET；地区电网；信息系统
中图分类号：TM73文献标识：B文章编号：1009-3044(2007)12-21499-01
Design and Implementation of Integration Information System for Local Power Network with .NET
WEN Qiu-shi
(Hunan University of Information, Changsha 410200,China)
Abstract:This paper introduces a design of integration information system for local power network from the practicalities of local network management. The system applies ASP.NET and C# language based on the B/S mode of web technique and the open database developed by SQL Server 2000 managing. It uses the comprehensive management of network technique and controls the other open management systems, real-time information system, and all the information related in different sectors of the enterprise. This system has the advantages of unification management and utilization of all kinds of information, convenient and fast to transmit, in time and precise data collection, and wide sharing range. Besides, it provides functions of bulletin board system, and it can improve the information management of local power network, save resources and avoid repeat construction.
Key words:ASP.NET; ADO.NET; Local Power Network; Information System
0 引言
電力行业是关系到国计民生的基础性行业。目前，我国电力行业信息化应用系统处于“各自为政，条块分割”的局面，众多信息系统由于其开发局部性，缺乏统一的编码标准，造成了电网中企业与企业间、企业内部间信息孤立、集成度差和信息可靠性、综合性、智能性不高等迫切需要改善的问题，阻碍了电力信息化建设。
针对这些实际情况，从成本、实际操作和管理维护等方面出发，设计一种实用的、易普及的电网集成信息系统，统一组织和管理输变电企业内不同部门间不同格式的信息，解决企业间以及各部门间的信息共享问题，保证电网信息一致、完整、安全、方便，使变电、修试、线路等部门间网络化的信息查询、浏览、创建和更新成为现实[1,2]，这样通过Web完善电网信息管理——这项最基础性工作。本文基于ASP.NET的设计思想和实现方法，利用C#语言，结合AD0.NET的应用，设计并实现了地区电网集成信息系统。
1 系统数据分析与总体设计
1.1 系统数据分析与功能设计
系统是联系地区电业（供电）局与所辖厂站及县、市供电局（所）的桥梁，也就是提供给工作人员查询和发送信息的服务[3,4]，其功能结构及数据管理如表1所示。
表1系统功能模块及数据管理
1.2 系统体系结构设计
系统整体构架采用客户端浏览器／Web应用服务器／数据库3层架构[5]。在客户端以浏览器的方式进行界面展示并与用户交互；Web应用服务器负责实现系统的全部功能，接收和处理用户的请求，并实现与底层数据库的交互；底层数据库存储与地区电网各类数据，包括设备台账、设备基本信息、设备运行信息、设备保护信息、图纸等相关数据，是整个系统的核心部分。
1.3 数据库系统设计
为确保系统数据库的安全，系统包含了五个不同类型的数据库：运行数据库、临时数据库、备份数据库、存档数据库及系统管理数据库。备份数据库与运行数据库内容完全相同，它由系统定期备份，两者存储在不同的设备；临时数据库通过增加审查级别等字段，实现数据修改时的各级管理机构审核；存档数据库用于保存系统的历史资料，可定期清除存档时间超过一定时间的数据；系统管理数据库用于管理用户登陆的IP地址，用户当前的登陆状态，最近一次登陆时间和最近一次退出时间等。
2 系统的实现
2.1 系统实现方案
地区电网集成信息系统的实现基于B/S结构，服务器操作系统为Windows 2003 Server，Web服务器为IIS5.0及以上版本，开发工具选用Microsoft Visual Studio .NET 2003结合C#编程，利用ASE.NET技术实现系统的全部功能，并借助于ADO.NET进行数据库操作，数据库为SQL Server 2000，界面的设计制作使用Javascript、Photoshop、Flash等技术美化用户界面，系统整体构架如图1所示。
图1 电网集成信息系统架构
软件系统由Web显示层、数据访问层、数据操作动态链接库和数据库构成。Web显示层即ASP.NET页面(Web Pages)层，为客户或用户提供对应用程序的访问，以Web页面的形式实现。数据访问层为Web显示层提供数据服务，系统的数据访问层的实现是根据数据库的表来创建相应的类，该类封装系统中相关信息的添加、选择、更新、删除等功能。数据库操作动态链接库(DLL)，该层直接访问ASP.NET系统的数据库，由一个独立的项目工程SQLHelpler实现。
2.2 ASP.NET数据库访问技术
ASP.NET主要用于在服务器上开发功能强大的Web应用。ASP.NET在服务器上运行经过编译的CLR代码；实现了代码与程序分离；ASP.NET支持多线程操作。在ASP.NET框架中调用Web Service非常简便；向程序中添加Web引用，就可以像引用类中的任何其他方法一样引用Web服务中的方法。
在ASP.NET中，数据库的访问可通过ADO.NET模型来实现[6]。ADO.NET提供了一种建立在ODBC、OLE DB之上的数据存取方式。本系统采用与SQL Server相连的方式实现对数据库的访问，通过创建SQLHelper工程，使用SqlConnection类建立数据库连接，SqlCommand类执行SQL处理命令，从数据库中返回的数据放入DataSet中，并通过DataGrid控件在页面上显示。对于数据更新操作必须在事务处理范围内进行时，使用SqlTransaction类实现。
2.3 系统安全性
安全性对于电网集成信息系统尤为重要， ASP.NET Web应用程序的安全性是建立在Windows安全性和IIS安全性基础之上的。在实现时，系统主要采取了以下的安全策略：
(1)身份验证方式：采用ASP.NET提供的表单身份验证。
(2)授权策略：基于角色的授权策略，使用角色将用户群分为在应用程序内共享相同安全权限的用户组：设备管理员、调度员、各级领导层及系统管理员等。将用户映射到角色，当用户有权执行所请求的操作时，程序使用固定身份访问资源。
(3)安全通信技术：由于表单身份验证方式采用明文在网络上传递验证数据，因此必须保证通信通道的安全性。对此类安全敏感数据，采用SSL／TLS来保护浏览器和Web服务器之间的通道安全。
(4)数据验证：验证数据类型、过滤任何非法性输入，尤其是防止SQL注入攻击。
3 系统的高级应用
3.1 与现有管理系统接口设计
调度SCADA系统和电气设备绝缘在线监测系统的安全性要求高，电网MIS系统和以上系统的接口通信可以采用共享中间数据库的接口方式。监测系统将共享数据写人中间数据库，MIS系统通过面向对象数据库中各对象对应拓扑关系，形成一系列的对应关系表，使得监测系统应用软件(如实时潮流等)的计算结果和实时量测通过对应关系表进入MIS，以表格形式显示设备绝缘监测实时状态信息。
3.2 输电网络动态规划
目前，我国部分地区电力供应形势严峻，电力建设速度落后于经济发展速度，电力规划任务十分紧迫。本系统有助于提高输配电网络优化规划的工作效率。在高级应用中加入无功优化与经济运行分析模块，通过调用外部可执行程序实现对新的目标网架进行快速潮流计算分析，在满足负荷增长需求的同时优化系统潮流。当网络优化后生成规划报告，报请计划部门审批，以利于改善系统结构。
4 结束语
该系统使地区电网信息完整、统一、传输快捷，克服了以往管理方式落后、数据不统一、信息孤立等特点，完善了基础性的信息管理工作，实现了信息集成化、过程管理优化，还避免了资源浪費和重复建设，为电网改造、检修、故障处理及经济供电等相关工作提供了有力的科学依据，具有良好的经济和社会效益。
参考文献：
[1]田玲．基于PDM技术的电网管理信息系统[J].农村电气化，2005，33(1)：54-58.
[2]邸彦彪，孙羡.电网建设项目的系统化和信息化管理[J].情报科学，2004，22(5)：32-34.
[3]水力电力部西北电力设计院.电力工程电气设计手册[M].北京：中国电力出版社，1989：145-163.
[4]蓝毓俊.现代城市电网规划设计与建设改造[J].北京：中国电力出版社，2004：305-368.
[5]Microsoft China.Microsoft.NET开发框架[M].NY:Microsoft China .NET技术，2001：185-204.
[6]俞自强.ASP技术访问WEB数据库[J].中国科技信息，2006，8(3)：21-23.
在医院实现信息化集成平台 篇6
关键词：集成平台,Web Service,Ensemble,XML
1 序言
随着医院对于信息化建设的不断投入, 医院的信息系统越发的庞大与复杂。除了通常意义上的以财务为基准的HIS系统以外, 医院信息化还包括了RIS系统、PACS系统、LIS系统、EMR系统、OR系统、血透系统、体检系统、病理系统以及各专科使用的电脑系统等内容。这么多专业的信息系统构架成了一个个复杂的、但是又各自独立的信息系统。如何有机的将这些信息系统融合成一个完整的、信息相互交流的及方便的信息系统, 让医护人员在这种系统之间无缝的操作系统是医院信息科万分头痛的事。
2 原医院各系统之间接口的关系
为了保证在各个信息系统之间相互的交换数据, 通常采用各种各样的接口来让医院的各类系统进行相互通讯。但是因为每个系统之间采用的体系结构和技术都不相同, 而一个业务流程通常涉及到几个异构系统之间的数据交换。为了实现这些数据的交换, 以前常在各个系统之间架立接口。例如A系统和B系统以及C系统需要就一个业务进行交换数据, 我们就需要建立A→B以及A→C的接口。
然而, 这种方法存在很多缺点:采用这种方法就意味着, 在每两个存在数据交换的系统之间都必须开发一个接口, 如果有n个系统, 若需要实现其中任意一个系统对于另外 (n-1) 个系统进行数据交换的话, 必须开发 (n-1) 个接口, 对于n个系统则需要开发n× (n-1) 个接口。随着医院信息化的不断推进, 各个子系统数量的不断增长, 整个医院系统将形成一个象蜘蛛网那样错综复杂的结构, 如图1示。这其中任何一个系统出错, 都有可能引发一系列难以预计的后果, 并且这些错误更是难于检查与调整。
以往面对这种情况, 医院都是倾向于由一家软件公司完成整个的信息系统, 这样能避免出现这么多的接口。但是随着软件专业化的发展, 越来越多的医院希望集众家之长, 采用各种专业的系统搭建医院信息化的平台。然而, 由于这些系统由不同的公司提供, 所以接口通常采用的都是不同的交换协议与开发方式, 虽然使用的软件更专业发化, 但是越发的使医院整个的接口环境日益的恶化。每增加一个新的系统, 对于原来的接口平台以及正在使用的信息系统而言, 都是一次高难度的挑战。对于负责信息化的人员来说, 更是面对千头万绪的系统接口难以下手。但是面对医院日益高涨的信息化需求来说, 越发的迫切需要一种能更好解决这种窘迫情况的解决方案, 可以让医院信息中心和软件提供商更快、更容易的将专业的医院信息系统接入整个医院的网络环境中。
3 新集成平台系统的系统构架
湘雅医院的信息系统从2000年HIS系统的上线以来, 发展迅速, 目前已经有HIS、RIS/PACS、LIS、PEIS、EMR及OR等系统。除此之外, 还包括各个独立的系统:病理、血液透析、肾脏移植、肝脏移植等专科系统、综合查询及网上预约等周边系统。这些系统各自覆盖了不同的应用领域, 并且通常有一定的重叠。例如:在EMR中开一个住院病人的检查申请, 首先在电子病历中产生一条医嘱, 同时将这条医嘱往HIS系统中发送供护士工作站进行校对, 并向检查系统发送申请, 并在检查系统中, 对该申请进行登记预约和执行, 并返回每个步骤的状态给EMR供医生查阅。当检查完成后将检查报告返回给EMR, 同时对HIS进行计费操作。同时EMR系统亦可以通过返回的信息直接从检查系统中调取图像信息等。
这一完整的检查过程, 涉及到EMR、HIS及RIS/PACS几个系统。由医生站、护士站、收费系统及RIS/PACS等多个系统协同完成, 每个系统都不可拆分, 也不能单独看待。为了实现这些系统之间的信息交换, 医院采用了信息化集成平台的方案。该系统由Ensemble产品为基础框架, 并通过webservice技术和医院定义的XML交换标准来实现数据的交换。
如图2所示, 门诊挂号、门诊收费、住院登记、住院收费、电子病历、护士工作站及检验系统等所有的信息系统都通过集成平台发送接口消息。所有的接口消息, 由集成平台决定发送到哪个系统, 并返回相应的结果。这个通过集成平台新增加的系统, 只要遵循统一的标准, 就可以很容易的与其他系统进行通讯。
4 技术说明
该平台的技术结构及数据流如图3示, 它采用Ensemble架构, 通过Web Service技术和自定义的XML标准实现数据交换, 它的结构分为存储数据的数据库、对消息进行管理与实现的Ensemble集成平台、供用户提供和取得消息的应用程序这三层。
4.1 Ensemble平台负责进行消息之间的传递以及调配, 并确定消息在平台上的工作流
它是一个集数据服务器与集成服务器及应用服务器和门户开发于一身的产品。它具有全方位的集成与开发、通用服务构架、持久的对象引擎、可定制的端对端的管理的特点, 且极大的降低了整合所有系统的复杂性。该平台利用对象继承和SOAP服务可以方便的调用各类的webservice适配器, 以实现各个系统与平台的接口。并可以通过工作流工具直观的进行消息流程的定义与开发与调整。且支持同步和异步的集成。它对于无法提供接口的项目时, 可以直接该问系统的原有的数据和函数, 而对于所有传递的消息, 更能提供界面实时地访问消息仓库里的正在处理和已经处理的消息, 以用于审计, 并提供基于SQL的报表和管理界面。同时, 该平台通过共享元数据仓库和消息仓库, 避免了使用传统关系数据库所带来的成本和负担。本系统仅使用两台服务器就负担起来了全院消息传递的负担。
4.2 接口消息的具体实现和开发遵循Web Service技术
Web Service技术是一个基于XML语言、允许各种应用程序间通过复杂网络之间互相共享数据的技术、可以完美实现与所有技术与硬件平台进行接口的技术。该技术支持JAVA、.NET、PB、VB、VC等等开发技术。并且由于Web Service技术采用的是http协议, 所以更是可以跨平台, 跨网段之间进行通讯。由于对Web Services的调用是通过SOAP消息机制远程调用来实现的, 因此Web Services使用者与Web Services提供者之间是松散耦合的。更由于Web Service是一种部署在Web上的对象, 具备对象的良好封装性, 且Web Services采取简单的、易理解的标准Web协议作为组件接口描述和协同描述规范, 完全屏蔽了不同软件平台的差异, 无论是CORBA, DCOM还是EJB都可以通过这一种标准的协议进行互操作。
4.3 所有接口的消息参数, 全部采用了XML语言
XML是一种可扩展标记语言, 是跨平台的、依赖于内容的技术, 是当前处理结构化文档信息的有力工具。采用XML语言, 可以一次性发送一个或数个消息, 同时亦可以表达一对多的消息方式。同时, 对于接口参数来说, XML更是具有良好的扩展性, 随着信息系统的更新或增加, XML参数的调整对于原有的系统来说, 不会带来大量的变动与调整。
5 实现方式
为了更直观地说明这一实现的过程, 下面以检验单的申请这个流程为例, 来看它在集成平台系统是如何完成的。首先, 由EMR系统进行检验申请, 在申请结束后保存时, 由EMR系统向集成平台系统Ensemble发送了一个检验申请 (消息名InLab Apply) 的消息, 该消息采用XML格式作为传递的参数, 其参数格式如下所示:
该消息被发送到Ensemble平台后, 根据平台中该消息定义的工作流程, 首先向HIS系统转发了该消息。由HIS系统的Web Service解析该参数消息内容, 并将其保存进HIS系统的数据库中。一旦实现完成, HIS的Web Service返回一个成功信息给平台。平台收到成功消息后, 再将该消息发送给LIS系统。LIS系统采用Web Service方式调用该参数, 解析后将数据存入LIS系统的相关表中, 并返回了一个成功的标志给平台。平台收到两个成功标志后, 判断该流程完成, 并向EMR系统返回成功的消息。EMR系统对数据进行确认与提交。至此一个检验申请的消息完成, 所有的数据在EMR, HIS, LIS三个系统中进行了同步, 如图4。
6 结束语
经过三个多月的开发及调整, 以上所述的集成平台已经将包括EMR、HIS、RIS、PACS、LIS、OR、PEIS等等系统的医院大部分信息系统全部集成在一起, 传递的消息囊括了病人PID建档, 住院ADT流程, 检验申请/留标/报告流程, 检查申请/划价/收费/报告流程, 手术申请/预约/收费/结果流程, 病案归档流程。使医院的信息可以在各个系统之间无障碍的流转, 大大加快了信息化的建设。并为未来医院信息化新增加的信息系统做了准备。相信未来的医院信息系统依托该平台, 可以更快的与整个医院CIS信息系统形成完整无缝的结构。
参考文献
[1]CAO B, LEI SD, HUANG S, et al.Application and prospects ofENSEMBLE in building digital hospital[J].Modern PreventiveMedicine, 2009, 36 (7) :1274-1277.Chinese
[2]XU SH, JIANG W.Design of information integration platform inenterprise based on WebService[J].Computer Engineering andDesign December, 2007, 28 (24) :5969-5972.Chinese
医院门诊收费系统集成的实现 篇7
1 Web Service相关技术简介
Web Service是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行;Web Service是一种新的Web应用程序分支,是自包含、自描述的模块化应用,可以发布、定位、Web调用;Web Service是一个应用组件,它逻辑性地为其他应用程序提供数据与服务,各应用程序通过网络协议和规定的一些标准数据格式(Http、XML、Soap)来访问Web Service,通过Web Service内部执行得到所需结果。Web Service可以执行从简单的请求到复杂商务处理的任何功能,一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务[2,3,4,5]。
Web Service是一个创建可互操作的分布式应用程序的新平台,其目标在于实现跨平台的可互操作性,它是完全基于XML、XSD等独立于平台、独立于软件供应商的标准。Web Service标准本身是建立在进一步标准,如HTTP和XML的基础之上的,通过使用这些被广泛接受的技术,Web Service不依赖于任何专有的系统或厂商,这样就能在任何平台上使用任何语言开发对Web Service的支持,如.NET、Java、Perl等。本文用.NET开发对Web Service的支持,并通过Power Buider9.0的SOAP协议调用Web Service来实现医院各收费系统的集成。
2 基于Web Service的医院门诊收费系统集成方案
2.1 系统体系结构
将医保收费功能集成到地方收费程序中,收费操作在同一个窗口完成。系统会根据患者的费别进行判断从而进入不同的处理流程。系统体系结构分为四个层次,包括Web Service层、医保功能层、业务处理层和程序调用层;采用三层调用模式,医保功能层调用Web Service层、业务处理层调用医保功能层、程序调用业务处理层。其中业务处理层和医保功能层在程序中进行单独封装。这样一来,系统的集成性高,保证了低耦合性,在程序的移植和二次开发中更加方便快捷,系统体系结构,见图1。
2.2 关键技术的实现
2.2.1 Web Service的创建
打开Visual Studio,新建一个ASP.NET WEB服务应用程序项目,按默认情况,Web Service放在Servicel.asmx中,类代码放在Service1.asmx.cs中。首先,对医保相关动态链接库(DLL)进行引用,调用外部函数。以实现连接医保前置机功能为例,代码如下:
(1)外部函数引用医保接口提供的动态库,声明该动态库提供的函数,供程序调用。
[Dll Import("hnbridge.dll")]
private static extern long Initialize(string svr IP,long svr Port,int Snd Buf Size,int Recv Buf Size);
注:在调用DLL前,初始化调用环境变量。整个调用工程只需调用该函数一次即可。
[Dll Import("hnbridge.dll")]
private static extern long Create Instace();
注:创建一个功能调用实例。在进行一个新的功能调用前必须执行该操作,以取得调用的处理句柄。返回的句柄将成为其他功能调用的入口参数。
[Dll Import("hnbridge.dll")]
private static extern long Set Param(long p Data Handle,String param Name,String param Value);
注:提供功能调用的参数组,如功能号以及其他功能的调用参数。
[Dll Import("hnbridge.dll")]
private static extern long Run(long p Data Handle);
注:运行调用实例。p Data Handle:功能调用的处理句柄,由接口函数Create Instace()创建。
[Dll Import("hnbridge.dll")]
private static extern long Destroy Instance(long p Data Handle);
注:释放功能函数调用句柄。
[Dll Import("hnbridge.dll")]
private static extern long Get Sys Message(long p Data Handle,ref String Message1,uint n Max Message);
注:获取详细的系统信息。通过该函数可以获取功能调用的返回信息;如果系统发生异常,则返回最后一次错误的出错信息。
(2)定义Web Service方法。
将此Web Service发布成IIS方式供门诊收费程序调用。
2.2.2 医保功能层调用Web Service方法
使用Power Builder编程工具创建Web Service Proxy Wizard项目,程序在调用Web Service前必须引用一个pbwsclient90.pbd文件。所有医保功能封装在一个用户对象中,如u_ybinterface对象,该对象中连接医保前置机的函数名为uf_connect_yb,此函数调用Web Service接口代码如下:
3 应用效果与结论
我院门诊收费系统集成后,大大减轻了收费员工作量,同时也降低了收费的差错率;解决了集成前数据不一致的问题,使数据的来源更加可靠,程序维护起来更加方便。对新引入的业务系统能够通过这种方式,使用已经开发的Web Services接口实现与医院信息系统(HIS)连接[6,7]。
本文主要介绍Web Service技术体系以及实现我院门诊收费系统集成解决方案,针对我院多个门诊收费系统各自为政的弊端,结合Web Service的特点和要求,构建了一种动态的、可控的、统一的全面集成化框架模式。该集成模式突破了传统的集成方案在应用范围等多方面的限制,提供了松藕合的远程调用方式,完全屏蔽了不同软件平台之间的差异,不需要对现有系统做大的改动就可以实现集成的高可用性和高扩展性,拓展了现有系统之间的互操作能力。此技术对医院信息系统集成提供了一种新的思路。
摘要：目的 实现医院门诊各收费系统的集成。方法 使用Web Service技术解决方案实现医院门诊收费各系统的集成。结果 医院门诊收费系统的集成使得所有收费操作都集中在一个系统窗口,使收费更加方便与快捷,有利于提高工作效率。结论 此方案对医院信息系统集成提供了一种新的思路。
关键词：医院信息系统,门诊收费系统,Web Service,系统集成
参考文献
[1]夏慧,熊俊芬,张帆."军卫1号"工程与武汉地方医疗保险系统的对接[J].医学信息,2003,9(16):497-498.
[2]柴晓路.Web Services技术架构[M].北京:电子工业出版社,2003.
[3]端妮,郭文明,张雪林.基于Web service的远程放射系统集成模型研究[J].南方医科大学学报,2007,27(8):1203-1205.
[4]谭显东,李存斌,樊建平,等.基于Web Services的电力营销管理信息系统框架研究[J].计算机工程与设计,2008,(7):1820-1823.
[5]W3C.Web Service Architecture[EB/OL].(2004-02-11)[2014-03-01].http://www.w3c.org/TR/ws-arch.
[6]刘芳.分布式医疗信息系统互联技术[J].中国医疗设备,2012,27(5):108-110.
隧道综合监控系统集成技术的实现 篇8
随着城市交通建设发展的加快, 隧道作为城市道路系统的重要组成部分, 其综合监控系统随之迅速发展起来。隧道综合监控系统是一个典型的系统集成工程, 按功能可分为交通、通风、照明、火灾报警、紧急电话、闭路电视、电力监控等子系统[1], 其相关数据均集成进入控制中心的中央监控计算机系统。本文以云南昆明草海隧道、岗头山隧道工程为背景, 从软件和硬件两个方面分析, 讨论隧道综合监控系统的集成方法和系统互连接入。
1系统整体架构
隧道综合监控系统是一个在以太网基础上、基于客户/服务器 (C/S) 体系结构的全分布式系统, 由设在控制中心的中央计算机信息系统、被控子系统及通信网络三大部分组成, 系统整体架构详见图1。
通信服务器的设置主要针对各隧道独立配置, 共设置2台。通信服务器主要负责从底层的现场光纤环网上采集各个监控设备转输过来的数据信息, 以模块化软件为基础提供整个系统的实时数据库功能, 然后将处理好的数据通过监控中心的上层以太网送到数据库服务器中保存, 以保证高响应性和供统计分析时使用。
各个工作站实现实时监控和历史数据查询。当任何一个隧道的通讯链路发生故障时, 将不影响监控中心各工作站对其他隧道的监控;故障消除后, 监控中心恢复对该隧道各系统的管理监控功能。
通信网络采用先进的光纤以太交换环网, 配置工业级的以太网环网交换机, 极大地提高了系统的抗干扰能力并提高了系统的通讯速率和网路的带宽。同时采用VLAN技术, 根据系统的数据交互需求, 例如广播系统、紧急电话系统、PLC采集和控制系统等, 将网络划分为多个广播域, 限制网络上的广播, 将网络划分为多个VLAN可减少参与广播风暴的设备数量, 从而有效地控制广播风暴的发生, 不同VLAN内的报文在传输时相互隔离的, 可增强局域网的安全性。
2硬件系统集成
隧道综合监控系统将不同厂商的设备或子系统数据集成到统一的数据平台上, 在硬件系统集成方面主要需要解决作为下位机的各类设备、子系统的互连接入中央监控计算机问题, 下面介绍本系统进行硬件集成采用的三种接口形式。
2.1PLC系统接入
设备监控系统的通风、排水、电力监控系统的照明以及交通监控系统的交通信号控制等多个子系统通过区域控制器 (ACU) 及远程控制终端 (RTU) 系统接入控制中心, ACU及RTU系统的关键设备为可编程控制器 (PLC) 。
根据隧道群中各隧道的不同地域分布, 将其划分为多个独立的控制子系统, 每个子系统内分别配置PLC, 串口服务器及工业以太网交换机统一组网。PLC通过开关量输入/输出、模拟量输入、RS232/RS485通讯口等信号接入方式连接被控设备, 经PLC处理后存入各自的寄存器, 而通信服务器经由PLC获取各隧道被控设备的实时数据, 最终完成与控制中心的信息交换, 实现信号采集和远程控制。PLC作为现场控制的执行者, 执行有效的分散控制, 因此即使上位机系统发生故障, 也不会影响整个控制过程的正常进行, 大大提高了系统的可靠性。
2.2智能装置接入
被控系统设置有独立的智能装置, 完成本系统的数据采集和控制执行。例如隧道供配电系统的各变电所内高低压设备采用智能化设计, 在变电所实行无人值班, 在10 kV、0.4 kV开关柜中装有微机综合保护测量控制继电器, 集保护、测量、控制和通讯等多种功能为一体。隧道内安装多个车检器作为交通检测的测控设备, 检测出每一区间每一车道上的车流量, 平均车速, 车道占有率等交通参数。交通诱导系统的隧道内可变情报板和简易限速板支持显示内容和格式的编辑及发送。
这些智能装置通过以太网通信通道 (RJ45) 接入100 Mbps以太光纤网, 基于TCP/IP网络协议或采用工业应用的多串口服务器提供足够的串口, 与通信 (I/O) 服务器建立通讯, 形成信息交互, 从而实现控制中心实施对这些装置的管理, 以提高控制的及时性、精度及抗干扰能力。
2.3控制主机接入
众多自动化子系统, 包括广播系统、紧急电话系统、电视监视系统、视频检测系统和消防系统, 都是利用计算机通讯主机与自身系统中多种现场级设备信号线的I/O接入或联网通讯交互方式, 整合各级现场数据。同时这些通讯主机提供以太网通信通道RJ45接口和通讯接口软件, 基于TCP/IP网络协议接入通信 (I/O) 服务器, 使得控制中心能实现对各种现场设备的实时数据采集和控制命令的下发, 从而降低了控制中心的数据处理和传输负担。
3软件系统集成
隧道综合监控系统的软件构成是围绕着数据的处理和集成展开的, 将不同厂商的设备或子系统数据从现场设备最终传输到中央监控计算机系统中, 并在集成的用户界面上及时直观地显示。
整个软件系统基于美国GE公司的组态软件CIMPLICITY HMI开发。由于组态软件本身具有比较强大的数据处理功能和图形编辑功能, 所以可利用组态软件自身功能对整个系统完成了数据及图形界面上集成。下面介绍本系统利用组态软件进行软件集成的关键点。
3.1基于Modbus TCP/IP协议访问设备
Modbus TCP/IP 基本上是用简单的方式将Modbus帧嵌入TCP 帧中, 这是一种面向连接的传输方式。其实质仍是以太网的CSMA/CD 介质访问控制技术, 只是在应用层采用了确定性的客户/服务器式协议Modbus, 它适用于主节点和多个从节点的通信网络中[2,3]。CIMPLICITY HMI支持Modbus TCP/IP协议建立通讯连接。
如果硬件设备直接支持Modbus TCP/IP协议, 如PLC系统, 只需直接作为一个外部设备, 在组态软件配置中定义通讯的物理参数, 定义组态变量和下位机变量 (数据项) 的对应关系。在运行系统中, 组态软件和每个设备建立连接, 自动完成和设备之间的数据交换。
如果设备不支持该协议, 如视频检测系统, 广播系统, 则编制软件中间件提供Modbus网关功能, 软件中间件作为服务器, 定义相关的变量并和采集数据的硬件进行连接。然后充当客户端的组态软件应用程序, 将软件中间件 (服务器) 作为设备, 建立连接, 并且添加数据项目。在应用程序运行时, 将按照指定的采集频率对组态软件的数据进行采集。
3.2基于数据库接口访问设备
需提供文字功能的设备, 例如文字板和情报板, 往往通过开放特定数据库, 让用户获取和修改文字数据并进行处理, 最终达到用户控制情报板及文字板显示内容的目标。
CIMPLICITY HMI支持通过标准的ODBC接口登录到Microsoft SQL数据库, 将所需要的数据集成到组态软件的实时数据库里。在组态数据登录时, 用户只需简单地在 Windows操作系统中建立一个数据源, 设置远程连接对方数据库服务器的相关信息, 然后在CIMPLICITY HMI中进行相关脚本文件的编写, 调用相关的数据库函数和数据点操作函数, 在应用程序运行时利用事件触发功能执行脚本文件。
3.3基于串行通信协议访问设备
车检器和照明PLC与通信服务器通讯, 采用多串口服务器提供物理的485通讯口, 通过以太网接口融入隧道综合监控系统。CIMPLICITY HMI可通过串口方式与现场设备建立通讯连接, 在配置中定义串口通讯的物理参数。监控软件与现场设备的数据交换通过数据点的组态来实现。一个数据点可组态为只从现场设备中读取, 单向的数据传输方式;也可组态为既读又反写入现场设备, 实现数据双向交换。
3.4用户界面集成
CIMPLICITY HMI软件向用户提供了内置的、面向目标的友好的开发环境——图形编辑器 CimEdit, 使用户快速设计隧道内各种设备图元, 形象地描绘隧道中各个子系统。
隧道分为若干个子系统, 每个子系统都有其对应画面, 在设计软件人机界面, 应遵循一致性原则[4] , 使各系统的画面有相似的界面外观和布局、信息显示格式、及相似的人机操作方式。每个监控画面能够静态地显示隧道全貌, 同时运用动态数据链接, 在静态画面中动态地显示模拟量检测值, 用不同颜色来显示不同的设备开关量状态。同时各界面上的跳转按钮, 方便用户在各子系统的监控界面之间进行切换。
针对各类突发事件的预防与处置, 系统将需提供对应的各种预案, 往往涉及多个系统, 使各子系统的独自智能控制扩展为整个系统全局的智能控制, 完成整个系统的联动集成。软件功能的开发实现是基于CIMPLICITY HMI通过设定触发条件和动作, 编写相关后台脚本完成。用户在操作画面上可通过键盘/鼠标选择某一预案, 也可自行发出自认为正确的命令, 以控制事故的蔓延。
4结束语
隧道综合监控系统实现目标就是通过对系统的多个子系统进行集成, 将各子系统的状态能第一时间更直观的显示在操作员面前, 并将所有系统的数据统一存储, 备份与集成。本系统采用基于组态软件、PLC与工业以太网技术的集成方法, 从软件和硬件方面解决了各类设备、子系统之间的互连和互操作性的问题, 最终形成了一个多厂商、多协议、多接口和面向应用的整体性系统。目前该隧道群监控系统已投入运行, 运行平稳、可靠, 完全满足运营监控的需要。
参考文献
[1]王德虎.隧道监控系统典型解决方案[J].山西建筑, 2010, 36 (35) :367-368.
[2]郝晓弘;程晓辉;苏渊;Quantum系列PLC与上位机的以太网通信研究[J].电气自动化, 2005, (03) :40-41, 72.
[3]GB/T19582.3-2004, Modbus协议的工业自动化网络规范_第3部分Modbus协议在TCPIP上的实现指南[S].
集成实现 篇9
关键词：BMS集成,APOGEE系统,Insight软件,OPC技术
0 引言
随着智能建筑技术的不断发展, 其包含的子系统及设备也不断增多, 为了让用户能够快速方便地了解各种建筑设备的运行故障状态和对设备的控制, BMS系统随之产生。根据《智能建筑设计标准》中的定义, 建筑设备管理系统 (Building Management System, 简称BMS) 是对建筑设备监控系统和公共安全系统等实施综合管理的系统。BMS系统通过将将建筑物内的楼宇设备监控系统、火灾报警系统、闭路监控及防盗报警系统、智能一卡通系统、智能停车场系统、智能照明系统等各个子系统集成在一个平台上, 进行数据交换和共享, 将各个具有完整功能的独立子系统整合成一个有机体, 降低系统的运行费用, 提高系统维护和管理的自动化水平。本文以某项目的BMS集成实施为例, 讲述以西门子APOGEE楼宇控制系统为平台采用OPC技术进行集成的实施方法、步骤。
1 西门子APOGEE楼宇控制系统
APOGEE系统是西门子公司推出的一套完整的楼宇控制系统, 系统上层由Insight监控软件、系统网络和多种DDC控制器组成, 下层由各种传感器和执行机构组成。Insight监控软件是以动态图形为界面, 向用户提供楼宇管理和监控的集成管理软件。Insight软件基于windows2003/xp/2000操作平台, 采用client/server架构。Insight监控软件是一个具备第三方系统集成功能的监控平台, Iinsigh监控平台支持BACnet、OPC、Lon Works、MODBUS、EIB等协议。本项目中采用OPC接口方式实现与各子系统的集成功能。OPC协议是一个工业标准, 这个标准定义了应用Microsoft操作系统在基于PC的客户机之间交换自动化实时数据的方法。
2 BMS集成的实现
2.1 BMS的网络结构设计
本项目是一个大型公共建筑, 由多栋建筑组成, 各栋建筑分布范围较广, 整个项目的智能化系统分布在各个建筑内, 各建筑内的智能化系统由统一的控制中心来管理。本项目的BMS集成系统采用西门子APOGEE楼宇控制系统为平台, 由APOGEE系统的Insight软件平台实现集中监视和管理。考虑到智能化各子系统安装位置分散、分布距离广, 因此本项目中设计了以光纤为主干的三层路由交换局域网, 称之为楼宇控制专网, 楼宇控制专网由一台三层核心交换机及分布在各楼层的接入层交换机组成。楼宇控制专网既用于实现各子系统自身设备远距离物理连接, 也可使各子系统通过局域网与BMS集成服务器实现物理连接。BMS集成系统的平台监控软件为Insight软件高级版, 系统集成接口模块是OPC SEVER (5000PT) 。本工程设置了一间智能楼宇监控中心, 配置一台BMS服务器, 运行Insight软件服务端, BMS集成服务器接入楼宇控制局域网。根据本项目的需求, BMS系统需要接入的对象有:楼宇自控系统、数字视频安防监控系统;智能照明系统;入侵报警系统;出入口控制系统;电梯系统;冷冻站群控系统;变配电监控系统;消防报警系统。
2.2 子系统的集成方式
2.2.1 数字视频安防系统的集成
本项目视频安防系统是数字式视频监控系统, 视频及控制采用了接入数字编解码器后在以太网传输的方式, 数字编解码器接入楼宇控制专网内。此系统的生产商提供第三方开发的SDK开发包, 本项目利用此SDK开发包开发了一个接口网关, 该网关运行在BMS服务器上, 通过楼宇控制专网来完成与视频编解码器的数据交换。由于BMS系统的Insight平台提供的是OPC服务器接口功能, 而OPC方式是采用客户机/服务器模式来进行数据交换的, 因此该网关作为OPC客户端来访问Insigh, 同时也做为BMS平台的视频图像的显示及控制功能模块。
2.2.2 配电监控系统的集成
配电监控系统采用的是IEC104数据传输规约, 此规约是基于TCP/IP协议的网络传输协议。本项目中配电监控系统有多台通讯管理机, 配电通讯管理机通过自已的局域网进行互连。要实现BMS服务器与配电监控系统的数据交换, 需要配电监控系统局域网接入BMS楼宇控制专网, 因此将配电监控系统的交换机与楼宇控制专网进行了级联。在网络互通的情况下, 为了实现对配电数据采集, 开发一个软件网关, 运行在BMS服务器上。此网关按IEC104数据传输规约来取得配电数据, 并作为OPC客户端与Insight平台上的OPC服务器交换数据。
2.2.3 智能照明系统集成
智能照明系统有独立的上位监控主机, 并提供了OPC服务器接口, 将智能照明主机连入楼宇控制专网, 通过路由配置实现智能照明主机与BMS服务器的网络连接。由于BMS集成系统也是OPC服务器, 因此在BMS服务器上开发了一个OPC客户端, 由客户端来完成Insight平台上的OPC服务器与智能照明OPC服务器间数据转发。
2.2.4 冷冻站群控系统集成
冷冻站系统的设备由独立的群控系统进行控制, 该群控系统已预留了第三方集成接口, 此接口称为datalink连接单元, 有一个25针的连接串口, 工作方式是第三方设备通过Datalink的串口发送要读取的变量的指令。Datalink收到该指令后, 通过群控系统的CCN网络从相应的控制器中抓取第三方系统所需要的数据, 并通过Datalink的RS232串口返回给第三方系统。本项目中BMS服务器作为第三方, 以ASCII方式从串口读取数据。在此也开发了一个软件网关, 用于在对datalink串口数据读写的同时作为OPC客户端与Insight平台进行数据交换。
除上述子系统外, 其它几个子系统也均采用类似方式与BMS系统进行集成。由于本项目BMS供货合同中订购的接口模块是OPC服务端, 并非OPC客户端。基于OPC方式是采用客户机/服务器模式来进行数据的交换的, 因此需要在BMS平台上开发一个各子系统的软件网关, 既用来实现与硬件设备的通讯, 也实现OPC服务器间数据的转发功能。
2.3 BMS集成系统的组态
作为BMS集成实施的第一步, 解决了各子系统与Insight平台的数据通讯后, 接下为需要进行设备组态、画面组态、控制程序编写等工作。APOGEE系统的BMS集成组态工作是通过Insight软件平台来完成的, 包括系统结构建立、监控点的定义、监控界面的生成、控制策略的生成等步骤。
2.3.1 系统结构的构建
此部分主要进行系统网络和设备的设置, 包括系统网络的构建、服务器、工作站的定义、各种控制器的定义。系统结构的构建通过Insight软件的系统轮廓 (System Profile) 工具来进行的。在完成网络结构和设备的设置之后, 最终要以图形的方式来表现楼宇控制系统。在本项目中分别定义了工作站, BLN网络、FLN网络、DDC控制器、及串口的配置。
2.3.2 各子系统监控点的定义
Insight平台上的监控点可分点物理点、虚拟点, 本项目中通过DDC控制器的物理连接的点为物理点, 而通过OPC接口获取的点为虚拟点, 相当于一个变量, 用于存储从子系统获取的数据, 物理点与虚拟点以相同的方式进行定义。在本项目中从各子系统取得的数据在定义时按子系统的点表来进行命名。所有的点均通过Insight软件中的点编辑器进行定义并存于数据库内。
2.3.3 监控界面的组态
Insight软件的监控界面由Designer软件来生成, Designer软件是一个图型制作软件, 自带各种常用的图库, 支持各种图型、图片格式。通过Designer制作出BMS系统主界面及各子系统的监控界面, 监控画面包括BMS主监控画面、各子系统主监控画面、各子系统的分画面, 这些画面作为集中监控界面的背景图。将由Designer制作的背景图通过Insight平台的Graphics工具导入, 通过在Graphics中插入各子系统的背景图, 生成各系统的监控画面。要在监控画面上实现动态数据的显示、动画、画面切换等功能, 则需要添加相应控件。在Insight中提供了多种控件, 如点信息块、棒形图、图形链接、动画等控件。将控件添加到背景图上需要动态显示及控制的位置, 并关联上已定义的信息点。画面即可根据信息点的变化显示情况进行动态显示。
2.3.4 控制策略的生成
BMS集成的主要功能之一是系统的控制功能。系统的控制功能是由控制策略来执行, Insight的控制策略是通这PPCL语言编程来实现的。PPCL是一种类似BASIC结构的高级语言, PPCL的编程是在Insight的程序编辑器下进行。由于各子系统的数据在Insight平台上进行了统一的定义, 各子系统的点在BMS平台上可以看作是同一个系统的点, 可在PPCL语句中进行引用并实现对点的操作控制功能。夸子系统的联动功能也就是通过对各子系统的点进行编程来实现的。
3 结论
本项目所集成的子系统采用多种协议和接口方式, 要转换成标准协议, 实施起来较为复杂, 不仅要开发协议转换软件网关, 还需要进行大量的硬件及软件接口测试, 这也是集成过程花费较多时间去完成的工作。因此在工程整体设计阶段, 在进行系统和设备选型时需要尽量考虑集成平台的开放性和各子系统接口的标准化, 这样更利于系统集成功能的实现。
参考文献
[1]中华人民共和国建设部.智能建筑设计标准.GB/T50314-2006.
[2]APOGEE顶峰系统技术手册 (2006) .北京:西门子公司, 2006, 5.
集成实现 篇10
关键词：多媒体系统；系统集成芯片；IP物理实現
随着消费类电子产品的应用领域不断扩大，各种媒体处理技术快速发展。在这种背景下，处理器的性能已经成为影响系统运行的关键所在。从当前实际情况来看，以硬件为主的多媒体处理系统具有强大的计算能力，并且能满足多种环境下的多媒体系统运行。同时，IP物理实现技术的发展，为整个多媒体系统硬件系统发展提供了新的方向，已经成为未来多媒体处理系统发展的主要趋势。
一、多媒体系统集成芯片技术研究
当前在多媒体集成芯片设计中，主要包含了两个可编程的处理器内核。在这种情况下，为了更好的满足多媒体系统运行的要求，系统集成芯片在整个系统处理中，一部分有硬件提供信息处理能力，另一部分主要由软件提供设计的灵活性，确保能在最大程度上控制系统运行。在功能实现中，多媒体系统集成芯片主要依靠标准单元实现对整个系统运行的控制，在标准单元基础的支撑下，相关人员能从系统资料库中的各个单元版图上设置一个同一高度点，除了等高的标准单元外，还支持插入单元模块的工作，使整个系统的运行进一步达到预期水平。而在整个多媒体集成芯片的设计阶段，验证成为评价系统集成芯片的关键点，因此，往往会在主要步骤结束之后，就及时采用静态时序方法与逻辑验证的形式对整个系统集成芯片运行过程进行评价，了解多种状态下的流程搭配情况，进而确定屏蔽控制、间距等多个常规数据资料，确保能及时对可能出现的故障进行修复，最大程度上保证系统运行质量。同时，为了保证多媒体系统运行质量，还需要及时的定位问题信息，并立足于整个芯片操作过程，对其中的问题进行补救，争取能进一步完善系统运行。
在整个有关系统集成芯片硬件研究中，首先需要对硬件的基本结构进行划分与建模，以模型分析的方法，将整个系统进行细化，也能将其划分为多个系统结构，这样才能在最大程度上保证系统模块的运行质量。
二、基于建模视角的多媒体系统芯片研究
在当前工艺条件下，受多方面因素影响，时序模型不准确、信号完整性等都会对芯片后端设计工作產生不良影响。在这种背景下，如何快速确定设计可行性、明确系统的基本功能，成为相关人员关注的重点。因此，必须要通过模型分析的办法，对多媒体系统芯片的优化内容做进一步分析
由于在整个芯片设计过程中，其不同设计过程分别代表的不同的功能层次，因此在建模描述中，需要从高层次综合、逻辑综合、物理综合等方面展开分析。
（1）高层次综合：主要负责将系统的算法级行为进行描述，并将描述结果转化为寄存器传输级。在整个应用中，高层次综合确定了电路的宏观结构，并生成了相应的结构级结构试图，并明确了电路功能到操作符号之间的关系，并会对不同对应关系之间的执行结果产生影响。因此，高层次综合是整个多媒体系统芯片研究模型分析中必须要考虑的一点。
（2）逻辑综合：逻辑综合的主要内容就是将寄存器的传输级结构进行描述，并使其转化为逻辑级的结构。与高层次综合相比，逻辑综合确定了电路的诶管结构，并且不同逻辑原型之间的互连关系也会通过逻辑综合的形式表现出来。
（3）物理综合：物理综合主要负责将微观电路及结构进行描述，并使其转化为版图集的物理描述方法。从整个物理级的变化情况来看，依靠在不同版图上构建的电路拓扑结构，能进一步深化明确芯片的标准单元级别，并对其物理布局、几何形状等进行描述，进一步加深相关人员对多媒体系统集成芯片的认识
本文在综合上述三个层次后认为，由于现阶段芯片设计开始朝着大规模、高性、短周期方向发展，高层次综合与物理综合的应用范围将会进一步扩大，这将会进一步优化系统的运行结构，在未来，三种技术之间通过相互借鉴，能有效的完善系统运行的逻辑，进一步满足系统运行的要求。
三、基于IP物理实现的多媒体系统集成芯片研究
在综合考虑集成芯片系统灵活性和可复用性的基础上，本文认为在整个多媒体系统集成芯片设计中，必须要充分考虑工艺约束的影响。
1、整体布局规划。IP物理设计的实质就是模块级物理设计，需要确定模块形状，并做好模块端口位置分配，保证其分配情况能有效满足集成芯片内部布线的要求。
为了达到这个目标，首先需要严格按照模块内部的标准单元确定当前模块面积，并用常见的矩形来约束其形状。在这个过程中，软模块端口对于硬核物理规划中边界的一小段金属条，并依靠这个金属条来实现对全局信号的控制与互连。在这种条件下，这些金属条都被称为端口分配，是保证系统运行平稳性的关键。
2、时钟树规划。为了达到面积最优化的目的，硬IP设计应该具有较高的利用率，并按照不同的应用策略，保证其始终具有较高的运行水平。例如在高速MAC设计中，初始硬IP的设计利用率往往会超过81%，即使在对其布局线进行优化后，其整体利用率依然能超过70%。因此在时钟树规划过程中，应该对布线资源进行有效的分配，才能在最大程度上保证布线质量。
鉴于400MHz以上主频的设计目标，高速始终网络在系统内部容易对其他信号产生影响，因此针对这种情况，建议将时钟网络从常用的3/4层迁移至5/6层，使干扰点远离原有的信息处理关键层，这样系统的运行质量将会得到进一步的保证。
4、结语
本文重点研究了多媒体系统基层芯片与IP物理实现的相关内容，从本文研究内容来看，模块化分析解决多媒体系统基层芯片与IP物理实现的关键，在这个过程中，相关人员必须要加深对多媒体系统基层芯片技术的认识，并结合IP物理实现技术的相关内容，对整个多媒体系统基层芯片实现进行分析，保证其设计水平能达到预期。
参考文献
[1] 于鑫.基于信息物理系统架构的微机接口远程实验系统设计与实现[D].吉林大学，2015.
[2] 梁骏.高清机顶盒芯片设计中的关键技术研究[D].浙江大学，2014.
[3] 韩晓霞，SOC中的连线模型与面向布局布线的设计方法及时延/功耗优化方法研究[D].浙江大学，2005.
SAP与WMS集成设计与实现 篇11
SAP主要负责企业物料的计划管理,从采购计划、生产计划再到销售计划,记录物料计划数量、计划状态等。而WMS主要负责仓库内物料存放货位的管理,既可以记录库存数据,又可以控制自动化设备的运行。为使两套系统之间能实现信息共享,优势互补,一般采用接口集成的方式进行数据传输。
本文主要介绍了SAP系统与WMS系统的集成设计和实现方法。
一、接口设计
1. 确定接口字段
WMS与SAP为两个不同的系统,均采用不同的数据库,一般WMS采用SQL Server2008的数据库,SAP采用的是自己开发的数据库。因此,为使两者之间能够实现数据传输,需确定双方对接的数据字段。如表1。
输入参数为在WMS中输入的信息,如物料凭证号等。WMS将这些信息传输到SAP中进行通讯连接。
输出参数为SAP获取到WMS的输入参数后,在数据库中进行查询,将查询结果反馈给WSM的信息,如物料编号、名称、数量等。
2. 参数设置
为使双方系统能够通讯连接,需设置一些通讯参数,如SAP系统的服务器名称,服务器的IP地址、客户端号、用户名、密码、系统号、语言等。上述参数需提供正确,否则WMS系统无法从SAP系统中获取数据。如表2。
3. 接口流程图
SAP与WMS接口流程为在SAP系统中开发RFC函数,WMS系统完成对RFC函数的调用,其流程图如图1。
二、实现方式
1. 在SAP中创建RFC函数,编写代码,测试无误后,激活使用,如图2、3、4所示。
2. 在C#中编写调用SAP RFC函数代码。首先下载SAP NC03.0组件,安装后在其安装目录下会生成3个dll文件,在程序中引用“sapnco.dll”和“sapnco＿utils.dll”两个文件,编写调用函数代码。编写完成后,编译代码,生成应用程序后,在程序中输入物料凭证号即可从SAP中获取需要的数据。
三、总结
采用RFC函数技术为ERP系统与WMS系统对接提供了一种很好的解决方案,此方案屏蔽平台差异和数据库本身的差异,实现互联网范围内多种信息资源的整合,消除“信息孤岛”,降低劳动强度,提高作业效率。
摘要：SAP和WMS系统虽然都具有物料存储管理功能,但二者定义范围不同。为使两套系统之间能实现信息共享,优势互补,一般采用接口集成的方式进行数据传输。本文主要介绍了SAP系统与WMS系统的集成设计和实现方法。