1、手机端页面文档仅支持阅读 15 页,超过 15 页的文档需使用电脑才能全文阅读。
2、下载的内容跟在线预览是一致的,下载后除PDF外均可任意编辑、修改。
3、所有文档均不包含其他附件,文中所提的附件、附录,在线看不到的下载也不会有。
近年来,随着市经济的飞速发展,客运发送量持续增长,根 据统计,年以市为出发地,旅客发送量达到万人次, 其中铁路公路客运民用航空和港口发送量所占比重分别为 和,公路客运居于第二位再比较十五期间平均复合增长率,公路客运实现了的增长,仅次于民用航空,统计数 据详见表。
可见,公路客运与铁路运输和民用航空起,共同构 成了最主要的旅客运输行业,增长趋势非常明显。
表旅客主要出行方式比较 年旅客发送量万人次年发送量比重十五期间复合增长率 公路客运 铁路 民用航空 港口 鉴于此,公众媒体和监管机构对公路客运行业的关注度不断提 高,行业动态不断见诸报端。
旅客希望在出行前和出行过程中能获得 更准确完整的班次信息,并借助电子客票方式预先购票也希望发 挥公路客运灵活便利的优势,对班线的调整能够满足出行目的地的 变化,班次的供应量能够满足需求量的变化。
监管机构为提供和谐的出行环境,需要对客运经营者的班线经营 状况实施监管,运输车辆流动性的特点决定了这种监管是动态的此 外,班车客运的线路调整运力投放站点安排班次线路走向等 决策都需要营运数据的支持。
另外,必须注意到现有平台的设备趋于老化,故障率逐年上升, 同时缺少灾备系统支撑,威胁了平台的安全稳定运行。
因此,从满足旅客当前或潜在的出行需求的角度,从加强监管 科学决策的角度,以及从平台的安全稳定运行角度来看,将行业基础 信息与营运信息互相整合,重新构筑系统,扩大系统的使用面,建立 灾备系统,已经彰显出其必要性。
项目建议的依据 交通部长李盛霖最近就交通信息化工作指出在信息化时代,交 通信息化建设要跟上发展形势。
加强交通信息化建设是提高政府管理 水平和宏观调控能力的需要,是增强政府公共服务能力的需要,是提 高交通行业竞争力的需要,也是建设创新型行业的需要。
项目建议书编制同时依据以下文件的有关要求和指导精神。
交通部公路水路交通信息化十五发展规划提出建 立公路公众出行信息服务,通过整合信息资源,提供全方位的公众出 行信息服务。
通过信息技术与业务的结合使各级交通主管部门的管理 决策能力公共服务能力应急处理能力以及企事业单位的市场竞争 能力得到较大提高。
充分运用信息化手段提高政府对交通行业的整体 监管水平。
市建设交通系统信息化工作规划纲要 提出城市建设交通领域信息化建设基本实现管理对象的数字化管理 过程的数字化和管理评价体系的数字化。
市市城市交通十五发展规划提出实现长三角 及周边省市公路客运信息查询服务和远程监控系统,推动区域内联网 售票进程。
市市长途客运行业十五发展规划提出继续推 进信息化建设,充分发挥公路客运信息平台的作用,拓展信息查询和 服务等功能,形成以长三角及周边省市为主要腹地的长途客运信息网 络,实现省际道路客运信息化智能化管理。
信息系统需求分析 现状和存在的问题 系统设备老化 市公路客运信息平台的设备在年采购配臵,年是服务 器常规使用年限,般到第年设备厂商停止对产品的服务,很多设 备配件停止生产。
若不及时更新,如果系统设备出现故障,将面临无 法修复数据丢失行业运营被迫停止的风险。
至今公路客运信息平台已连续运行超过四年,历史上服务器硬 盘内存磁盘阵列等硬件故障发生的频度统计详见图,历年 故障造成的系统累计中断时间也越来越多,见图。
从年起, 硬件故障频发,最近的次较大故障发生在年月日,因硬 件损坏等原因,当天系统中断,次日凌晨恢复,客运站虽启用 了手工开票等应急措施,行业营运秩序受到较大影响。
年年年年 时间 故障频度 图平台硬件故障发生频度 年年年年 时间 系统累计中断时间分钟 图故障造成服务停止时间趋势图 平台没有灾备系统 年建设初期,由于受资金的约束,没有将灾备系统纳入建 设范围。
以年月日故障为例,如果具备灾备系统,在系 统故障时可快速切换,确保平台的正常售票。
因此灾备系统的缺失无 疑放大了硬件故障发生时的风险。
出行者得不到全方位的服务 虽然本市公路运输的旅客发送量仅次于铁路,但面向旅客的信息 服务却难以令人满意。
旅客在出行前很难获得本市的客运班次信息 公路客运行业的班次变动频率远远超过铁路民航,更无法利用 电子支付手段购买电子客票目前本市仅实现了中心城区五大客运站 间联网售票,远郊区县旅客购票要付出较高的隐性成本旅客即使赶 至客运站购票,站内也无法显示实时的余票信息。
系统功能未达到行业管理要求 市公路客内存容量需求分析 本项目系统数据库由票务信息交易日志交易流水三部分组成。
每张票务的信息平均大小为左右,每笔都要记交易日志,日志的 平均大小左右,每笔交易都要记交易流水,交易流水的大小为 左右。
票务信息交易日志和交易流水都按照保留三个月进行统计 票务信息容量 交易日志容量 交易流水容量总体数据容量要求。
而数据库系统在缓存容量达到数据库总容量的时性能较好,因 此,数据库缓存大小为。
从而计算出系统内存需求 为 操作系统所占的内存 数据库管理系统所占的内存 中间件等系统软件所占的内存 应用程序所占的内存 数据库缓存 合理的内存利用率 总计内存容量需求为 存储容量需求分析 除了上述联网售票系统票务信息的存储容量要求之外,还有政府 行业监管需要的客运流量流向等辅助决策类信息,这类数据需要保存 年。
这样存储容量为。
为避免存储系统成为系统性能的瓶颈,系统存储系统的使用率应 小于,采用镜像方式存储数据。
因此总的存储容量为 安全需求分析 市公路客运信息平台保存传递和处理的数据都是经营和管理 的重要数据,未来的运营和监管越来越依赖这些数据的完整性和准确 性。
如果由于安全因素导致系统崩溃系统数据丢失,数据泄漏信息不准确等情况的发生,将会对用户在各方面造成很大的损失。
现有系统已经在物理安全网络安全系统安全应用安全和管 理安全几个方面有所建设。
拟改造项目的安全建设内容除延续以上各 方面之外,重点在于应用系统安全建设数据备份和接入,涵盖 范围包括已建和新增的服务器网络等硬件及应用软件等,主要包括 应用安全身份鉴别访问控制通信完整性软件容错 权限控制代码安全 数据安全数据完整性数据保密性数据备份和恢复 接入代理售票点通过公网的安全认证及接入。
设备需求分析 考虑到本项目对于市城市交通的重要性,在网络设备服务 器数据存储及其它设备选择和配臵时应保证小时不 间断正常运行,同时数据库系统和应用服务器系统要都能实现负载均 衡及互为备份,保证系统高可靠性。
存储设备容量应该满足存放年 的数据量。
所配臵的各类设备需要和原有系统有很好的兼容性。
软件需求分析 由于本项目是对原系统的改造,软件选择应遵循致性的原则。
操作系统核心系统平台采用稳定且处理多用户并发能力强的 操作系统,其它各类系统采用界面友好易管理的 操作系统。
数据库能支撑大容量数据采集支持复杂业务系统处理的大型 数据库管理软件数据仓库模块能够存储分析计算海量历史数据,为辅助决策提供功能支持。
中间件需要稳定成熟性价比高,遵循规范,通过 认证,同时适合大型业务系统逻辑处理的中间件软件。
应用系统基于平台开发运行。
第四章项目目标和内容 建设目标 在确保现有公路客运信息平台稳定运行,降低风险的同时,把原 平台改造成满足出行者客运站经营者管理机构多方使用的信息平 台。
系统建设总体目标更新并完善市公路客运信息平台,平 台包括三大应用子系统,即公众出行服务系统联网票务结算 系统政府行业监管系统,并同步建设配套的灾备系统。
灾备系统 系统目标 建立基于应用层容灾的同城灾备系统,达到既能保护数据的完整 性,使业务数据损失最少甚至没有业务数据损失,又能保障快速恢复 运行,使业务停顿时间最短甚至不中断业务的目标。
具体量化目标为 恢复时间目标指标小时,数据恢复点目标指标趋 于,即灾难发生后,小时内完成能恢复系统运行,且以前的数据 丢失可以忽略不计。
系统功能围绕系统设计的目标,要实现对生产数据的保护,同时又要保障 业务的连续性。
系统须具备数据复制功能,能够完整地把生产系统的 任何变化复制到灾备端,同时又要建立完善的灾难恢复计划,灾难发 生后进行快速系统恢复。
数据复制 通过城域网连接,实现生产系统向灾备系统的同步和异步复制, 确保系统数据的高可用性。
灾难恢复 通过制订完善的灾难恢复计划,规范灾难恢复流程,使系统在灾 难发生后就能够快速地恢复数据处理系统运行和业务系统运作,满足 业务运营的需要。
基本性能要求是灾备系统接管生产系统工作后, 运行性能不会出现明显下降。
系统架构 灾备方法的具体分析 依据保护能力的不同,灾难恢复的实现也有多个层次。
国际标准 定义的容灾系统有七个层次如图所示,从最简单的 仅在本地进行磁带备份,到将备份的磁带存储在异地,再到建立应用 系统实时切换的异地灾备系统,恢复时间也可以从几天到小时到分 钟秒或数据丢失等
