收费系统管理平台化软件.docx

收费系统管理平台化软件.docx

《收费系统管理平台化软件.docx》由会员分享，可在线阅读，更多相关《收费系统管理平台化软件.docx（7页珍藏版）》请在冰豆网上搜索。

收费系统管理平台化软件

收费系统管理平台化软件

一概述

收费系统管理平台化软件主要面向于高速公路收费的管理，提供了完整的一揽子解决方案，从开放式收费到封闭式收费，到不停车收费，以及大区域的一卡通收费；

二特征与益处

1完整的收费体系解决方案

针对不同的场景（站、分中心和中心）和角色灵活配置，每部分既能自成系统，具有一定的自治性，又能相互配合，形成一个有机整体；

提供通用的规范接口，形成所管理数据的平台化概念，便于二次开发，便于实现数据挖掘、增值服务等，便于系统升级。

2适应能力强

不仅能和本系统车道机平台软件相配合，也能融合其它公司车道机软件，不仅支持最新的收费模式，也能兼容经改造的老式收费系统；

3数据处理准确、高效，杜绝收费漏洞

系统结构清晰、逻辑严密，实现有效的管理。

系统业务数据处理准确及时，提供数据校验和复核功能，便于管理业务的处理“有据可查、有法可依”，对于通讯等异常偶然原因造成的数据不完整提供警报和恢复机制，保障系统正常时能可靠运行，故障时存在恢复的能力和手段；

系统支持电脑票、手撕票，对所有的票据能进行有效管理，包括号码，库存，使用，发出，作废等数量，对于废票处理除限制相应的权限外，还打印出详细的废票清单备案；

系统提供通行卡、公务卡、储值卡、身份卡、电子标签等全面的IC卡管理方案；

从卡发行到卡流通，系统按照卡编号对每一张IC卡实施流通追踪及全方位的业务管理。

4系统安全性高

统一的集中权限管理与身分认证机制，保证系统的安全可靠。

系统自动建立相应的运行档案，记录使用人员的每个关键性操作，便于系统维护人员进行维护；系统的所有原始数据，任何系统使用人员都严禁进行修改或删除；并且系统提供可靠的数据备份与恢复机制。

当系统任一部分故障时，保证系统在降级运行的情况下，不会影响正常的收费工作。

故障解决后，系统能恢复正常运行，并保证其间各种数据的完整性和一致性。

在系统网络及通讯系统出现故障时，在权限允许的情况下，系统可以脱机处理必要的收费业务，保证收费工作的正常进行。

必要时可以使用备用卡处理收费业务。

5友好的用户界面

采用类似微软文件管理器的风格方式，操作无需培训；

所有应用软件均使用中文界面，为使用人员提供详细的帮助信息；提供在线帮助，复杂的业务采用向导式人机交互界面，对用户的重要操作系统提供详细的提示与警告信息。

6报表具有定制修改的能力

提供报表定制平台，业主方管理人员可根据需要灵活定制报表样式和数据内容。

7部署简单快捷

系统采用平台化思想模块化结构设计，结构明晰，接口明确，改造简单，并且易于现场实施，软件部署快捷，免去研发人员现场开发的成本，提高效率；

三具体实现描述

1结构描述

典型收费系统分为中心（分中心）、站、车道三级结构，分中心的概念一方面对于省中心和淸分中心来说，各地原来独立核算路政公司可界定为分中心，其概念为具有局域管理几个站的功能，又有向上级机构提交交易流水数据的功能需求。

系统数据流动如下图所示：

下图表示了典型收费系统的硬件配置图：

2数据库平台化实现

1现状

针对收费系统对应服务器上一个应用库，库内存储代码表和数据表，针对业务，应用代码表生成并处理业务数据，实现相应管理功能。

2问题

1总述

首要的问题在于数据的结构性问题，数据库方式基于基本流水处理的方式，如果基本流水无此信息，就如大厦缺了基石，是非常危险的，此问题具有普遍性；

数据库处理提供信息问题是目前一个大问题

目前系统总体表现为实时性差，检索速度慢，对特定统计报表需要增加数据统计表，涉及数据结构的改变等等；

2历史及发展

下面按系统发展针对不同典型情况加以阐述。

1开放式收费系统

●基本表方式

采用NT+SQLserver的服务器方式，基于流水表WASTEBOOK查询方式，功能实现简单，但数据量大时统计有问题，等待时间过长；

●触发器方式

后改进为触发器方式，来一条流水实时统计信息，但定制报表麻烦，增加一个报表需要添加一个表结构，还要改动触发器程序，危险性比较大，触发器存在错误回滚机制，处理起来复杂；

数据传输方式基于SQL的复制方式，过于复杂，不易于维护；

2封闭高速公路收费系统

目前有基于两种操作系统：

标准版（NT+SQLserver）小型机版（AS400）。

处理方式有所改进，采用基于JOB的方式，流水数据通过触发器导入到临时表，JOB定时对于业务进行处理，统计信息生成进入统计报表，增加了一定的安全性和易操作性，但仍旧对定制报表缺乏一定的灵活性。

数据传输增加了编程实现方式，灵活性加大，安全性和通用性降低。

以上系统对于站和中心采用统一处理方式，没有考虑各自角色的特性。

3可能方案

1业务需求分析

首先分场景有针对性的对有特性的东西加以描述

✧站级数据库处理业务及需求实现分析

1站服务器需要实时接收车道数据，尽可能实时统计或查询时比较快获得统计信息

2站内业务实时性要求比较高，领票报帐，基本以当天当班次处理实时性要求最高，预处理；

3流水库多方参与工作，应对此加以隔离，不同的业务不同的操作对象减少数据库操作锁定和等待造成的性能降低

4库结构明晰，修改其中处理流程易于实施

5平台化结构，一定程度针对平台化流水的定制

✧中心数据库处理业务及需求实现分析

1中心目的在于宏观掌握信息和控制

2信息实时性要求相对较弱

3整体统计分析平台化需求较高

2数据库平台描述

1数据库结构承袭原体制，注意在数据表定义方面考虑

●容纳进近期开发经验教训

●参考相应规范

●参考各地地方特色

●关键地方有所预留

●不同数据平台数据类型兼容性

2处理机制考虑进行改变

●流水表处理

站级：

添加短期流水表（ShortTimeWastebook）和长期流水表（LongPeriodWastebook），短期流水表针对三个业务，车道机上传数据、本身涉及要求相应及时的票务业务处理查询（只读，无统计功能，直接针对短期流水表STW查询），提供通讯原数据（只读方式）；长期流水表（LPW）定期（例如每天）接收临时表打包数据，进行平台化数据统计；

中心：

机制类似，但考虑尽量减少或省略STW作用，避免数据流转

●提供数据库调度机

结构的统一是平台化系统的共性，但各地处理业务存在特性，优先级别不同，处理流程的差异，业务量的处理瓶颈，使得数据库业务处理的性能需要调节（ProformanceTunning）,使得业务处理的资源耗费程度能够在服务器处理时间内保持一致，不要起伏过大，具体来讲，可以调节业务处理的时间，晚间车道机数据处理稀少时进行业务数据的统计，分析。

站级和中心尽量做成一致，可灵活配置

●建立报表数据平台

按照报表分类需求建立二次流水汇总平台（MiddleWastebookPlatform），报表查询针对此平台进行检索，实现检索时间耗费和数据汇总工作量的一种折衷方案。

建立一套全面的标准版报表结构，满足大部分需求，在这种结构上进行取舍，实现一种有限化平台的概念方式。