校园一卡通解决方案Word文档格式.docx
《校园一卡通解决方案Word文档格式.docx》由会员分享，可在线阅读，更多相关《校园一卡通解决方案Word文档格式.docx（55页珍藏版）》请在冰豆网上搜索。
“尽量避免重大安全事故发生，降低小型安全事故发生频率，发生重大事故少损失数据，发生小型事故不损失数据”。
安全性设计主要从六个方面进行保证，即服务器安全、数据库安全、网络传输安全、应用系统安全、终端产品安全、卡片安全。
整个系统设计遵从中国人民银行有关标准，采用主密钥、工作密钥、扇区种子密钥、卡片扇区密钥、个人密码种子密钥、卡片个人密码密钥六个密钥组成系统的密钥体系，确保支付交易各环节的安全性。
数据及服务器安全则采用RAID方式、双机热备方式，支持多种备份方式，对于数据传输部分采用SSL（安全套接字）进行统一的通道加密，并对于其中的关键数据采用双重加密方式，对于应用程序在进行数据访问或进行服务器初次访问时必须通过证书服务器进行合法应用程序身份的认证；
在终端产品的安全性方面，采用黑名单与白名单并存的方式，在终端产品中保存有业务交易数据，脱机时可保证交易的正常进行和数据的完整性。
1．7扩展性设计
扩展性设计分为数据扩展、接口扩展、应用扩展三个部分。
数据结构设计按照教育系统信息规范进行；
接口扩展由于采用的支持热部署应用服务器技术，实现手段主要为WebService技术，在将来对接口进行扩展时只需在应用服务器中部署相关的接口即可完成；
应用扩展是在以上两点的基础上进行的，且放进系统必须通过证书服务器的认证。
1．8兼容性设计
在逻辑上提供紧耦合、松耦合、不耦合三种方式，在技术实现上提供WebService、Com+、EJB三种方式，在数据兼容实现上能提供文件、数据库表两种方式，一般可根据学校的具体要求进行有效的配合使用。
第2章系统特点
2．1数据平台独有的开放性
宝石“校园一卡通”系统在数据平台的设计上，采用了中心数据库服务器/应用服务器/工作站三层结构，并选用热部署的应用服务器软件，用户可以在应用服务器上自主开发中间层软件，并映射到中心数据库服务器，实现用户应用软件的定制。
2．2商务消费有效的三重保障
在校园网正常的情况下，可保证中心数据库中的用户余额与每个消费系统实时同步，因而可有效地防止透支情况的发生；
在校园网出现问题的情况下，消费系统和中心数据库可分离运行（半脱机状态），消费系统由网控器进行管理，采用黑、白名单进行合法身份认证，网控器可存储消费数据10万条，并可进行容量扩充；
在消费系统也出现问题的情况下，消费终端和消费系统网控器也可分离运行（全脱机状态），采用黑名单、校园卡进行合法身份认证，消费终端中保存当前的消费或业务流水，
无论是校园网还是消费系统出现问题，当故障消除之后，系统会自动进行数据上传，保证全局的数据同步。
2．3系统的模块化、功能化设计
宝石“校园一卡通”系统采用积木式结构，不但可以进行应用组合，而且也可以进行功能组合。
可以根据不同的用户需要进行不同的组合，也可根据不同的用户权限进行不同的组合，如：
可以做到一人一个使用权限，而每人都有不同的功能。
2．4联机/脱机可选择消费方式
由于“校园一卡通”系统依赖于学校的校园网，网络不通或不顺畅的情况是一定存在的，但对于学校的某些业务应用，如餐饮系统是不能够停止使用的，所以本设计的所有终端设备产品都具有联机/脱机两种模式，即使在脱机的状态下也不会影响应用系统的正常使用；
使用脱机模式有两种方式，一种方式是半脱机状态，这种状态由网控器进行管理，采用黑、白名单进行合法身份认证，在网控器中存储所有的脱机消费数据，基础容量为10万条，并可通过增加存储芯片进行容量扩充；
另一种方式是完全脱机状态，这种状态由POS机进行统一控制，采用黑名单及卡片双向验证的机制进行合法身份认证，此时在POS机中保存当前的消费或业务流水；
当故障消除之后，系统会自动将这一部分未上传的数据上传，并自动进行全局的数据同步。
2．5硬件无关性设计
目前，各个学校都已经使用了各种卡应用系统。
宝石“校园一卡通”系统从客户的角度出发，设计了先进实用的软件应用系统，对硬件的依赖降至最低，可以实现硬件的无关性。
第2部分用户需求分析
第1章用户背景
XXXXX大学占地XXX万平方米，学校本部设有XX个本科学院，还设有XX等X个学院；
开设涵盖哲、经、法、教、文、史、理、工、农、管X个学科门类的共X个本科专业，全日制及各类在校学生近XXXXX名。
学校现有餐饮收费、网上选课、办公自动化等XX套应用系统。
网络建设采用先进实用的网络通信技术和计算机技术，建立了一个覆盖全校所有建筑和机构的综合网络，目前联入校园网的有XX栋楼，XXX个信息点。
整个网络分为教学区和宿舍区，形成了一个技术先进、高效优质的校园网络系统。
第2章一卡通需求分析
2．1功能需求
●“校园一卡通“系统的应用范围覆盖每一个校区；
●在各校区内，凡涉及到现金使用的任何一个消费网点，校园卡的帐户都能通用，所有商户单位不论其性质与规模都可以授权代理收款、结算，商户资金可以实时到账；
●用校园卡取代各个校区以前的各种证卡，实现宿舍楼、学生公寓的身份识别一卡通；
所有用证、用卡的信息管理系统，其身份识别部分都连通“校园一卡通”系统，实现身份识别的数据共享；
实现校内所有重要场所的出入门禁管理，包括校门、图书馆、学生宿舍楼等，提高学校的安全管理水平；
●与各子系统的挂接与捆绑，将传统商务消费系统平稳过渡，减少投资；
数字化校园建设中的其他MIS系统、OA系统，可以通过平台预留的扩展接口实现与“校园一卡通系统”的数据共享；
取代各校区原有的各类借书证、卡，实现与图书馆管理系统、电子阅览室等系统的对接连通，做到系统软件直接扣除罚款的紧耦合连接；
实现与教务管理系统的对接，实现学生按学期的学籍注册管理，实现教学资源、生活设施的使用控制；
实现宿舍楼、学生公寓的用电控制管理、公共浴池的用水控制管理；
在不同操作系统、不同数据库基础上构建开发的公用机房上机收费管理、校医院挂号收费管理、宿舍楼出入门禁、教职工考勤管理、学籍管理、安全保卫的巡更管理等第三方子系统，都可以实现与“一卡通系统”的挂接与捆绑；
●借助银行提供的自助终端设备，持卡人可实现银行卡的自助业务；
在各校区建立统一的校园自助查询系统，包括电话查询，网上查询，触摸屏查询，领导查询，为持卡人提供24小时全天候服务；
●实行“两卡合一，物理分离”，即银行卡与校园卡物理上分开，但形式上表现为一张卡、逻辑上统一。
卡片由银行统一提供，采用非接触式加密IC芯片卡片背面加磁条的形式，在校园内通用，具有多钱包功能，同时，具备金融借记卡功能；
●通过自助圈存、自动批量等多种方式实现持卡人银行卡—校园卡实时自助转账功能；
●“校园一卡通“系统不受校区的限制，银行卡可以充分享用银行的各项信用卡业务，如异地通存通兑、商户消费、网上银行、电话银行、银证转账、代收付等；
●通过建设结算中心，对所有校区、商户实现统一结算和管理。
2．2网络需求
●利用校园网已铺设的光纤建立“一卡通”专用网；
●专网主干通过网控器将所有的485网络连接起来形成下层为RS485采集转发网络；
●一卡通专用网通过路由器、防火墙、前置机及专线与银行专网相连，实现“校园一卡通”系统的实时银校互通；
●一卡通专用网通过交换机及防火墙与校园网连接，为全校师生提供基于校园网的管理信息查询；
●所有一卡通系统的子应用将挂接在校园网上，对于挂接于校园网上的所有一卡通子系统将进行必要的认证；
●远程单位或校园网未通连接到的信息点可以采用拔号或租用电信线路的方式与一卡通专用网络实现互联；
●路由协议及各基层单位的地址规划；
●在专用网的二层交换机上划分VLAN，对不同的访问设定不同的端口，降低校园网广播风暴对一卡通系统的影响。
2．3安全性需求
由于一卡通系统建立依赖于校园网，其所有的数据传输也依赖于校园网，所以要求采用防火墙技术，设立应用前置机，减轻中心数据库的网络压力，一卡通系统接入校园网的第二层交换机采用具有路由功能的交换机，在其上划分VLAN，保证一卡通系统的逻辑隔离，使不同的工作站有不同的访问通道，VLAN技术的采用即提高了网络的安全性，又降低了广播风暴，在一卡通系统与校园网的连接方面设立应用网关，实现一卡通网与校园网的逻辑分离。
一卡通中心数据库平台采用Unix/Linux操作系统，中间层对于关键的数据进行加密处理，对所有请求连接或请求访问的数据进行身份验证。
后台服务器采用双机热备技术，存储设备使用磁盘阵列技术，并提供多种备份机制，从根本上保证一卡通系统的数据安全性。
数据库采用Oracle数据库，对于不同的数据库用户设写不同的访问权限，并对重要数据建立相应的视图，从而避免对于重要数据的直接访问。
2．4扩展性需求
所有网络产品均采用国际标准化产品，保证通用和扩展。
主干网利用校园网，校园网点均可直接使用，方便接入和扩展。
子网线路按照标准局域网星型结构设计，终端产品相互隔离不在一条总线上，增加或减少终端产品数量不会影响已挂接使用中的终端产品，保证了扩展性。
一卡通平台软件产品采用三层结构设计开发，标准模块化结构设计，集成、拆分、维护非常方便，用户经授权可以自行定义和组织这些标准模块，利用我公司用户权限功能分配系统可以按不同的用户生成不同的应用系统；
软件系统采用积木式的应用模式，可以进行方便的功能拼接。
从软件升级方面，由于软件集中安装在应用程序服务器中，局部升级实现了功能模块的“热拔插”技术，升级不影响系统的正常运行，为软件升级带来极大的方便。
系统的WEB查询采用B/S结构，同时其他部分可以分步进行结构升级。
由于学校的发展，其应用的功能也在不断的发展，一卡通系统建立之后，其后续的扩展也是整个一卡通系统应用所应考虑的一个重要的课题。
我公司的一卡通系统平台采用三层结构，采用RPC方法调用，RPC通讯方式采用WebService技术，传输所采用的上层传输协议为XML的SOAP协议，下层可以选用HTTPS、SSL、TSL等；
开发语言采用JAVA，所以可以达到跨平台的效果，在一卡通平台的层次上保证了学校可以采用不同的操作系统增加不同应用。
一卡通系统也是实际意义上的学校的数据中心，其数据与全校其他系统的数据共享，由于采用WebService及EJB技术，将来进行扩展时在应用方面的扩展时只需在中间层中部署相应功能的插件，就可以与一卡通系统共享数据，而并不会影响到一卡通系统的正常运行。
第3部分方案设计
第1章总体结构设计
宝石“校园一卡通“系统的定义是在统一平台的整体调度下，以校园网为传输媒体、以卡片为信息载体，在学校内实现商务消费、身份识别、社会应用及查询决策等功能，实现全局数据共享，并提供扩展及兼容方案，为数字化校园建设打下基础。
1．1网络拓朴图
1．2系统功能图
系统主要由一卡通管理平台和业务应用系统两大部分组成，其中一卡通管理平台是整个系统的核心，它对整个业务应用系统进行管理和控制。
第2章一卡通管理平台
2．1体系结构
平台体系结构：
C/S+B/S结构+多层结构；
操作系统：
Unix、Linux、Windows98/NT/2000/2003
数据库：
Oralce9i数据库
开发语言：
Java+.Net+Delphi
2．2系统体系结构图
2．3系统功能
2．3．1维护业务
●学校基础信息维护
用于维护学校的基本信息，其学校编码采用《教育部教育信息规范》中统一规定的全国学校的统一编码，以便将来实现校际联网时使用；
●学校各级部门维护
维护学校中所有的部门信息，在此表中包含所有的学校部门，按属性可分为人事、行政、教学等，各部门之间的关系利用父级科室代码进行关联；
●用户组维护
对所有可使用本系统的用户按组进行分配，同一组中的用户所使用系统的权限是一致的，也就是说对于用户的管理采用分级管理的方式；
●系统功能设定
用于维护一个用户组其应有的功能；
●登录用户维护
对有权力使用本系统的用户进行统一的维护，登录用户与单位员工表中数据关联，也就是说只有本单位的员工才有权力登录以至于使用本系统；
●系统功能分配维护
对系统中的所有功能进行维护，以便在进行功能设定时有所选择。
●卡片类型维护
维护卡片的类型，如M1卡、ID卡，对于可以读写的卡片，有卡类型中对其所要使用的扇区进行动态的分配；
●用户类型维护
维护用户类型，如是学生、教师、特困生等；
●单位员工维护
维护本单位中的所有的教职工信息，可与人事系统对接，采用同类的格式；
●系统参数设定
维护系统的参数开关，本系统采用模块的方式，不同的参开关所使用的功能有所有同；
●卡应用范围维护
此部分内容用于维护卡片使用的范围，主要有全局类型及各区域类型，与卡表中数据相对应；
●营业部门维护
此表主要由业务部门进行维护，由一卡通中心统一管理，主要用于对于各类数据的统计；
●数据字典维护，包括民族、地区、办学性质、学校类型、专业信息、文化程度
这一部分维护采用国家统一编码，与国家标准保持一致；
●专款专用信息维护
对专用款项进行分类管理，并指定使用专款的用户科室或部门。
2．3．2卡户管理业务
●加密管理
对学校中的卡片进行管理，对所有的学校内可用的卡片进行加密处理，卡片加密采用的是动态密钥的方式，实现一卡一密，有效防止伪造卡的出现；
●挂失管理
持本人持有效证件到卡管理中心或指定的挂失地点进行办理。
提供电话挂失、网上挂失、触摸屏自助挂失，触摸屏自助挂失、电话挂失或网上挂失需要提供校园卡密码；
●解挂管理
持卡人找到丢失的校园卡后，可持本人有效证件到卡管理中心办理解挂或在触摸屏上自助解挂，触摸屏自助解挂需要用户输入校园卡密码才能生效；
●补办卡管理
持卡人到卡管理中心进行补办登记；
卡管理中心使用银行已授权卡执行补办操作，发放补办卡；
●注销管理
持卡人持有效证件到卡管理中心办理销户并上交校园卡，得到退款凭证；
一个工作日后，凭退款凭证到卡管理中心领取退款；
●临时卡借用
学校的短期培训学员应使用临时卡；
采用一卡发行的学校，当学生丢失校园卡后通常不能立刻补办新卡；
根据银行的规定，卡丢失一周以后才予以补办，所以在这段时间，学生可以借用一张临时卡，供消费使用；
●临时卡归还
持卡人到卡管理中心办理临时卡归还手续，领取押金；
卡管理中心进行归还登记，收回临时卡；
●卡延期
超过有效期和退役期的校园卡如需继续使用时，需到校园卡服务中心进行卡延期确认方可继续使用；
●卡片拾遗管理
当丢失的卡被拾到后，由系统自动记录此卡片的一些关键信息，并记录拾卡人的姓名，并在学校的电子公告版进行实时发布。
当丢失人未能发现自己的卡片信息来进行挂失时，系统可以自动提示挂失人，此卡在X区已经被人拾到，可到该区去领取。
当已挂失补卡后又找回原来丢失的卡时，处理这两张卡之间的关系，最后只保留一张卡。
2．3．3账户管理业务
●开户管理
单卡开户：
操作员录入持卡人基本信息，卡业务管理模块为持卡人分配卡号；
卡管理系统使用银行已受权卡执行开户操作；
持卡人领取校园卡；
批量开户：
注册中心提供新生详细信息文件；
卡管理系统处理信息文件，获得系统代码文件；
卡管理系统使用系统代码文件执行批量开户操作，为用户分配卡号，并生成开户文件；
开户文件送到银行进行批量制卡；
负责人到银行领取校园卡发给用户。
●销户管理
单卡销户：
操作员录入持卡人基本信息，管理中心根据卡片的信息进行销户处理，同时系统自动扫描整个网络的连通情况，如果有系统没有实时通讯，将提示用户由于有系统未能连通，对于退款事宜将延后进行，在网络连通的情况下，系统设计默认退款时间为1天（24小时）；
卡管理系统通知银行与银行卡相关的卡片已经注销，回收卡片；
批量销户：
管理中心提供需要进行卡片注销的用户群体情况；
卡管理系统使用系统代码文件执行批量注销操作，回收卡号，并生成相应的销户记录；
通知银行关于批量销户的用户信息；
自动判断系统连通状态，如正常连通，将在24小时后退还卡片押金及卡内余额，如不连通，视连通情况而定，回收卡片。
●一户多卡管理
同一账户有多张卡片，多张卡片使用这一个账户的余额，此部分功能公文即于商务消费系统，对于身份认证系统，只有主卡有效；
建立账户主表，记录此账户拥有人的信息，同时生成账户主卡信息；
生成子卡表，与主卡记录相对应；
当主卡挂失后，并不影响子卡的使用；
子卡挂失后，不影响主卡的使用；
消费记录统一记录到主卡账户中，但对于消费明细将分别记录。
账户密码修改
持卡人凭有效证件可以到管理中心进行修改密码操作，也可以通过电话和网上服务修改账户密码。
2．3．4财会管理业务
增款业务
主机增款：
持卡人刷卡，验证持卡人信息；
输入增款金额，并按学校规定的规则进行实际增款金额；
增款完成；
POS机增款：
由POS机增款员通过钥匙卡打开增款机；
持卡人刷卡，进行卡正确性判断；
输入增款金额，确认后，数据实时生效。
圈存业务
详细内容内社会应用部分的描述
退款管理
当天未进行财务结算时退款，由退款操作员查找所生成的错误数据，并根据此错误生成一条退款记录，保存到退款记录表中，此数据的内容格式与原收款数据完全一致，当进行财务结算时，原收费记录与退款记录同时参加运算。
当天财务结算已经完成，首先由退款操作员查找到错误的收款数据，并根据此错误数据生成一条退款记录，此退款记录时间记录为当前时间，其它格式及内容与原收款数据完全相同，当进行财务结算时，原收费记录不参与运算，只有此退款的数据参加报表的生成工作，从而保证前期及后期报表的准确性。
补贴发放
单个补贴：
找出未能及时领取补贴的用户资料，由申请补贴人刷卡，验证此用户的合法性；
输入补贴金额，确认合法；
生成补贴资料，并增加用户余额，同时生成补贴记录及相关报表；
集体补贴：
由相关部门提供需要进行集体补贴的用户资料；
由补贴操作员导入用户数据，进行集体补贴；
生成相应的补贴资料，并增加补贴人的账户余额，同时生成补贴记录及相应的报表；
类型补贴：
根据不同的类型的持卡人进行不同的计算，生成相应的补贴金额。
校内转账
由转出人刷卡或输入其身份识别信息，并输入个人卡户密码；
由转入人刷卡或输入其身份识别信息；
由转出人输入要转出的金额，确认无误；
生成转账记录，同时在转出人账户扣除相应的金额；
在转入人的账户中增加相应的金额；
生成转账报表。
学杂费收缴
由教务部门提供学杂费应收缴人员的明细资料，上报财务部门，由财务部门统一进行收费处理。
专款专用
在学校中，存在各种补贴，这些补贴学校要求必须做到专用的补贴用到专门的项目中，比如伙食补贴必须用于食堂，而洗理费则只能用于浴室、理发室等相关的场所，并且在各部门所使用的POS机上要显示相应的金额，在其它不使用专款的地方则要求显示非补贴部分的金额。
系统设计原则是基于“以数据库中的数据为准”，采用“以卡为准”的方式只作为意外、突发事件的一种应急补救措施。
呆账处理
对于由于系统错误所产生的数据，本系统将这些数据集中进行保存，并生成相应的呆账报表提供给财务部门。
统一财务报表
⏹营业日报
⏹营业月报
⏹转账报表
⏹银行圈存对账报表
⏹账目平衡表
⏹存款/取款率情况
⏹开户/销户情况
⏹各消费子系统按月消费统计
⏹单位整体账务变动情况统计（包括商户）
⏹商户整体账务变动信息统计
⏹各商户营业情况对比（总额/月发生额）
⏹整体及各商户账务变动情况统计
借、贷（现金/转账）、存款、押金、管理费。
⏹整体及各卡户账务变动情况统计
⏹整个单位卡户的账户/账务变动情况统计
⏹借（现金/转账）、贷（现金/转账）、存款、押金、管理费，发生额（含统计图）持卡人总数，挂失、冻结总数等
⏹整个单位持卡人消费情况统计
2．3．5实时监控
主要功能：
●数据库的监控：
对后对中心数据库进行监控，可以主动提取数据库的日志文件供参考，并可监控数据的使用负荷。
●应用平台监控：
包括三个部分，第一是监控结算平台，第二是监控业务平台，第三是监控查询服务器。
·
结算平台监控
监控结算平台的工作状态是否正常，如不正常将报警，网络连接情况、IP地址，并可对工作量进行智能分析；
业务平台监控
监控业务平台的工作状态、使用情况、IP地址、与业务平台交互的用户情况、与之交互的硬件设备情况；
查询服务器监控
监控查询服务器工作是否正常、IP地址、目前的工作量、与之交互的工作站情况。
●工作站监控
显示工作站的工作状态、工作量、IP地址、机器名称、工作站用途、与工作站相连的消费终端的情况。
●终端设备监控
监控终端设备的工作状态、是否存在故障、是否已经连通、终端设备工作量。
2．4硬件配置（三个可选方案）
方案
：
IBMXSERVER255，双机热备
名称
厂商
型号
配置
服务器
IBM
XSERVER255
868511x
内存512M，硬盘18.2G，CPUXeno1.5，DVD光驱，双通道，网卡，一块ＳＣＳＩ卡
网卡
3C509
１０／１００Ｍ
SCSI卡
Ultral
29160
磁带机
00N7991
４０Ｇ
阵列柜
豪威
5960U
带有６块希捷ＳＣＳＩ硬盘
双机热备软件
Microsoft
DataWareWin200
二个方案可任选其一
IBMAS400270（#2248），单一服务器
厂商
型号
配置
ＡＳ４００
＃２２４８
内存256M，硬盘最大可支持４２１G，ＣＰＷ值为４００
IBMRS6000S80，单一服务器
名称
ＲＳ６０００
Ｓ８０
内存64G，
升级会员 