银行自助设备监控系统.doc_第1页
银行自助设备监控系统.doc_第2页
银行自助设备监控系统.doc_第3页
银行自助设备监控系统.doc_第4页
银行自助设备监控系统.doc_第5页
已阅读5页,还剩26页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

本科毕业论文题目银行自助设备集成监控系统作 者: 王锐 专 业: 电子信息工程 指导教师: 岳贤军 完成日期: 2015年5月29日 诚 信 承 诺 书本人承诺:所呈交的毕业设计是本人在导师指导下进行的研究成果。除了文中特别加以标注和致谢的地方外,其中不包含其他人已发表或撰写过的研究成果。参与同一工作的其他同志对本研究所做的任何贡献均已在文中作了明确的说明并表示了谢意。 签 名: 日 期: 本论文使用授权说明本人完全了解南通大学有关保留、使用学位论文的规定,即:学校有权保留论文及送交论文复印件,允许论文被查阅和借阅;学校可以公布论文的全部或部分内容。(保密的论文在解密后应遵守此规定)学生签名: 指导教师签名: 日期: 南通大学毕业论文摘 要随着经济的腾飞,各家银行为了拓展服务,方便顾客,增加竞争力,均采购了大量的自助设备。从ATM(自动取款机)、CDM(自动存款机)、POS(销售点终端),到多媒体自助服务终端、缴费易等,设备种类越来越多,功能也越来越复杂。但是,由于自助设备的软件平台标准一直没有统一,目前绝大多数的银行都是采用前置系统的方式管理各种设备, 造成其前置系统也不能有效统一, 这直接导致银行对不同的自助设备机具需要有各种不同的应用服务系统,包括各种设备的监控系统,相当的繁杂,更有甚者,每种品牌都有不同的监控,造成运行、管理、维护、权限控制相当不便,人力资源浪费严重,因此也已有相当多的银行开始着手实施统一的自助设备处理系统,而统一的自助设备监控平台也有着迫切的需求。本课题旨在突破以往银行自助设备监控类型单一,规则简单,集成能力差,集成过程复杂,实施成本高等弱点,以自主知识产权的技术平台,形成针对银行自助设备机具的统一集成监控产品。本设计成果不仅可以应用在银行自助设备监控系统中,还可以应用在政府、医疗、教育等行业。关键词: 数据处理;自助设备; 监控; 服务系统II南通大学毕业论文ABSTRACTWith the rapid development of economy, the banks in order to expand the corresponding business, let customers more convenient, increase competitiveness, procurement of self-help equipment for large. From the ATM (automatic teller machine), CDM (automatic teller machine), POS (point of sale), to multimedia self-service terminal, payment and so on, more and more types of equipment have sprung up, the function is more complex.However, due to the standard software platform of self-service equipment has not unified, most banks are managing various equipment using front end system, causing the front system can not effectively uniform, which led directly to the bank needs to have various application service system of self-service equipment monitoring system of different, including a variety of devices, quite complex, moreover, each brand has different monitoring, operation, management, maintenance caused considerable inconvenience, access control, serious waste of human resources, self-service equipment processing system and therefore have a considerable number of banks began to implement a unified, and the self-service equipment monitoring platform unified also are in urgent demand.The purpose of this project is to break through the single bank self-service equipment monitoring, the former type of rule is simple, poor ability of integration, integration process is complex, high cost of implementation of weakness, with independent intellectual property rights of technology platform, form a unified integrated monitoring products for the bank self-service equipment. The design results can be applied not only in the self-service equipment monitoring system in the bank, but also can be used in government, hospital and other industries.Keywords: Data processing, self-service equipment, monitoring, service system南通大学毕业论文目 录摘 要IABSTRACTII目 录I第一章 绪 论11.1 本课题研究领域的现状和发展趋势11.2 研究的目的与意义11.3项目现有科技水平及知识产权情况21.4 课题形成成果的商业化应用前景2第二章 研究开发内容和主要任务42.1 项目重点研究开发内容和主要工作任务42.2 必须解决的关键技术和可能面临的技术困难42.3 项目主要的技术创新之处42.4 课题设计总目标和主要技术5第三章 研究试验方法、技术路线及工作方案83.1 具体研究方法、步骤和数据分析83.1.1 机具监控数据处理分析83.1.2 机具网络状态处理分析103.2 研究试验方法11第四章 测试与分析134.1 测试概要134.1.1 测试项目134.1.2测试目的134.1.3测试用例设计134.1.4 测试环境与配置134.2 测试结果154.2.1 功能测试154.2.2 性能测试164.3 分析总结184.3.1 iMon银行自助设备集成监控系统 M端分析结果系统功能184.3.2 iMon银行自助设备集成监控系统 V端系统功能18第五章 结束语20参考文献21致 谢22附 录2325第一章 绪 论1.1 本课题研究领域的现状和发展趋势国外分析:据调研分析,国外此类集成监控软件厂商较少,未见明确表示支持多种自助金融设备集成监控的产品。鲜有几家公司,如HP表示有类似的解决方案,如“HP NonStop Business Service Management solutions”,但也局限于对交易分析和问题管理的集成,并非专业的集成设备监控系统。国内分析:国内有厂商提供相关品牌的金融自助设备监控,但大都为专用监控系统,不能完成不同品牌、不同型号的集成监控;即使表示能够完成集成的产品,也存在如下缺点:集成能力差,缺乏标准的软件集成思想指导;集成方法、过程及其复杂,二次开发难度高;常见仅支持B/S或者C/S一种,不能同时支持双模式管理;计算算法过于简单,不能满足实际应用中复杂的需求;产品灵活性不够,对未来和预见性的环境、资源变化时适应性差。本项目的后台处理核心软件,在技术实现上依托于“iMon企业集成智能监管平台软件”。该软件主要致力于从企业全局出发,对企业内部所运行的各种软件系统、硬件设备进行统一整理,从中提取监测、控制和分析的需求,制订系统监控、数据采集、报表汇总的整体解决方案。平台以VC+7.0为开发工具,结合.net、php等Web应用技术,采用ACE(Adaptive Communication Enviromnent)开发平台,作为操作系统无关性及各类通讯机制开发的基础,以自主开发的LCom组件技术为受控设备组件软件实现基础,利用自主知识产权的LeisureC 描述解释语言研发而成。使用该平台软件可以以EAI的思想实现自助设备运行系统的软件集成,可靠实现对各种自助设备应用数据的集成分析。本项目预在以下方面的超过其他同类产品:系统依托于成熟的“iMon企业集成智能监管平台软件”核心技术,实现对所有监控设备的软件集成,达到平台级的智能集成及管控;系统计算核心稳定,外部接入方便。同时支持多种应用模式,包括统一的和非统一的自助设备服务系统;同时支持C/S、B/S模式;提供高可用性和持续性,简单方便的二次开发和集成接口;统一的机构、用户、权限管理模型。1.2 研究的目的与意义随着时代的进步和信息技术的发展,银行业也得到了迅猛的发展,各类银行如雨后春笋般的成立,银行的自助设备数量急剧膨胀。为了更好的管理使用这些设备,增加竞争力,提高客户满意度,对自助设备进行有效地统一集成监控产生了巨大的市场需求。通过详细而周到的调研,信息化监控手段可以有效的提高行业的服务质量,实现对服务过程的跟踪、设备运行的维护,在今后几年对于自助设备机具的统一监控一定会获得大面积的推广及实施。国内相关的IT企业应要抓住这千载难逢的发展机遇,大力发展具有自己技术特色、具备自主知识产权的自助设备集成监控产品,充分发掘市场需求,把握核心技术,为软件行业开辟一条新的产业方向。而借助于成熟的监控平台,能够大大缩短产品的开发时间,从而迅速的占领市场,赢得先机,这也是从商业目的考虑,研发此项目的最大因素。本项目的研制不是单纯的对目前银行自助设备机具监控手段进行的补充,而将成为行业的领军产品。其思想和技术,不仅局限于监控产品,而且对于EAI(企业应用集成)也是有效地实践和验证,为EAI产品开发提供有力的实践基础。1.3项目现有科技水平及知识产权情况一直以来银行自助设备监控多以项目实施形式,针对某品牌或某型号设备,又或以某家特定的银行为基础,在实现上更多的是更多依靠硬件厂商自行开发。随着时间和需求的变化,几乎每家银行都有多种品牌、多中型号的自助设备,而对于相关监控产品必须站在技术前沿的角度,从大局出发,统一筹划,才能形成一个完备的、符合大部分客户需求的集成型产品。本项目在技术和产品推广上有以下一些优势:软件实现上基于自主产权的“iMon企业集成智能监管平台软件”核心技术:实现了对多种数据接口自助设备智能集成监控。改变了目前大部分监控厂商以项目实现某种特定品牌、型号监控的局限性,大大提高了该领域产品的推广性。以EAI模式实现产品整体架构:集成流程管理、决策支持系统、业务功能的松藕合、基于组件的应用程序、分布式、事件驱动、安全服务、元数据存储。同时支持多种模式的客户应用系统架构:轻松应对复杂多样的银行应用体系架构,方便快捷的完成各种应用数据的转换、集成。同时支持多种类型、品牌、型号的金融自助设备机具:标准的接入接口,可以很快构建以多种ATMC、ATMP、POSP等为输入数据源的自助设备控制系统。同时支持C/S、B/S多种模式管理:实现以C/S管理,B/S灵活呈现的现代监控系统,取两种系统所长,避两者之短,获得更好的用户体验。1.4 课题形成成果的商业化应用前景从前文分析可知,银行业对统一的自助设备集成监控的需求非常迫切,市场巨大,毋庸置疑。目前,国内外同类产品仅仅只能单一或几种品牌、型号的用户接口,本项目采用EAI思想为指导,以稳定的iMon智能集成监控平台为基础,一旦完成产品化建设,在商业化推广中具备以下优势:价格优势强:以成熟稳定的平台为基础,大大降低了应用实施的成本,与同类产品相比,Imon银行自助设备集成监控系统可以以相当高的性价比赢得更多的市场份额。应用范围广:提供对多种类型、多种品牌、多种型号的统一监控,不受银行的实际应用环境、机具状况的限制,本系统拥有比其它同类产品更多的市场应用范围。第二章 研究开发内容和主要任务2.1 项目重点研究开发内容和主要工作任务本项目重点研究开发内容包括:多种类金融自助设备机具的监控特征分析:以典型设备为参考,提炼分析监控、业务特征数据,形成金融机具监控的数据标准,满足绝大多数银行的监控需求。多种银行电子渠道接入报文特征分析:重点分析多种多样的数据交换格式:固定格式和字符字符分隔方式、xml 格式,bitmap 等方式、ISO8583报文、XML报文、TUXEDO FML报文、类8583报文等金融行业常用报文封装方法,提炼统一的接入转换模型。统一的机构、用户、权限模型:以引擎模式实现内外部用户、机构、权限管理的无缝连接,满足各种不同单点登录需求的工况,以最小代码开发代价,获得最高灵活度。灵活高效的计算引擎:以类似与C 语言语法的解释性语言:LeisureC完成计算的灵活性,用户可用方便地通过集成开发工具编写脚本,实现自定义的计算方法。实现编译器编译脚本,形成高效的三元式,满足运行时高效处理。2.2 必须解决的关键技术和可能面临的技术困难多样式外部应用数据报文与监控系统内部XML报文转换算法:各家银行使用不同的应用系统,有着格式各样的报文格式定义,需要有统一的高效转换算法和灵活的报文定义工具实现外部报文转换。多样的数据呈现模式:多种类、多地区(机构)的设备管理模式,给监控带来呈现的难度,需要有合理的算法、方法灵活地呈现设备的状态,交易的状态。C/S和B/S模式高效结合:图形化监控内容如何能够同时支持C/S模式和B/S模式,而且对用户体验没有差异感,这是作为商业监控系统必须解决的问题。灵活的用户权限管理,单点登陆: 解决银行现存的系统和监控系统的单点登录,解决用户管理困难也是作为现代商业软件系统必须要解决的。全文搜索引擎:监控的目的在于应用维护,避免造成浪费。因此需要为此构建相应的知识库,全文搜索引擎需要满足对数据库、文本、Offic文档、PDF文档等常见信息源的内容搜索需求。2.3 项目主要的技术创新之处金融机具监控集成性:突破以往银行自助设备监控类型单一,规则简单,集成能力差,集成过程复杂,实施成本高等弱点,以自主知识产权的技术平台,形成针对银行自助设备机具的统一集成监控。基于C+实现EAI,突破EAI基于WEB 的自然技术架构:EAI的技术思想,受微软、Bea、IBM等巨头的行业规矩安排,各种于自身的技术平台之上构建了相关的EAI产品。而Imon银行自助设备集成监控的实现模型则打破了传统思想统治,形成以C+开发语言的不依赖与Web技术, 但却支持B/S 及 C/S 的系统结构。为EAI产品开发拓宽了思路,提供了实践理论依据。灵活高效的监控规则计算引擎:应对不同银行的管理需求,对设备的硬件模块、业务种类、运营时间等统计因子,提供灵活高效的规则设置、计算方法,较之同类产品,可谓是实现了跨越式的改变,先进了一个时代。2.4 课题设计总目标和主要技术课题总目标:图2.1 系统建成网络架构图图2.2 监控系统平台组成通过Tcp/Ip方式,对各类自助设备完成状态和交易的监控,可以满足国内大部分银行的自助设备集成监控需求。项目实施市场化操作后,可以根据不同用户不同的需求,选择相应的处理设备和软件模块。主要功能及技术指标1) 运行支撑系统l 服务主控框架提供框架管理平台内部各种服务,实时检测个服务模块状态,实现整个平台内部各个子系统的统一管理。l 规则解释引擎提供对系统运行过程中采集的实时或历史数据进行跟踪调试,包括设置断点、单步运行、查看规则属性数据等。通过智能规则引擎的使用,用户可以方便地了解系统告警的具体流程和详细的实时数据流信息。l 流量管理引擎可以灵活的获取监控的统计信息,并可以通过各种图表方式呈现。l 配置管理通过可配置数据库可以对系统内部各子系统的实例、操作员等信息进行管理。l LCom组件系统LeisurePlatform基础技术平台采用ACE(Adaptive Communication Enviroment)技术规范,实现了操作系统无关性,同时以LCOM的组件技术为基础,实现了分布式应用监控。平台提供标准组件供用户使用,对于特殊的应用可以通过集成开发环境实现快速定制开发。l HawkEye代理框架自助设备一般不能直接以探测点方式直接从C端获取监控数据, 因此需要以统一接口形式的代理模型,完成设备数据的差异屏蔽,无缝连接外部设备监控数据与系统内数据格式的转换和清洗。充分利用实时、定时机制,完成对受控设备的监视和控制。l 标准服务监控平台内置多个服务:注册服务、Ftp 服务、短信服务、Email 服务、Web 服务等。这些服务可以用于内部数据交换及告警消息发出。l 任务驱动监控平台提供任务驱动,对于组件的配置更新、动作等可通过任务驱动来实现。2) 集成开发环境监控平台提供集成开发环境实现快速定制开发特殊的LCOM应用组件,包括XML定义、代码生成、组件打包、组件注册、组件更新等功能。3) 数据总线监控平台采用共享内存技术实现的高速数据总线,形成进程间共享的XML 容器。同时总线引入消息队列机制,一旦数据总线的数据到达事件触发,就会通过消息队列通知伺服进程进行数据处理流程驱动。总线把树转化成二叉树,利用二叉树的线性存储技术,对二叉树采用深度优先算法,实现整个报文结构的快速查询。4) 数据分析系统包括数据抽取、数据聚合、报表/图表等模块,在本项目中通过数据抽取接口将告警事件等信息导出。表2-1 产品达到的主要技术指标序号指 标1实现多种金融机具:ATM、CDM、POS、CDT、ASM运行状态、交易状态的统一监控2同时支持C/S、B/S模式3平均故障发现时间160G Hd时,最大容量大于2000台设备第三章 研究试验方法和工作方案3.1 具体研究方法、步骤和数据分析3.1.1 机具监控数据处理分析机具类型包括:ATM、CDS、CDM、ASM等几种设备类型的机器。监控状态数据包括:读卡器、凭条打印机、日志打印机、密码键盘、存取款模块等各机具模块状态。监控的交易数据是自助机具与银行处理核心之间的数据交互报文,如自助机具的存款、取款、转账、查询等功能。机具将功能交易数据发送处理核心,核心进过分析后返回数据报文,告知该交易继续或是被终止。由于终端自助机具的交易实时性要求比较高, 数据交互时通过加密传输。Imon监控系统与机具通过TCP/IP协议交换信息,这种方式下,机具既是服务方,又是客户方。监控系统会随时呼叫机具终端,发送控制命令;机具终端执行完成后,需要呼叫监控中心,发送执行结果。通信方式:通信协议:TCP短连接。数据包组成:包头+包体。包头:共4个字节,是包体的长度(ASCII),如“0123”表示包体长度是123字节。包体:指正式报文。本节以后所说的报文,均指这个部分。例如:应用层欲发送一包“abcd12345”,共9个字符。则实际发送时,前面加入四个字符的包头,最后网上实际发送:“0009abcd12345”:应用层包文实际发送长度n+4长度n图3.1 数据传输简图接收方可先接收四个字符,再转换成整数,根据其值收满后面部分,这样可完整地接收到全部报文。如果包体内容长度不满包头所指定的长度,则视同通信出错,可直接拆线。表3-1 机具终端的回应码回应码解释00成功01设备号不符02设备处于维护状态,不能处理03文件不存在04版本号不对:大版本跳跃太大05版本号过低06命令不存在07解报文出错11FTP操作开始00FTP操作成功14FTP操作失败20软件更新失败21广告图片名与配置文件中记录文件名不一致22版本文件不存在23软件升级时,解压出错24升级补丁包丢失25写配置文件错26复制升级包至目标文件夹下失败27配置文件里,广告总数为098其他错误RW设备加钞后发送的第一个设备状态表3-2 部件状态表部件名取值表devATM总状态:O=正常;C=暂停服务状态;S=系统维护;钞箱总状态:0=正常;1=少钞;(所有取款钞箱或循环钞箱为少钞或无钞)2=无钞;(所有取款钞箱或循环钞箱为无钞)3=故障;(所有钞箱为故障)4=未安装;(所有钞箱为未安装)5=将满6=已满(所有存款钞箱、循环钞箱为钞满)注:该状态不用C端上报,V端根据各钞箱信息自动识别mbox1钞箱一状态:0=正常;1=缺钞;(仅当钞箱为取款钞箱或循环钞箱时)2=无钞;(仅当钞箱为取款钞箱或循环钞箱时)3=故障;4=未安装;5=将满6=已满钞箱一类型:0=废钞箱;1=回收钞箱;2=取款钞箱;3=存款钞箱;4=存取款循环钞箱;钞箱一面额:0100=100元面额;0050=50元面额;mbox2钞箱二(同上)mbox3钞箱三(同上)mbox4钞箱四(同上)mbox5钞箱五(同上)mbox6钞箱六(同上)mbox7钞箱七(同上)mbox8钞箱八(同上)MKS读卡器:0=正常;3=故障;4=未安装;CDM出钞模块:(状态同上)CIM存款模块:(状态同上)BV验钞模块:(状态同上)EPP加密模块:(状态同上)JP日志打印机:0=正常;1=少纸;2=无纸;3=故障;4=未安装;RP凭条打印机:(状态同上)3.1.2 机具网络状态处理分析机具的网络状态既是是机具终端与前置核心的网络状态、也是指机具与监控的网络状态。由交易数据处理分析流程可以看出,在生产中会出现机具与监控网络状态不正常时,机具可以对外提供服务,可以进行交易处理。针对这中情况,监控综合两方面的实际情况,在监控探测机具网络状态失败时,还需要检测机具在30分钟内是否有交易上送。3.2 研究试验方法本系统将采用理论研究、算法分析、实验调试同步相结合的开发方法,具体步骤如下:l 研究实验关键技术点:1. 研究多样式外部应用数据报文与监控系统内部XML报文转换算法2. 实现多样的数据呈现模式3. 研究图形化模式下C/S和B/S模式高效结合4. 全文搜索引擎算法研究l 协议及算法分析1. 研究、抽象典型银行、各类设备的通讯协议2. 研究、抽象典型银行的电子渠道服务程序的通讯协议和算法l 实验调试1. 模拟设备接口的测试、实验与调试、优化。2. 协商关系银行或公司,租用其测试环境实验、测试,并调试优化。l 以敏捷模型进行软件设计、编码第四章 测试与分析4.1 测试概要4.1.1 测试项目验证iMon银行自助设备集成监控系统管理功能(M端)是否满足概要设计的需求;验证iMon银行自助设备集成监控系统监控功能(V端)是否满足概要设计的需求;验证iMon银行自助设备集成监控系统在应用环境中的总体性能。4.1.2测试目的验证iMon银行自助设备集成监控系统是否满足业务需求,并将过程中产生的各种测试文档及最终测试总结报告提供给上海银行参考,为实现系统上线后成功运行,做充分的准备工作。4.1.3测试用例设计表4-1 功能测试M端功能测试352例M端第一轮回归测试352例M端第二轮回归测试352例M端第三轮回归测试352例测试案例_针对监控(NCR)76例测试案例_针对监控(东信)76例测试案例_针对监控(广电)76例测试案例_针对监控(怡化)76例测试案例_针对监控(长城)76例第一轮集成测试26例第二轮集成测试26例第三轮集成测试26例性能测试机具增加、删除机具修改多场景执行(获取机具最新状态、机具信息查询、机具信息修改)稳定性测试4.1.4 测试环境与配置-表4-2 测试结果M端32iMon管理服务器V端70iMon监控服务器P端0应用服务器ATM(怡化)13(18003069)测试机ATM(长城)74(18003066)测试机ATM(东信)11(18003060)测试机ATM(广电)62(18003065)测试机ATM(NCR)63(18003062)测试机本次测试,功能部分通过手工测试的方式进行,应用在测试环境搭建完毕后,根据测试案例执行测试用例;性能测试部分,通过Loadrunner Vgen录制脚本,然后通过场景执行工具controller进行特定场景执行,最后通过结果分析工具analysis工具进行测试结果的分析。测试工具有HP公司的LoadRunner创建虚拟用户脚本工具Virtual User Generator;HP公司的LoadRunner创建、运行实际场景工具Controller;HP公司的LoadRunner分析测试结果工具Analysis。Loadrunner最大的特点就是它可以模拟多个并发用户进行负载测试。这些用户在Loadrunner里被称为虚拟用户(Virtual user),测试人员可以通过文档或数据库等方式很灵活得导入每个虚拟用户测试数据。它不仅提供了友好的用户界面,并且还提供了以C语言为基准的测试脚本编辑接口,方便测试人员对所录的测试脚本进行编辑,从而扩展所要测试的功能。Loadrunner的工作原理:Mercury LoadRunner向运行的测试代理机器Agent发送测试指令,测试代理机器运行经过编的脚本,模拟多个用户同时向服务器发出请求,测试在不同条件下服务器的响应情况。图4.1 性能测试工作原理图LoadRunner 通过Virtual User Generator捕捉客户端向服务器发送和接收的数据流形成脚本框架。在此基础上利用的脚本定制向导自定义测试数据,使用数据表或随机数模拟现实环境的用户数据输入。创建内容检查点,验证负载下的被测系统是否出现功能错误。通过Controller并发指定数量的模拟用户运行以上设置好的脚本,确保测试尽可能接近真实环境,最大程度地反映系统的实际情况。性能监控与分析:在前台使用LoadRunner模拟多用户并发访问的同时,后台将使用性能监控与分析工具对服务器系统的资源消耗情况进行性能分析。4.2 测试结果4.2.1 功能测试表4-3 功能测试图被测系统测试案例数发现缺陷数未解决缺陷数M端功能测试352例158例0例M端第一轮回归测试352例16例0例M端第二轮回归测试352例0例0例M端第三轮回归测试352例0例0例测试案例_针对监控(NCR)76例17例6例均为P端上送报文与预期不同但不影响V端界面的显示,所以不修改不影响使用测试案例_针对监控(东信)76例20例7例其中:6例为P端上送报文与预期不同但不影响V端界面的显示,所以不修改不影响使用1例为机具本身无S状态测试案例_针对监控(广电)76例16例5例均为P端上送报文与预期不同但不影响V端界面的显示,所以不修改不影响使用测试案例_针对监控(怡化)76例16例5例均为P端上送报文与预期不同但不影响V端界面的显示,所以不修改不影响使用测试案例_针对监控(长城)76例17例7例其中:6例为P端上送报文与预期不同但不影响V端界面的显示,所以不修改不影响使用1例为机具本身无S状态第一轮集成测试26例10例8例其中:6例为P端接口及加密平台未就绪未测2例为测试机无存款功能未测第二轮集成测试26例1例1例其中:1例为等待P端UAT换版流程结束4.2.2 性能测试图4.2 平均响应时间与用户关系图用例编号002-ATMVedit-L性能描述V端接收机具的增删改交易8小时用例目的V端接收机的具增删改命令,查看在长时间执行情况下V端响应的情况及系统稳定性前提条件系统正常运行特殊的规程说明无用例间的依赖关系无场景设置方式场景分别为50用在线执行虚拟用户进入时间点默认为同时进入思考时间设置为normal脚本循环次数与执行时间对应网络带宽设置为当前环境最大带宽执行目标源设置为localhost50用户在线执行8小时用户数交易量平均响应时间失败笔数CPU50128494笔2.7392笔使用前14%使用中37%使用后15%图4.3 平均响应时间和图吞率关系图图4.4 机具修改图4.5 4000机具吞吐量与响应时间关系图图4.6 运行8小时图吞量与响应时间关系图4.3 分析总结4.3.1 iMon银行自助设备集成监控系统 M端分析结果系统功能M端功能能够满足需求说明书所述功能,缺陷曾主要存在于被监控资源信息反馈及用户体验性方面。系统性能M端可以支持100用户同时在线50用户并发(预估在线峰值为250)且能保证良好的响应时间。由于系统数据读取操作多为异步处理对系统资源消耗影响不大,系统资源峰值均一般均出现在用户登录阶段。单由于异步处理增加了线程数的开销,在用户量及请求量上升后,会出现用户请求排队而造成页面响应时间变长,极端情况下可能会造成页面请求失败。在测试环境中,模拟3000台机具情况下,M端系统获取最新机具状态响应时间及系统资源消耗均比较理想,随着机具的增加,会出现获取最新状态失败的情况,在4000台机具的情况下会出现4%左右的失败请求,在模拟5000台机具的情况下,失败增多。4.3.2 iMon银行自助设备集成监控系统 V端系统功能iMon银行自助设备集成监控系统功能能够满足需求说明书所述功能。受控设备下挂组件在超过30后失败率增加,建议最优下挂组件在15个左右;框架允许的组件并发数为3,故在设置组件监测时间时应将轮询时间错开以避免进程排队造成的监控结果延迟(一般情况下延迟时间不会超过一个监控周期);由于每个受控server由单独HawkEye服务监控,所以受控系统间不会存在轮询时间冲突问题;总结:iMon银行自助设备集成监控系统端性能可以支持当前业务需求: 表4-4 监控系统性能指标技术指标名称单位约定技术指标实际达到技术指标最大容量大于2000台设备台单主流PCServer最大容量大于2000台单主流PCServer最大容量大于3000台平均故障发现时间秒小于120秒小于30秒多种管理模式种支持两种模式支持两种模式支持多种金融设备种集成ATM、CDM、POS、CDT、ASM集成ATM、CDM、POS、CDT、ASM第五章 结束语通过一年的努力,本项目顺利的按照既定计划进行研发,攻克了多项关键技术和技术难点,统筹规划,实现了项目制定的技术功能和技术指标,完成了合同中规定的研发任务。在目前已经试用的其他银行中有些客户提出了由于银行的自助机具涉及的内部管理部门较多,而且对于硬件模块的维护有些采用外包的方式,因此对于不同的硬件及软件模块故障告警应可灵活的分配到不同的角色人员,同时对告警的时间段对于不同的角色也应该具备定制化功能。对于该问题,软件已经进行了调整,将设备到组件两级告警动作拓展到N层,可以有效彻底解决以上问题。目前修改后的软件已经在上海银行测试环境进行测试,可在近期内完成产品的升级。参考文献1 李庆莉.未来五年银行信息化七大建设重点解读中国银行业“十一五”信息化建设发展规划J. 中国金融电脑, 2008, 33(5): 27-31.2 陆尚俊, 王珩.网络信息监控系统的设计与实现J. 中国金融电脑, 2005, 25(12): 95-96.3 陈军, 史代敏.信用卡客户价值比较分析J. 中国信用卡, 2005, 33(11) : 5-12.4 戴霞.银行卡客户营销分析系统的设计与实现J. 现代金融,2005, 36(11): 9-22 .5 庞瑞江.国内银行业客户服务中心的过去、现在和未来Avaya中国区CRM总监罗军访谈J. 中国金融电脑, 2005, 33(11) : 7-19.6 李气宁.商业银行运营与管理制度的研究J. 企业导报, 2005, 12(11): 4-11 .7 张燕, 经纬.对银行自助设备集中管理的思考J. 时代金融, 2005, 21(11): 16-19 .8 洪运锡,詹珽,高应波基于XM

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论