高速公路车道收费系统

第一篇：高速公路车道收费系统

高速公路联网系统车道收费软件的设计与实现分析

摘 要 高速公路收费是确保高速公路营运正常的一项措施，在信息技术与网络不断发展的时代下，高速公路车道收费网络化正逐步完善。在高速公路收费系统中，主要有数据清分中心、收费中心、收费站以及车道收费这四个系统。其中车道收费是整个系统中的第一处理点以及数据源。本文基于这一背景，简单阐述了车道收费系统在联网状态下的功能，分析了收费软件设计需注意的几点问题，并在此基础上研究了软件实现要点。旨在优化收费软件设计，提升高速公路收费管理效率。

【关键词】高速公路 收费系统 软件设计

车道收费软件的使用目的在于处理好车辆出入作业，联网是对信息的一种交互，确保收费合理性。车道可分为出口与入口两种，入口系统主要功能为读写IC卡、开启与关闭自动栏杆、转换交通信号灯、为道路监控提供实时信息、上传或下载车辆黑名单、入口车辆相关数据的上传等;而出口系统除上述功能外，还需计算通行费用并语音播报、更新费率表、特殊车辆记录与抓拍、出口数据上传等。在联网状态下，我国高速公路管理将更为规范化，通过车道收费软件的设计与使用保障整个交通系统的正常运作。本文以车道收费系统的设计与实现为主线，作出如下分析。

1 车道收费软件设计要点分析

1.1 突发状况应急处理设计

在现阶段高速公路收费环境中，不乏一些车辆为了节省过路费出现闯关现象，这种情况可能造成收费的混乱。另外，车辆种类的不同在收费标准方面也不尽相同，例如在遇到公务车、军警车、领导车队(紧急车)、欠款车等车辆时，软件需对这类车辆展开及时划分，确定收费标准。且车辆还分为有卡与无卡两种，与收费标准差异性相互组合时无形中极大增加了收费复杂性。

1.2 用户版本移植的复杂性

现阶段收费系统相当于仅面向了业主这单一方面，在联网状态下，业主使用的车道收费模式与软件设计密切相关。传统收费系统属于非联网状态，若在此基础上加以改进首先要解决业主匹配问题。在联网情况下，可将收费看做两个以上高速公路业主(且行驶路段为相连状态)的联合收费，无论是在外设上还是版本上都需有所改变。换言之，要求收费系统不仅能够起到既定作业的处理功能，还可灵活应对现实状况，做好适应性与灵活性。

2 收费软件的功能实现分析

2.1 软件实现方式

车辆在进入到收费系统之后，由于自身重量以及车身行驶状态会将线圈触发，车辆随即进入到天线检测范围。在信号被触发之后，车道程序会将天线开启，接收CPU与OBU传来的信息同时实时处理。通过信息交互，车辆CPU卡信息将实现被读写。

首先收费系统会验证CPU卡与车辆是否匹配，并查验OBU有效性。之后访问服务器数据库，了解车道内车辆是否处于黑名单或灰名单之中，若处于则根据欠费或漏缴情况作出合理判断并打印单据(此操作需联网实现)，在所有检验均合格后才能够开始收费操作。收费操作为交易核心，车辆在高速公路入口处收费为零元，出口处收费根据驶入与驶出情况按标准收费。最后，车辆在交易成功状态下，费额显示器上会将扣费信息显示出来并放行。

2.2 数据上传

数据上传是联网状态下软件的必要技能，也是联网时车道收费核心功能。由于高速公路在软件运行条件上相对恶劣，受到内存等客观条件影响较大，因此在设计上可分为前台与后台两方面展开传送，通过UDP通信协议完成。但这是一种可靠性不强的传输协议，因此需采用某种方式保障数据可靠性，例如SendFlag标志。具体上传流程如下：

当高速公路入口处发卡或出口收费信息出现时，信息会被存至本地数据库，将标志定义为假并让前台软件向后台发送传送消息。后台接收后则使用协议将数据上传，将标志为真的记录删除。接着，当收费站服务器收到信息后，需自动检索数据库再操作数据，成功后发送成功标志至车道软件。软件收到成功信息后，可将该记录标志设置为真。最后，车道收费后台软件会将数据发送至收费站服务器。此时若网络出现故障，需重新检查网络是否处于联通状态。

2.3 时间统一性的实现

在收费系统中，由于需使用到联网功能，因此时间的统一性尤为重要。在软件实际运用中，时间标准应以站级服务器为主。服务器中会安装SQL Server，能够自主实现与Windows的对时。

2.4 数据打印高效性

传统采用Windows驱动的数据打印花费时间较长，通常为8秒左右，若通过车辆过多可能造成堵塞情况。在联网系统中，需正视打印时效这一问题，直接将打印控制码发送至打印机，票据会在2秒左右时间被打出，极大提升了收费速度，确保高速公路的通畅性。

2.5 特殊情况的处理

对于车辆在驶入收费站后出现的特殊情况，软件需加以区分并将其上传至服务器，包括车辆车牌号、车主信息以及具体情况类别等方面。尤其是在出口车道，通常出现的特殊情况有储值卡余额不足、入口信息错误或丢失、CPU卡丢失、报警器提示等。入口方面，主要有缺少CPU卡以及电子标签两种。对于特殊情况，需值班员正确引导车辆至MTC车道处理，并将信息上传。

3 结束语

高速公路联网车道收费系统的设计是对高速公路运营的支撑，也是减少道路堵塞，提升车流速度的有效方式。在联网状态下，信息传播速度极大提升，系统可实现大部分数据处理，有效减轻了值班员工作量。在系统的设计与实现方面，现阶段需解决的主要问题在于联网状态下身份认证的统一性以及软件处理功能范围的扩大化。总之，软件设计人员还需加大投入力度，在不断实践基础上将收费软件设计得更为完善，通过软件真正实现联网管理，为高速公路的运营提供强有力支撑。

参考文献

[1]郑颖.高速公路车道收费软件的设计与实现[D].西安电子科技大学，2010(01).

[2]张星.ETC车道收费软件的设计与实现[J].中国交通信息化，2011(01).

[3]周杨.高速公路收费系统MTC车道软件设计与实现[D].西安电子科技大学，2012(02).

[4]余绪金.高速公路不停车收费联网车道软件的设计与实现[J].科技广场，2012(04).

作者单位

江苏智运科技发展有限公司 江苏省南京市 210049

第二篇：**收费站车道堵车应急预案演练活动总结

为积极应对在收费工作中遇到的各类堵车现象，组织起高效有序的排堵疏导工作，确保车道畅通，使过站车辆快速通过，切实维护好公路“窗口”的良好形象。为此，结合本站工作实际，2008年7月在收费现场开展了车道堵车置预案演习。在各参演人员的共同努力下，演习圆满完成，达到了预期效果。现将演习具体情况汇报如下：

演习事件预定：一辆载重货车在经过318国道**收费站交费时对地磅称重数字产生异议，收费人员耐心解释并出示相关文件后仍拒不缴费，车辆阻塞出口车道。监控室了解情况后立即通知相关人员，征稽股股长立即组织人员开启备用车道，指挥疏导车道。收费站站长也第一时间到达收费现场，拿出地磅质量检测标准，对当事人做劝导解释工作劝其离开。在工作人员的耐心劝说下，驾驶员终于缴纳了通行费，车辆驶出车道。

演习目的：增强收费站应对突发事件的能力，提高应对突发事件启动应急预案的反应速度，使全站人员应对突发事件的应变能力得到进一步提高，收费站的保畅能力得到进一步提升，确保收费工作的安全高效进行。

随着应急演练领导小组下达“演习开始”的命令后，上午9时许，收费车道上车辆一辆接一辆的通行，突然，一辆载重车因收费标准与收费员产生矛盾，并强行将车堵在车道。收费员立即上报监控室。监控室立即通知相关人员，并调整监控探头做好特殊录像;征稽股股长立即指挥收费人员临时开启同一方向的超宽车道，并增派人员进行车道疏导，保证其他车辆快捷通行，收费站站长对受堵的司乘人员做好宣传解释工作。现场稽查人员站在堵车最后车辆后侧进行疏导，杜绝车辆摩擦事件发生，对不听劝阻的车辆，由收费站现场值勤民警值勤暂押司乘人员的有效证件，让车辆先行右边停车，让出受堵车道，另行解决。整个演练过程维时5分钟，活动开展顺利。演习严格按照方案进行，参演人员分工明确，步骤控制严谨，演习仿真程度高。

通过此次实践演练，不仅检验了收费站在面对突发事情时保证车道畅通的能力和提供优质服务的能力，而且增强了收费队伍的协同反应水平和应急处置能力，从而使单位在应对各类突发事件时，能够做到有条不紊、从容应对，确保通行费征收各项工作安全有序运行。

第三篇：高速公路收费系统软件

发布时间：2007-09-07 点击次数：1940 提供：深圳市迅维技术有限公司 作者：sunnycomm

SUNNY-CM高速公路收费系统采用入、出口人工判别车型和车种、人工收费、检测器校核、自动栏杆控制、闭路电视监视、计算机管理的自动收费模式，收费业务主要以收取现金为主，有较为完善、严密的非接触IC卡和收据管理系统。

收费系统应用软件根据功能及分布主要分为以下几个既相互独立又彼此联系的软件模块，由它们构成了IC卡收费管理信息系统：

(1) 车道级软件，包括入口车道发卡软件和出口车道收费软件。

(2) 站级软件，包括站级财务软件、站级监控软件和站级网络管理软件。

(3) 中心级软件，包括中心财务软件、中心监控软件、中心网络管理软件及中心IC卡管理软件。

(4) 通信软件，包括车道通信软件、站级通信软件和中心通信软件。

车道级软件

车道软件的主要功能是完成入口发卡或出口收费业务，收费车道设备完成一次正常的车辆处理业务后，由此而产生的车型、车种、入口时间、入口站名、通行卡卡号、车道号、收费员工号等信息将存贮在车道控制器内，并实时上传给收费站计算机和收费中心计算机。如网络故障不能上传数据，车道控制器可连续存贮40天的数据，等到网络连通后，系统自动将数据上传收费站计算机和收费中心计算机。

收费员在下班时如网络有故障，可刷自己的身份卡下班，将数据写入自己的身份卡，下班后再到财务计算机上刷身份卡将数据读入财务计算机，以便财务统计当班表。

收费站软件

收费站计算机系统的硬件设备包括网络服务器、财务管理工作站、监控工作站、喷墨打印机、IC卡读写器等。软件设备包括站级财务软件和站级监控软件。站级软件的操作界面为WINDOWS 风格界面，操作方便简捷，操作员只需轻点鼠标和按几个数字键即可完成所有的操作。 站级财务软件

主要功能是提供与站级管理尤其是与财务管理有关的各种报表，主要有入、出口当班表，各种日报表、月报表、年报表等，其次是IC卡的管理，有卡的调动、和卡的发放及回收。

收费员下班后到财务结算时，系统将根据车道上传的数据统计入、出口当班表，再由财务人员输入实发、实收数据，以检验收费员的操作是否有失误。当班表一经打印输出即转到历史当班表，可在历史当班表中查询已输出的当班表。系统可根据当班表统计各种日报表、月报表及年报表。

收费站监控软件

主要作用是实现监视和查询的功能。根据站级服务器的数据，统计本站的交通量数据并显示出来，并显示站和车道的通讯状况。并能够实时统计和显示收费业务以及实时显示车道使用的票号。

收费站监视计算机的软件主要由以下模块构成：

(1) 交通量统计模块：监视工作站定期从服务器提取车道上传的收费信息和车辆通过信息进行加工处理，按车型、车种及车道统计出交通量信息，并显示出来。

(2) 通讯状态监视模块：监视工作站定期和车道控制器进行实时通讯，以便确定通讯线路是否正常，并显示出来。

(3) 收费状态监视模块：监视工作站定期从服务器提取车道控制机上传的收费信息和车辆通过信息进行加工处理，统计出当前收费信息(车道号、收费员姓名、车型、车种等)，并显示出来。

(4) 票据状态监视模块：监视工作站通过通讯模块，实时获取车道票据的使用情况，将票号显示出来。并且在车道票据只剩下20、

10、

5、

4、

3、

2、1张时在监视计算机上产生报警信息。

站级网络管理软件

主要功能是管理各种站级参数表。包括查看软盘中的参数表、查看服务器中的参数表、清除服务器中的参数表、将软盘中参数复制到服务器。 在网络出现故障时，可用软盘将参数从中心服务器上拷出，再将软盘中的参数复制到站级服务器。

收费中心软件

收费中心计算机系统安装在收费中心的管理大楼内，其主要硬件设备有网络服务器、网络管理工作站、监视工作站、财务工作站、POS工作站(预付卡管理)、IC卡管理工作站、UPS管理计算机、打印机、IC卡读写器等。其主要功能如下： (1) 收集和处理各收费站计算机系统上传的数据; (2) 统计、查询各类报表并打印输出;

(3) 建立全线统一时钟，统一车型分类参数和收费参数表、收费系统人员码表等，并通过收费站计算机系统将有关运行参数下传到收费车道;

(4) IC卡编码管理(包括通行卡、公务卡、身份卡)和通行卡的调度; (5) 数据库的管理和数据备份; (6) 全线预付帐户及预付卡的管理;

(7) 对车道工作情况实时监视，处理入、出口车道发生的特殊事件(如车型或车种不符、废票请求等)。

(8) 收费系统的网络管理等。

收费中心软件的操作界面为WINDOWS风格界面，操作员同样只需点点鼠标和按数字键即可完成所有的操作。

收费中心财务管理软件

主要功能是提供与中心级管理尤其是与财务管理有关的各种报表，主要是各种站级报表的汇总，如日报表、月报表、年报表等，其次是IC卡的管理及全线站级财务软件运行参数的管理。

收费中心监视软件

功能主要是监视和查询。系统根据中心服务器的数据，统计出整个收费系统的交通量数据并显示出来;显示全线各站和车道的通讯状况及车道的运行情况;对车道发生的特殊事件进行处理，并显示报警信息;实时查询IC卡所在的位置。 收费中心监视软件主要构成模块及其功能如下：

(1) 交通量监视模块：监视工作站定期从服务器提取各站上传的收费信息和车辆通过信息进行加工处理，统计出中心交通量信息，并显示出来。

(2) 通讯状态监视模块：监视工作站定期和各站服务器进行实时通讯，以便确定通讯线路是否正常，并显示出来。

(3) 收费业务监视模块：监视工作站定期从服务器提取各站上传的收费信息和车辆通过信息进行加工处理，统计出当前收费信息，并显示出来。收费员可通过系统实时的查询全线各站各车道的收费业务情况。

(4) IC卡查询模块：当需要查询IC卡信息时，只需输入要查询的IC卡的卡号，系统将检查所有已登录的IC卡，并显示出该卡的信息。

(5) 参数设置模块：通过参数设置，可以显示指定车道的报警。

(6) 实时报警模块：通过实时通信模块获取车道报警信息，将其实时显示出来，并处理车

道发生的特殊事件。

收费中心网络管理软件

主要功能包括对整个收费系统的参数表进行管理以及实施系统所需要的辅助功能。网络管理程序负责维护收费系统所需要的各种系统参数表(如通行费率表、旅程时间表、授权员工表等)，以及对系统参数表数据的增加、修改和删除。网络管理系统所维护的系统参数表被保存在位于收费中心的服务器上的数据库中，由收费站服务器接收，在各收费站和车道使用。系统的辅助功能主要包括运行参数的拷出和收费数据的备份、恢复及整理。 收费中心

收费中心 IC卡管理软件

主要功能是对所有IC卡编码、存档、登记，然后发放非接触IC卡通行卡、IC身份卡、IC公务卡和IC月票卡以及对非接触IC卡黑名单进行管理。 通信程序

通信程序分为中心通信程序、站级通信程序和车道通信程序，通信程序在本套系统中没有界面，系统自动运行，主要负责中心、站与车道之间的数据通信，如车道收费数据的上传和中心参数表的下发等。

第四篇：高速公路收费系统设计与实现

高速公路收费系统设计与实现 目 录 目 录

第 1 章 绪论

………………………………………………………………………1 1.1 高速公路收费系统概述 …………………………………………………………1 1.2 数据传输系统开发的背景……………………………………………………… 1 1.3 数据传输系统设计的目标……………………………………………………… 1 第 2 章 系统的组成及主要功能……………………………………………………3 2.1闭路监视系统………………………………………………………………………3 2.2辅助系统……………………………………………………………………………3 2.3收费系统……………………………………………………………………………3 2.3.1 车道收费子系统………………………………………………………………3 2.3.2 服务器…………………………………………………………………………4 2.3.3 通信机…………………………………………………………………………5 2.3.4收费管理系统………………………………………………………………… 5 第3章 数据库应用……………………………………………………………………6 3.1 数据库系统的组成和全局结构………………………………………………… 6 3.1.1 数据库系统的组成………………………………………………………… 6 3.1.2 数据库系统的全局结构…………………………………………………… 7 3.1.3 DBMS的工作模式和用户存取数据的过程………………………………… 7 3.2 数据库系统体系结构………………………………………………………… 8 3.2.1 集中式DBS……………………………………………………………………8 3.2.2 客户机-服务器结构DBS…………………………………………………… 9 3.3 开发数据库应用系统………………………………………………………… 10 3.3.1 数据库应用系统的简单结构………………………………………………10 3.3.2 数据库引擎…………………………………………………………………10 3.3.3 开发数据库应用系统的技术背景和任务…………………………………11 3.3.4 开发数据库应用系统需要考虑的问题……………………………………12 第 4 章 系统设计与实现 ……………………………………………………… 14 4.1 收费计算机和通信机…………………………………………………………14 4.1.1 动态组件……………………………………………………………………14 4.1.2 TCP报文的构成………………………………………………………………15 4.1.3 数据包的抽象………………………………………………………………16 4.2 牙管理工作站…………………………………………………………………17 4.2.1 用户登录模块 ………………………………………………………………25 4.2.2 主界面模块……………………………………………………………………26 4.2.3 用户管理模块…………………………………………………………………27 4.2.4 车辆收费模块…………………………………………………………………27 第 5 章 维护与管理…………………………………………………………………28 5.1事件的初步分析…………………………………………………………………28 5.2.1加强收费服务器的日常维护…………………………………………………28 5.2.2定期做好服务器的清洁工作…………………………………………………28 5.2.3做好紧急修复磁盘和系统启动盘……………………………………………29 5.2.4定期检测磁盘，察看系统的日志文件………………………………………29 5.2.5做好数据库的备份工作………………………………………………………29 5.2.6做好病毒的防治工作…………………………………………………………29 5.3 数据管理模式的分析和比较…………………………………………………30 5.3.1现有某高速公路的收费管理模式……………………………………………30 5.3.2现有数据管理模式的优缺点…………………………………………………31 5.3.3数据集中管理模式的定义和特点……………………………………………31 5.4集中管理模式的可行性分析……………………………………………………32 5.4.1网络可靠性分析………………………………………………………………32 5.4.2服务器系统软硬件平台………………………………………………………32 5.4.3 冗余独立磁盘阵列RARD等安全措施 ………………………………………33 结束语 ………………………………………………………………………………34 主要参考文献…………………………………………………………………………35 致 谢…………………………………………………………………………………36

第 1 章 绪论

1.1 高速公路收费系统概述

高速公路收费系统实现了半自动和 ETC 两种收费方式，可选用 IC 卡、磁票、二维条卡作为通行券，支持现金、预付卡、储值卡等支付方式;各级可以实现监控下级的操作异常事件;实时监测出入口车道的设备状态;各级系统可以自动统计交通量、通告量曲线图;实现了对路费、通行券、票据、设备等的严格管理，杜绝舞弊行为;提供独特的专家分析系统等。系统组成： ·系统采用先进的 C/S 三层体系 ·通过广域网实现各级间互联 软件特点： ·符合我国现有国情 ·适用范围广 ·开放的收费系统 ·可定义的业务流程 ·友好的人机界面 ·安全可靠的性能 高速公路收费系统 系统概述：高速公路收费系统实现了半自动和 ETC 两种收费方式，可选用 IC 卡、磁票、二维条卡作为通行券，支持现金、预付卡、储值卡等支付方式;各级可以实现监控下级的操作异常事件;实时监测出入口车道的设备状态;各级系统可以自动统计交通量、通告量曲线图;实现了对路费、通行券、票据、设备等的严格管理，杜绝舞弊行为;提供独特的专家分析系统等。 1.2 数据传输系统开发的背景 随着我国经济的快速发展，社会车辆日益增多，因此我国普遍实行贷款修路，收费还贷制度。原有的手工收费系统存在着许多弊端，而收费站的收费情况直接影响到还贷的能力和业主的经济利益。以计算机网络为基础的公路收费与监控系统，不仅最大限度地防止各种营私舞弊现象，有效制止收费过程中的漏征、作弊行为，并且大幅度提高普通公路收费过程和财务管理的自动化程度，提高工作效率和服务质量，为管理决策提供有力支持。但是目前运行的高等级公路监控收费系统的开放性、可靠性不高，对各种可能出现的问题考虑不周全，在实用暴露出很多问题或不能适应目前形势的发展，需要进一步完善和改进。为此，我在参考已有系统的基础上，设计研制了一套较为全面的收费监控系统。 1.3 数据传输系统设计的目标

通常在等级公路上的收费方式为人工判别车型，人工收费，计算机打票( 也可以按要求使用IC卡、非接触卡等)，并对收费数据进行统计管理;CCTV系统辅助监督的收费方式。

考虑到收费站的实际情况(人员计算机水平低，灰尘大等特点)，我们在软件的设计上注重软件的公正、精确、简便、可靠性;并能做到应征不漏，收费准确，可有效的防止员工的作弊行为，作到作弊可查，查必有据。在软件设计中注重了以下几个方面：

1)可靠性：由于收费站存在的大量灰尘容易导致设备损坏或接触不良，因此本系统充分考虑到磁盘介质损坏可能对数据产生的影响和系统崩溃对数据产生的影响，建立了两级数据库---车道计算机数据库和服务器数据库。车道控制计算机首先将收费数据、设备状态、事故日志等数据信息存入本地硬盘上的数据库，再将其上传到服务器。当服务器或网络出现故障时，车道计算机可以独立工作，将收费数据等信息保存在本地数据库;待故障消除后，车道控制计算机调取故障时以及故障之后的数据，上传服务器，从而保证收费数据的完整性。

2)开放性：系统具备良好的开放性和兼容性，整个系统易于升级、易于维护。本系统车道数量可以灵活配置，适用于任意数量车道的收费站系统。便于联网，组建省地级监控中心。

3)高效性：保证车辆通过收费车道的高效率和业务快速处理的能力。对于车道控制计算机众多外围设备自动控制，减轻了收费人员负担，提高了工作效率。

基于以上思想，我们采用C++ Builder作为开发工具，SQL Server 7.0作为服务器数据库，车道控制计算机数据库采用C++ Builder自带的Paradox。

第 2 章 系统的组成及主要功能

收费监控系统主要由收费计算机系统、CCTV监视系统、内部对讲系统和辅助系统等子系统组成。下面分别描述各个子系统的主要功能。

2.1 闭路监视系统

闭路监视系统是相对独立的系统，只是和收费系统存在某些关联(如收费数据叠加、抓拍、硬盘录象等)。整个闭路监视系统可以划分收费亭监视、车道监视、广场监视等几个部分。

2.2 辅助系统

辅助系统是指确保收费系统正常运行的配套系统，包括内部对讲、电力供给、设备保护等多个方面。

2.3 收费系统

收费系统基本上包括车道收费控制系统、收费站管理系统两大部分，其拓扑结构如图1所示。

收费站计算机与车道计算机组成局域网，采用客户机/服务器模式。根据车道到收费站的距离远近，车道和收费站之间采用光纤或双绞线连接。

2.3.1 车道收费子系统

车道收费子系统是整个收费的前端，如图2所示。主要包括车道计算机、交通控制等设备，通过车道收费控制软件，实现这些设备有机的整合。具有安全管理、车型判断、收费管理、设备控制(车道灯、挡车器、测流线圈、金额显示、语音报价、字符叠加)、设备状态检测、数据传输控制、数据存储等功能。能够快速、准确地完成各种收费业务，杜绝收费过程的舞弊行为，同时保证车辆的通行高效率。

车道收费系统按照收费工作逻辑流程，集中控制所有的车道设备。车辆到来时，车道控制机接受收费员的操作，显示收费金额，并进行语音报价，同时通过字符叠加卡将金额叠加到监视图像上供监控人员参考;收费完成后，挡车器升起，车辆通行;车辆通过测流线圈后，栏杆自动放下。对免费车、月票车及特殊情况自动抓拍图像，并将图像数据上传到站服务器。

车道收费系统采用基于Socket的数据传输技术，能够动态监测网络通信的工作状态，使车道收费系统的运行具有很强的独立性，实现网络工作环境和单机工作环境的动态切换。切换过程对操作人员是隐含的，不会影响车道收费系统的正常运行，保证车道的最大工作效率。当管理站计算机系统出现故障或车道和收费站之间通信线路出现故障时，车道收费系统可以立即检测到故障的出现，停止数据上传，将收费数据储存在车道计算机;当故障排除后，车道收费系统可以自动恢复数据上传。

2.3.2 服务器

服务器主要进行数据的存储和收费数据处理：在数据库中编制触发器和预定义存储过程，当收费数据写入数据库或者对数据进行修改、删除时，数据库的触发器会自动更新有关统计数据(如日收费统计、班收费统计、车型分类收费统计、收费员收费统计等)，从而保证收费数据的完整性和一致性。

2.3.3 通信机

我们借鉴了软件工程中Agent的概念，在服务器和车道控制计算机之间建立一个“代理”层，该软件可以运行在任意一台的计算机上，即通信机。根据收费站的规模，也可以运行在数据库服务器或管理计算机中。

车道计算机、通信机之间通过传输层协议连接。传输层有两种通信协议：TCP/IP和UDP。

采用TCP通信时，通信双方需建立连接，通信过程中有应答和重发机制来保证所有通信数据都正确到达。采用UDP通信时，不需要建立连接，也没有应答帧，而且可以广播发送，实时性较高，但缺点是发送方不能确认通信数据是否正确到达目的地。因此,我们必须根据具体要传输的信息来采用相应的传输方式。

在本系统中，实时性不是主要因素，所以我们采用TCP/IP协议来保证数据的可靠到达。

通信机的主要功能是数据库的操作、数据的传输控制及应答，即：

a、通信机通过ADO(或ODBC)和服务器数据库相连接，进行收费数据的数据库写入工作。

b、接收车道计算机收费人员登录信息包和收费流水数据，并将其写入收费数据库中，并返回相应应答信息。

c、通信线路故障后，计算机自动记录，并向管理人员报警提示，人工排除故障，系统恢复后，自动从收费车道计算机调取数据，保证数据的完整性。这样基于TCP/IP协议建立了多层分布式数据库的软连接。

d、代理可以迁移到系统任意一台计算机中, 自动将新IP地址发布到各个车道的计算机。

当收费车道与收费站之间出现长时间的通信故障时，可以通过车道收费软件提供的数据导出功能将车道数据库中的收费数据写入软件盘后，在管理站将数据导入数据库中。

2.3.4收费管理系统

收费站管理系统具有收费监视、收费工班管理、用户管理、收费数据管理、系统维护、站点管理、报表打印等功能。

第3章

数据库应用

数据库系统的组成、全局结构和数据存取结构。 数据库系统体系结构。简要讨论集中式和客户机-服务器(C/S)结构的数据库系统体系结构，本书专门讨论这两种结构的数据库应用系统实现实例。 数据库应用系统的简单结构、数据库引擎、开发数据库应用系统所需的技术背景和开发任务以及开发数据库应用系统需要考虑的问题。 3.1 数据库系统的组成和全局结构

数据库系统(database system，DBS)是采用了数据库技术的计算机系统。DBS是以信息处理为核心的计算机系统，信息的存取是系统工作的枢纽，它是一个可运行的，按照数据库技术存储、维护和向应用系统提供数据支持的系统，是由数据库、硬件、软件和数据库用户组成的有机集合体。

3.1.1 数据库系统的组成

任何数据库系统都由数据库(DB)、硬件、软件和数据库用户组成。 数据库是与企业具体的业务应用有关的全部数据的集合。从数据库的用途来看，数据库可分为以下两类：

物理数据库 物理数据库是业务应用数据的集合，是业务应用数据库的主体。

描述数据库 描述数据库又可称为数据字典或元数据库，用来描述和存储各业务应用数据库的数据结构及其定义。

硬件包括中央处理器、内存、外存、输入输出(I/O)设备等硬件设备。数据库系统特别关注内存、外存、I/O存取速度、可支持的终端数、性能稳定性、网络的支持能力、存储设备的扩充能力以及数据存取通道的能力等。不同的数据库系统对硬件的要求不同，应根据具体应用选择适当的硬件设备。

软件包括数据库管理系统(DBMS)、操作系统(OS)、数据库引擎和应用开发支撑环境等程序。DBMS是DBS的核心，需要在OS的支持下才能工作。数据库引擎是数据库应用程序和数据库交互的中间驱动程序。应用程序是数据库终端用户用来实现业务的操作界面，是提高生产效率必不可少的程序。应用开发支撑环境是数据库应用程序开发者能够以低成本、高效率开发出数据库应用程序的高效、多功能、集成的交互式程序设计系统。目前，典型的数据库应用开发环境有Delphi、C++ Builder、PowerBuilder、Visual Basic、Visual C++、JBuilder、C#Builder以及.NET开发环境等。

数据库用户就是与DBS交互的用户，按照与系统交互方式的不同，可分为如下4类： 数据库管理员(DBA): 负责定义和修改数据库结构，负责DBS的正常运行，承担创建、监控和维护数据库的责任。

专业用户 : 数据库设计过程中使用专用的数据库查询语言操作数据的数据库设计专业人士，例如系统分析员。

应用程序员 : 使用应用开发环境和数据操作语言开发应用程序的程序员。

终端用户 :使用应用程序完成具体业务应用工作的人员。通常又将这类用户称为“软件最终用户”。 3.1.2 数据库系统的全局结构

从数据库系统的组成来考虑各组成模块之间的关系，数据库系统全局结构如图?3-1

3.1.3 DBMS的工作模式和用户存取数据的过程

DBMS是DBS中对数据进行管理的软件系统，是DBS的核心组成部分。在DBS中对数据库的一切操作(数据定义、查询、更新和各种控制)都是通过DBMS进行的。DBMS的工作模式如图3-2所示。

图3-3是用户存取数据库的示意图。用户对数据库进行操作是由DBMS把操作请求从应用程序带到外模式、模式、内模式，进而通过OS操作磁盘中的数据。同时，DBMS为应用程序的请求在内存中开辟一个数据库的系统缓冲区，用于数据传输和格式转换。

3.2 数据库系统体系结构

根据计算机的系统结构，DBS可分为集中式、客户机-服务器式、并行式和分布式4种。本章重点讨论集中式和客户机-服务器式数据库应用系统的开发技术。 3.2.1 集中式DBS 集中式DBS运行在单个计算机系统中，与其他计算机系统没有联系。通常也将集中式DBS称为单机DBS。集中式DBS中的数据库、DBMS和应用程序等组成部分都运行在一个计算机系统中，不同机器之间不能共享数据。

计算机系统有单用户系统和多用户系统两种，因此，可将集中式DBS分为单用户和主从式两种类型。微型计算机和工作站都属于单用户系统，单用户集中式DBS的结构如图3-4所示。通常说的桌面DBS是单用户DBS的典型应用模式。单用户DBS由一个用户独占使用，无数据共享能力。

图3-4 单用户集中式DBS

主从式结构是指一个主机带多个终端的多用户结构。在这种结构的DBS中，应用程序、DBMS、数据库等都集中存放在主机上，所有任务都由主机来完成，各个用户通过主机的终端并发地存取数据库，共享数据资源。主从集中式DBS的结构如图1-5所示。主从式结构的优点是简单，数据易于管理和维护。缺点是能够支持的终端数目有限，由于所有任务都由主机完成，主机的性能是DBS的瓶颈。

应用较为广泛的集中式数据库管理系统有Paradox、dBASE、Access、Visual FoxPro等。集中式DBS的应用目前主要是在小型数据管理和信息处理业务中。本书将讨论基于Paradox的数据库应用系统项目的开发实例。 3.2.2 客户机-服务器结构DBS 客户机-服务器结构DBS通常简写为C/S结构DBS。C/S结构DBS是随着计算机网络技术的发展和应用产生的。C/S结构的关键在于功能的分布，DBS的一些功能在客户端(前端)执行，另一些功能在服务器端(后端)执行。C/S结构DBS的体系结构如 图3-6所示。 在C/S结构DBS中，服务器专门用来执行DBMS功能、管理数据库以及完成分配在后端的功能。应用程序和应用开发工具等则安装在客户机上，支持用户的应用。服务器和客户机之间通过网络连接，并通过数据库引擎接口实现相互之间的通信。 在C/S结构中，客户端的用户请求被传送到数据库服务器，数据库服务器进行处理后只将结果返回给用户，从而减少了网络上的数据传输量，提高了系统性能、吞吐量和负载能力。同时，C/S结构的DBS具有更多的开放性、可扩展性和可移植性，能够跨平台运行。

通常将C/S结构的DBS称为两层结构的C/S系统。如果在客户端和数据库服务器之间增加应用服务器(或其他中间服务程序)，则两层C/S结构演化成多层的C/S结构，例如B/S结构的DBS就是典型的三层C/S结构。

C/S结构DBS是目前应用比较广泛的DBS类型之一。应用较为广泛的C/S结构数据库管理系统有Oracle、DB

2、Sybase、MS SQL Server等，这些数据库管理系统都能够支持大型的数据应用业务。本书将讨论基于MS SQL Server的两层C/S结构数据库应用系统项目的开发实例。

3.3 开发数据库应用系统

以数据库为基础的信息系统通常称为数据库应用系统，它一般具有信息采集、加工、抽取和传播等功能，是实现业务应用的数据库系统。开发数据库应用系统需要对其基本结构、所需的技术背景、开发任务和需要考虑的问题有所了解。 3.3.1 数据库应用系统的简单结构

如果抛开DBS中的硬件和操作系统组成部件，就可以采用如图3-7所示的简单结构描述数据库应用系统。从图3-7中可以看出，数据库应用系统由应用程序端、中间件和数据库端三部分组成。

图3-7 数据库应用系统的简单结构

中间件通常由数据库管理系统或应用程序开发环境提供商提供给开发用户使用。中间件是应用程序和数据库之间进行交流的必需通道。设计数据库应用系统时，不需要自己编写，但必须要了解中间驱动的运作原理和使用方法。数据库应用系统中采用的数据库类型和开发环境不同，可使用的中间驱动也可能不同。

如果数据库应用系统使用服务器类型的数据库，应用程序必须要通过数据库服务器(数据库管理系统)才能存取数据库。如果使用的是文件类型的数据库，应用程序可直接存取数据库。数据库服务器由专门的数据库管理系统提供商提供，设计数据库系统时，不需要自己编写，但必须要了解数据库管理系统的运作原理及其提供的数据库开发能力。数据库的设计和实现是开发数据库应用系统的核心工作。

不同的数据库应用系统由于其业务要求和运行环境不同，用于存取和管理数据库中存储的信息的应用程序也不同，这是终端用户使用数据库应用系统必不可少的操作界面。如果数据库应用系统离开了应用程序，终端用户无法直接操作数据库，完成信息管理工作。 3.3.2 数据库引擎

数据库引擎是数据库应用程序与数据库(或数据库服务器)进行交互的接口，负责提交、处理数据库访问请求并返回处理结果。通常，数据库应用程序开发环境都会提供相应的数据库引擎及其开发组件，也可以这样说，在客户端，数据库引擎是由一系列用于进行数据库访问的数据结构和基于这些数据结构的方法(或函数库)组成。

从服务器端响应和处理数据库请求的方式来看数据库引擎有两种基本的体系结构，分别是多进程数据库引擎(见图3-8)和单进程多线程数据库引擎(见图3-9)。 图3-8 多进程数据库引擎运行结构图

图3-9 单进程多线程数据库引擎运行结构图

单进程多线程数据库引擎。这种数据库引擎的优点是：占用资源比较少，成本低，在比较低的配置下也能发挥较好的性能。其特征是：在一个处理进程内创建多个线程来响应多个数据库访问请求。具备比较好的可移植性，但低配置不能支持太多用户数。单进程多线程数据库引擎的代表是SQL Server 2000。

3.3.3 开发数据库应用系统的技术背景和任务

从DBS的组成、体系结构和数据库应用系统简单结构的讨论可知，开发数据库应用系统需要有如下一些技术背景：

应掌握数据库设计的基本理论知识，了解数据库系统的体系结构、数据库的分析建模技术、数据库的体系结构、完整性约束和数据库规范理论等。

应掌握一种桌面数据库和服务器数据库管理系统的应用技术，了解数据库管理系统提供的数据库管理和设计支持能力。

熟悉一种能够支持数据库应用程序开发的开发环境，包括相应的程序设计语言、数据结构、算法分析和应用程序架构技术等知识。

了解开发环境提供的数据库存取技术和所提供的数据库引擎。

了解软件设计和开发过程的一些基本知识，如个体软件过程、团队软件过程和软件工程等。 了解应用程序的分发技术和分发工具，即如何制作应用程序的安装程序以及如何在用户环境中实施数据库应用系统。 开发数据库应用系统的任务是：充分利用上述基础知识和技能，设计实现业务要求的数据库，设计终端用户操作数据库数据的应用程序，在用户环境中实施数据库应用系统以供用户完成业务工作，提高用户的生产率。

3.3.4 开发数据库应用系统需要考虑的问题 开发数据库应用系统和开发其他应用系统一样，需要根据用户的业务需求确定数据库应用系统的运行环境和开发环境等。从技术角度看，通常，开发数据库应用系统需要考虑以下问题。 a.确定数据库应用系统的运行环境，选择合适的DBS体系结构

开发数据库应用系统的首要问题是根据业务要求确定数据库应用系统的运行环境，选择合适的DBS体系结构。如果用户只需要在单机上工作，且需要管理的数据量很小，则应选择单用户结构的数据库应用系统;如果用户的业务需要在局域网环境中同时由不同工作人员完成，则应选择C/S结构的数据库应用系统;如果业务需要在远程机器上完成，则可能需要选择B/S结构的数据库应用系统。

选择不同的体系结构将决定后续的数据库应用系统开发问题，如确定系统开发环境等。同时，开发不同体系结构的应用系统，其开发技术复杂度也不一样，实现的技术也有所不同。 b.基于数据库应用系统的运行环境和体系结构确定数据库 所有数据库都提供了存储和检索信息的能力，但不同数据库提供的附加功能则有所不同，主要表现在以下方面：

不同数据库提供的数据安全保证机制不同。

有的数据库基于文件锁定机制保证多用户并发操作，有的数据库则采用事务并发控制机制，后者比前者效率高很多，占用的资源也相对较大。

不同的数据库描述数据字典(或元数据)的技术不同，提供的数据字典获取和管理技术也不同。

不同数据库对数据完整性的保证措施和程度不同。有的数据库只能保证基本的实体完整性约束(主码)和参照完整性约束，而有的数据库则能够提供较全面的完整性保证技术。

根据不同DBS体系结构中应用程序存取数据库的方式，数据库可分为本地数据库和远程数据库两种类型。集中式数据库应用系统使用本地数据库，而C/S结构的数据库应用系统则需要使用远程数据库服务器。本地数据库的典型代表是Paradox、dBASE、Visual FoxPro和Access等。远程数据库服务器的典型代表是Oracle、DB

2、Sybase、MS SQL Server等。 选择数据库时需要考虑数据库将要存储的数据量、存取数据库的最大用户数和数据库的效率要求这些问题。就存储量而言，本地数据库的存储量比远程数据库服务器小很多。就多用户问题而言，本地数据库也能够支持多用户同时存取数据库，但采用基于文件的锁定技术来控制并发操作;远程数据库服务器是专为多用户并发存取数据库而设计的，采用基于事务的技术控制并发操作，因而提供了更为复杂的多用户支持。就数据处理能力而言，远程数据库服务器的能力比本地数据库强大很多。

同时，选择数据库时还应考虑用户是否有移植数据库的需求。如果需要移植数据库，则开发时需要牺牲部分高效的SQL功能以获得最佳的移植方式，例如遵循不同数据库公用的SQL集进行SQL程序开发等。

第 4 章系统软件实现

本系统是在按照面对对象，基于组件、数据库开发的，拥有全面的错误捕捉和异常处理机制，因此具有更好的稳定性和可扩展性。

4.1 收费计算机和通信机

在收费计算机和通信机之间，我们采用了TCP/IP协议，TCP建立连接时采用客户/服务器模式，主动发起连接的进程叫做客户，被动等待连接建立的进程叫做服务器。在本系统中，收费计算机做为发起连接方，成为客户，通信机为服务器。

4.1.1 动态组件

TCP是面向连接的，因而可提供可靠的、按序传送数据的服务，它提供双向的的连接，即全双工。在收费站，由于环境恶劣，可能会网络故障导致TCP连接中断，或由于通信机维护中断连接。为了故障消除后能自动恢复TCP连接，减少监控人员维护量，采用了动态组件技术，自动检测连接的状态，并给监控人员一定提示。

if( Client->Active == false)

//定义为 TClientSocket * Client { HW_SENDTIME++; if(HW_SENDTIME%20 == 0)

//每隔一段时间尝试重新连接

{ HW_SENDTIME = 0; Client->Close(); delete Client; Client = NULL;

Client = new TClientSocket(this); //新建组件

Client->ClientType = ctNonBlocking;

Client->Address = sIpaddr; //通信机IP地址

Client->Port = atoi(sPort); //通信机端口号

Client->OnDisconnect = ClientDisconnect; //映射Disconnect事件

Client->OnRead = ClientRead; //映射Read事件

Client->OnError = ClientError;

// 映射错误处理事件

try{ Client->Open(); } catch(...){ Client->Close(); } } } else{ ………; } //网络连通，上传数据

通过动态TClientSocket组件的建立，网络连通和中断切换过程对操作人员是隐含的。不会影响车道收费系统的正常运行，网络正常后自动恢复上传数据功能，保证了车道的最大工作效率。

4.1.2 TCP报文的构成

应用层的报文传送到运输层，加上TCP的首部，构成了TCP的数据传送单位，称为报文段。在发送时，TCP的报文段作为IP数据报的数据，加上首部后，成为IP数据报。在接收时，IP数据报将其首部去除后交给运输层，得到TCP报文段。再去掉其首部，得到应用层所需的报文。

一个TCP报文问为首部和数据两部分，TCP报文段首部的前20个字节是固定的，后面有4N字节是可有可无的选项，因此TCP首部的最小长度是20字节，加上IP数据报的首部后至少有40个字节。如果TCP的数据段只有一个字节，那么网络的利用率就不会超过1/41。反之，如果TCP报文段非常长，那么在IP层传输时就可能要分解成多个短数据报片，在目的站还要将收到的各个数据报短片装配成原来的TCP报文段，加上出错时还要重传，加大了系统开销。一般认为，数据段应尽可能大些，只要在IP层不再分片就行。TCP缺省的数据段长度是536字节，因此我们在发送TCP报文时，要控制数据长度在这个范围之内，同时包含尽可能多的信息。比如我们在收费流水数据包中包含车道设备状态字节，这样我们就可以在监控室了解设备运行状态。

在本系统中，存在着多种数据包，如收费人员登录、收费流水、收费标准、通信机转移等。为此我们定义了多种数据类型。

我们定义的TCP报文的数据段由两部分构成，报头(TPACKETHEAD)和数据(PacketData)。报头是格式是固定的，用PacketType来区分不同的包类型。其定义如下：

//Packet = PACKETHEAD+ PacketData typedef struct { char tag[2]; //version 0x453b int PacketLen; //包长

char PacketType; //包类型

int trytimes; //重传次数

char sIpaddr[20]; //通信机地址

char sRet[2];

//标志，OK通信机写入数据库成功、ER写入失败

}TPACKETHEAD;

这里以收费流水数据为例，说明PacketData结构。

typedef struct //流水帐数据结构 { char LSH[13]; //流水帐号

char CXDM[3]; //车型代码

int je; //金额

char FJDW[11]; //车辆吨位

char SKRQ[20]; //收款日期 char SKSJ[20]; //收款时间

char GH[11]; //工号

char SKY[21]; //收款员

char CDH[4]; //车道号

char BH[2]; //班号

int CG; //冲岗标记

int MF; //免费标记

int YP; //月票标记

char TICKETNO[9]; //票据号

char devicestate; //设备状态

}TLsz; 4.1.3 数据包的抽象

面对对象程序设计的本质是把数据和处理数据的过程当成一个整体——对象。C++本身就是面对对象的语言，能将各种数学模型封装成对象，因此具有更好的稳定性和扩展性。在本系统的实现过程中，由于存在着多种数据包，为此，我们抽象出数据包的基本共性，形成数据包的基类TpacketBase。

class TPacketBase { private: TPACKETHEAD * pHead; char *pBuf; //发送缓冲区

public: int Sendpdate (void); //发送数据包

int Readpdate (void); //接收数据包

int pTypeExcute (int pType);

//按pType类型执行相关工作 }; 各数据包类以此为基类，实现数据包的发送和接收工作，并扩充了自己的成员变量和成员函数。以流水帐数据包为例。

Class Tlszpak : public TpacketBase {private: TLsz lsz; public: int Getlocaldate (void); //取本地数据

int Fillpacket (void); //填充数据报

};

其他类型的数据包，如登录、收费标准等的实现与流水帐数据包类似。 4.2 管理工作站

随着Internet的普及、城域网和广域网的发展，对监控提出了更多的要求。目前要求建立地区监控中心或者省级远程监控中心，由于各个收费站监控收费系统承包商的开发语言各不相同，基于商业利益的考虑又不会开放源代码，对监控中心的管理带来麻烦。因此，解决问题的最佳途径，就是遵循“开放系统”最大限度保护用户原有硬软件投资的原则，走开放系统结构(OSA)。即新上的项目一定要符合OSA标准;原有的项目，通过转换或改造接入开放系统。

对于管理工作站的软件，我们建立了基于INTERNET收费管理系统，采用C++Builder的ActiveForm技术开发，给本地监控和远程管理带来许多鲜明的特点和优点，其软件模块划分如图3所示。

这种方式的主要优点是：同时可以在一台客户机上完成多种客户机的功能;界面统一，使用和培训相对容易便于实现多个收费站的统一管理;采用INTERNET浏览器操作方式，自动下载最新版本，便于升级。 a.收费监视

本系统运行于图像处理工作站上。工作站的显示器配置于操作台上，用于监视和显示车道设备工作状况以及收费员操作情况。系统主要功能如下： 1) 动态实时显示收费车道状态，其中包括： l 收费员姓名 l 车道号

l 天棚信号状态(红色“×”或绿色“↓”) l 通行灯状态

l 自动栏杆机的状态 l 收费员判定的车型车类 l 通信线路正常/故障

2) 显示最近抓拍的车道特殊处理图像。

3) 接收矩阵的输出，实时显示摄像机采集的一路视频信号。 4) 任意摄像机间的切换和广场摄像机的变倍变焦操作。 5) 图像查询打印功能

l 随时来查询车道软件所捕获的所有图像。可以输入的条件有：时间如年月日，地点如车道，人员如收费员，或者是以上条件的组合 l 打印图像。查到所需图像以后，可以打印。 b.数据查询 1) 入口车道过车记录查询 l 以卡编号为关键字查询

l 以入口车道编号为关键字查询 l 以时间段为关键字查询 l 以收费员编号为关键字查询 l 以收费员班次为关键字查询 l 以卡编号为关键字查询 l 以车型为关键字查询 l 以费额为关键字查询

l 以上条件之间的相互组合为关键字查询 2) 出口车道过车记录查询 l 以卡编号为关键字查询

l 以出口车道编号为关键字查询 l 以时间段为关键字查询 l 以收费员编号为关键字查询 l 以收费员班次为关键字查询 l 以卡编号为关键字查询 l 以车型为关键字查询 l 以费额为关键字查询

l 以上条件之间的相互组合为关键字查询 c. 统计报表打印预览及打印模块

包括以下统计报表：

l 高速公路收费员班次报表(入口)

l 高速公路收费员当班特殊处理明细表(入口) l 高速公路收费员当班明细表(入口)

l 高速公路收费员当班特殊处理明细表(入口) l 高速公路收费员当班明细表(出口) l 高速公路收费站班次汇总表(入口) l 高速公路收费站班次汇总表(出口) l 高速公路收费站通行费收入日报表 l 高速公路收费站通行费收入月报表 l 高速公路收费站通行费收入年报表

l 高速公路收费站入口车道特殊处理明细日报表 l 高速公路收费站出口车道特殊处理明细日报表 l 高速公路收费站交通流量日报表 l 高速公路收费站交通流量月报表 l 高速公路收费站交通流量年报表 l 高速公路收费站交通流量OD日报表 l 高速公路收费站交通流量OD月报表 l 高速公路收费站交通流量OD年报表 l 高速公路收费站交通流量日分析表 l 高速公路收费站交通流量月分析表 l 高速公路收费站交通流量年分析表 d.系统管理模块 l 收费员信息编辑 l 费率信息编辑 l 收费站信息编辑 l 车道信息编辑 l 车型车类信息编辑 e.工班清帐管理系统

结帐管理系统由以下模块组成: l 管理人员登录模块 l 收费员工班管理模块 l 收费员当班数据录入模块 l 数据查询统计模块 1)管理人员登录模块

l 系统对管理人员的认证 l 人员登录名称,口令添加 l 人员登录名称,口令修改 l 人员登录名称,口令删除 2)收费员工班管理模块 l 收费员工班分配 l 收费员工班调整 l 收费员工班查询

3)收费员当班数据录入模块

录入内容：收费员班次,编号,姓名, 通行卡实缴数, 通行费实缴数, 定额票据金额, 废票上缴数1, 废票上缴数2, 值机员编号, 执行录入操作的时间(由服务器时间自动获得),备注等。 4)数据查询统计模块

l 按照收费员姓名查询 l 按照收费员编号查询 l 按照收费员班次查询 l 按照值机员编号查询

l 按照执行录入操作的时间段查询 l 按照以上条件组合查询 根据查询结果,自动统计出: l 通行卡实缴数总和 l 通行卡实缴数总和 l 定额票适用张数总和 l 定额票据金额总和 l 废票上缴数1总和 l 废票上缴数2总和 IC卡管理系统日常报表：

l 高速公路收费站入口通行卡发放日统计 l 高速公路收费站入口通行卡发放月统计 l 高速公路收费站入口通行卡发放年统计 l 高速公路收费站出口通行卡回收日统计 l 高速公路收费站出口通行卡回收月统计 l 高速公路收费站出口通行卡回收年统计

IC卡管理系统主要数据库表结构：

通行卡调入表 含义 调入时间

卡号

相关人员编号

通行卡调出表 含义 调出时间

卡号

相关人员编号

通行卡坏卡回收表 含义 坏卡回收时间

坏卡卡号

收费员编号

收费员班次

车道号

注释

相关人员编号

通行卡坏卡上缴表 含义 坏卡上缴时间

坏卡卡号

注释

上缴值班员工号

通行卡日库存记录表含义 库存统计日期

正常卡库存数量

发放通行卡数量

回收通行卡数量

调入通行卡数量

调出通行卡数量

恢复通行卡数量

库存坏卡数量

坏卡回收数量

坏卡上缴数量

库存维护数量

字段名

Intime Ickn Managern 字段名

Outtime Ickn Managern 字段名

Getintime Bkn Tollern Class Carroad Note Managern 字段名

Putuptime Bkn Note Managern 字段名

Sdate Stockn Pn Gn Inn Outn Hfn Stockbk Getinbk Putupbk Stockchange 类型

Datetime Int Int 类型 Datetime Int Int

类型 Datetime Int Int Tinyint Tinyint Char Int 类型 Datetime Int Char Int 类型 Datetime Int Int Int Int Int Int Int Int Int Int 字段宽度 8 4 4 字段宽度 8 4 4

字段宽度 8 4 4 1 1 20 4 字段宽度 8 4 20 4 字段宽度 8 4 4 4 4 4 4 4 4 4 4 序号 1 2 3 序号 1 2 3

序号 1 2 3 4 5 6 7

序号 1 2 3 4

序号1 2 3 4 5 6 7 8 9 10 11

通行卡恢复记录表 含义 恢复时间 卡号

相关收费员工号 班次 入库方式 字段名 Gettime Ickn Tollern Class Stocktype

类型 Datetime Int Int Tinyint Tinyint

字段宽度 8 4 4 1 1

序号 1 2 3 4 5 入口车道原始过车记录 含义 字段名

卡网络编号

RCardNetwork 卡编号

RCardID 入口网络编号

EntryNetWork 入口站编号

EntryStation 入口车道编号

EntryLane 入口日期时间

EntryTime 入口统计日期

EntryDate 入口收费员编号

EntryOperator 入口收费员班次

EntryShift 车型

RvehicleClass 改型前车型

RPvehicleClass 费额

Toll 设备状态

RdeviceStatus 纪录类型

RRecordType OD分类车型

RODSpecification 保留 Reserved 出口车道原始收费记录

含义 字段名

卡网络编号

CardNetwork 卡编号

CardID 入口网络编号

EntryNetwork 入口站编号

EntrySttion 入口车道编号

EntryLane 入口日期及时间

EntryTime 入口统计日期

EntryDate 入口收费员编号

EntryOperator 入口收费员班次

EntryShift 入口车型

RVehicleClass 出口网络编号

ExitNetwork 出口站编号

ExitStation 出口车道编号

ExitLane 出口日期及时间

ExitTime 类型 Smallint int

Smallint Smallint Tinyint Datetime Tinyint int Tinyint Tinyint Tinyint Smallint Smallint Tinyint Tinyint Smallint

类型

Smallint Int

Smallint Smallint Tinyint DateTime Tinyint Int Tinyint Tinyint Smallint Smallint Tinyint DateTime

字段宽度 2 4 2 2 1 8 1 4 1 1 1 2 2 1 1 2

字段宽度2 4 2 2 1 8 1 4 1 1 2 2 1 8

序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

序号1 2 3 4 5 6 7 8 9 10 11 12 13 14

出口统计日期 出口收费员编号 出口收费员班次 车型

改型前车型 总费额 设备状态 业主网络编号 业主编号 业主分帐额 记录类型 标识站

OD分类车型 仲裁车型

仲裁管理员编号 保留字段

车道费率表 含义

入口网络编号 入口站编号 入口站名 出口网络编号 出口站号 出口站名 标志站 车型 总费额

收费站名表 含义

收费站编码 收费站名称

ExitDate ExitOperator ExitShift VehicleClass PVehicleClass TotalToll DeviceStatus OwnerNetwork OwnerID OwnerToll RecordType FlagStations

RODSpecification Judgetype JudgeID Reserved Tinyint Int Tinyint Tinyint Tinyint Smallint Smallint Smallint Tinyint Smallint Tinyint Long Tinyint Tinyint Int

Smallint 1 4 1 1 1 2 2 2 1 2 1 8 1 1 4 2 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

字段名

EntryNetwork EntryStation

EntryStationname ExitNetwork ExitStation

Exitstationname FlagStations VehicleClass TotalToll 类型 字段宽度 Smallint 2 Smallint 2 Varchar(20) Smallint 2 Smallint 2 Varchar(20) Int 4 Smallint 2 Smallint 2 序号 1 2 3 4 5 6 7 8 9

字段名 StationID StationName 类型 字段宽度 Int 4 Varchar(20) 序号 1 2 每班收费员下班填报数据表 含义 字段名

Date 统计日期

Shift 收费员班次

Operatomum 收费员编号

OperarorName 收费员姓名

Data11 通行卡实缴数

Data21 通行费实缴数

Data31 定额票适用张数

Data32 定额票据金额

类型

Tinyint Tinyint Int

Varchar(8) Smallint Int

Smallint Int

字段宽度 1 1 4 2 4 2 4 序号 1 2 3 4 5 6 7 8 废票上缴数 废票上缴数 值机员编号

执行录入操作的时间 备注 Data41 Data42

Surveillantnum Time Remark Smallint Smallint Int

Datetime Char 2 2 4 8 20 9 10 11 12 13

4.2.1用户登录模块

收费站计算机系统软件一律采用窗口界面系统，值班管理员在绝大多数情况下只需使用鼠标器在屏幕显示的任意一个菜单上双击即可选中该功能，并使计算机完成一系列控制、显示、打印等操作。计算机在系统登录时检查操作人员身份密码，以确认其是否有权力使用该项功能。

某高速路收费系统设计了美观大方，操作方便的用户登录界面、主界面、车辆收费界面，典型界面如下图：

图4.1用户登录界面

4.2.2 主界面模块

图4.2 主界面

4.2.3 用户管理模块

4.2.3 用户管理界面

图4.4用户管理界面

4.2.4车辆收费模块

图4.4车辆收费界面

第5章 收费系统服务器维护与管理

收费站的服务器非正常关机之后便发生故障，系统无法启动，造成全所收费当班结账工作无法正常进行。经过技术人员的检查，确认为服务器的硬盘损坏而造成系统的无法工作。后虽经多方面的不懈努力，恢复系统的工作，但是仍有部分历史数据由于客观条件所限终究无法恢复，造成了一些无法挽回的损失。不禁使人认识到这样一个问题的重要性，如何更好的保护好我们的收费系统服务器，减少故障的发生;如何有效地保护收费数据，把此类故障造成的损失减小到最小。

5.1事件的初步分析

服务器故障，虽说是个偶然突发事件，但有它的必然发生性。首先，监控室人员对机房环境保持不佳以及技术人员对服务器维护重视程度不够，应该是导致本次事件的直接原因。从现场拆下的服务器来看，机箱内部充满了灰尘和异物，电路板上也是尘迹斑斑。通过测定，主硬盘的电路控制部分已经损坏，镜像硬盘上系统重要文件错误丢失无法使用，从系统的日志分析，早在一周以前，备份磁盘镜像就已经断开……等等，这些都充分表明，该服务器很长一段时间没有受到足够的重视，最终不幸发生系统的崩溃，数据的丢失。

其次，服务器配置上的不尽合理客观上加大此类事件发生的几率。某收费服务器采用的是惠普LC3 PC服务器，配以微软Windows NT server4.O作为操作系统，采用微软SQLServer7.0作为数据库平台。由于NT Server对系统内存的最低要求是32M，加上服务器上运行的SQL数据库系统和其他后台服务程序，并进行软件RAID l磁盘镜像，更是需要很大的系统资源，而该服务器的内存总量仅为64M，除去以上所述资源占用以外，真正留给数据服务使用的内存资源已是所剩无几。系统在内存不足之时，会采用虚拟内存进行补充，利用硬盘空间作为进行数据交换和读取，随着高速公路的车辆通行数的不断增加，服务器的负荷也明显增大，磁盘读取数据也越发频繁，时间长了，必然加速设备的损坏，缩短硬盘的使用寿命。

5.2.1加强收费服务器的日常维护

某站的事件，给了各位高速公路的工程维护人员敲响了警钟，如何更加切实有效的做好系统的维护保养工作，确保设备的稳定运行，将是大家面临的重要问题。

5.2.2定期做好服务器的清洁工作

由于客观条件等因素的限制，目前高速公路收费系统站级服务器均同所里监控室在一起，并无采用专门收费系统机房放置。由于平时监控室内人员进出较为频繁，长此以往，势必造成服务器内的灰尘堆积，机内均为精密电子元件，这样的运行环境对硬件的损坏很大。

因此，很有必要定期(建议大约2个月)对服务器进行一次停机清洁，这对延长内部的元器件使用寿命很有帮助。

5.2.3做好紧急修复磁盘和系统启动盘

目前我们的收费系统服务器采用微软公司的Windows NT server作为操作系统，在安装Windows NT Server时准备一张l.44MB的3.5”软盘，用于创建紧急修复盘。紧急修复盘上保存了修复系统所需的数据，当系统文件因故被损坏时，可协助管理员修复丢失或损坏的Windows NT文件，并恢复Registry(登录)，包括了安全账户管理(SAM)数据库、安全信息、磁盘配置信息、软件Registry项以及其他系统信息，使Windows NT能够正常启动。因为Windows NT Server采用NTFS磁盘文件系统，一旦出现故障，使用系统紧急修复盘，可以十分便利的访问系统分区，读取其中的文件，这对我们恢复系统十分有利。利用系统恢复盘，使得工程技术人员能够从像磁盘中获得了许多原先系统的资料，如用户信息，备份日志等，挽回了损失。

5.2.4定期检测磁盘，察看系统的日志文件

在让NT操作系统捕获重要的软硬件信息后，可以用Event View查看这些信息，跟踪服务器运行情况。因此定期察看系统的日志是很有必要的;服务器的硬盘频繁进行数据的读写，有时会因为异常断电或外部震动等因素使硬盘产生坏点，如果能定期检查硬盘，察看系统的日志，及时发现错误，就能减少系统崩溃或数据丢失情况;在发现硬盘有坏点的情况下，可以进行扫描修复，以确保数据安全，延长硬盘的使用寿命。

5.2.5做好数据库的备份工作

数据库是信息系统的心脏，是信息资源开发和利用的基础。目前的服务器都已采用磁盘镜像的方式进行全盘数据备份，尽管此次，建立一套策略和方法，定期做好SQL数据库文件的单独备份，还是显得十分的必要，尤其在数据文件遭遇不幸的时候，能够尽快的恢复，减小损失。需要特别重视的是数据库内的各种结构表、重要存储过程以及各种参数、原始拆帐数据等，一旦出现意外，能够在最短的时间内给予恢复。

5.2.6做好病毒的防治工作

随着软件开放性和网络技术的不断普及和发展同时，也给了计算机病毒提供了十分便利的传播途径;在高速公路专网内，服务器之间以及服务器同工作站之间大量的文档、结构化或非结构化的收费数据、统计数据通过网络来传输和处理，这种频繁和大规模的文件、数据交换为病毒传播大开便利这门;目前，高速公路收费系统已实现全路段的联网收费，一旦遭遇病毒入侵，势必引起全线收费数据的破坏，后果将不堪设想。因此，定期进行服务器、工作站间的病毒检测是一件十分必要和关键的步骤。例如：2003蠕虫王(Worm.netkiUer2003)，正是利用SQLServer数据库系统的漏洞，采用“缓冲区溢出”技术，进行网络感染与攻击，从而对网络和服务器造成严重危害，导致网络严重阻塞，甚至造成SQL Server服务器的全面瘫痪。2002年，就曾经因此让全球网络接近瘫痪6小时。因此，在做好病毒的防治工作时，还必须充分运用网络杀毒软件、防火墙以及入侵检测等多种手段，才能够有效预防并清除危害。

5.3数据管理模式的分析和比较

如前所述，某服务器故障虽说是由多方因素引发的——人为疏忽，硬件配置不合理等都直接或者间接的导致了此次故障的发生。从某站的事件中，我们也充分认识到了加强日常维护保养工作的重要性。可是，仅仅如此吗?在高速公路管理系统的不断建设发展的今天，在经济发达、交通量较大的路段管理地区，都已提出要求降低运行成本，提高经济效益。这些新的需求，都要求我们的系统管理和建设者需要思考新的管理方式和系统结构。这正是我们下文所要阐述的观点：从管理模式的角度，结合泉港服务器事件，根据实际的功能需求，对目前所采用的沿用多年的数据管理模式进行分析讨论，我们大胆提出：收费系统应该改变当前的数据管理模式，采用一种新型的数据管理——集中式管理，从而使得高速公路收费管理更加规范的进行，真正最大限度的避免此类事件今后不再发生。

5.3.1现有某高速公路的收费管理模式

目前，某高速公路收费系统采用多年传统使用的分中心一站一车道的分散管理模式。即由收费站系统、收费分中心系统、省中心拆帐系统共同组成，分为三级管理模式：收费站—分中心一省中心，具体的网络拓扑图如图1所示：

其中车道与收费站之间组成星形结构的局域网，收费站与收费分中心之间、收费分中心与收费拆帐中心之间租用专用速率64Kb/s的DDN线路进行通讯。 5.3.2现有数据管理模式的优缺点

优点 ：

a)对网络的依赖性小，网络不通时，收费站级系统的业务处理正常进行;

b)业务操作不面向大型数据库，系统运行的效率较高;

缺点：

a)系统配置相对烦琐，维护量较大。由于整个路段收费站的系统维护工作由所辖分中心技术人员负责，而每个收费站远离分中心，因无形中加大了系统的维护量;

b)增加了系统配置的开支;

c)维持两端相应数据的一致性占用了一定的系统资源;

d)对收费站机房环境的要求很高，容易出现人为的服务器故障如关机、断电等。也正是上述的这些不足，为泉港的服务器故障埋下了隐患，这不能不引起我们的思考——有没有更好数据管理方式，可以减少故障发生。 5.3.3数据集中管理模式的定义和特点

所谓数据集中管理一就是结合各路段管理范围的特点，采用弱化原收费模式收费站功能，加强收费分中心、总中心的管理功能，集中在收费分中心、拆帐中心进行收劳业务管理的新型管理方式。它的核心，就是利用计算机软件、网络技术及相关设备对某个路段的收费数据进行集中处理，有效地保证计算机主机上所有数据的完整性、可靠性、稳定性，有利于收费业务的规范化管理。具体地说，在某高速公路收费系统中，利用监控分中心的收费服务器，在分中心的直接监督下对各个收费车道、收费站进行收费业务数据的采集和处理以及管理和统计，而不通过收费站服务器。因此，数据管理模式分二级，省拆帐中心——分中心，网络拓扑图如图2所示：

其中收费分中心与收费站、收费拆帐总中心与收费分中心之间利用高速公路建成的专用通信网进行通讯。

集中管理又有哪些特点呢，正如我们上面提到的，具体的从上面的网络图，很容易看出：采用了集中数据管理模式，优缺点如下：

优点

a)采用了集中数据管理，使得只在分中心设置一台服务器：每个收费站不设服务器作为系统的一个使用终端，从而降低了成本。

b)服务器管理简单，便于维护，大大减少了分中心技术人员的维护工作量。

c)数据的安全性好，由于采用集中式管理，减少了当中的许多环节，最大限度避免了其他因素造成的破坏。

缺点

a)由于需要对各站进行数据处理，对服务器的处理能力和运行速度等要求较传统方式有很大提高。

b)当某些主要设备出现故障时，影响的范围要广一些，因此对网络可靠性、稳定性要求较高。

5.4集中管理模式的可行性分析

5.4.1网络可靠性分析

从集中管理的定义以及上述的图示，可以很容易的知道，想要实现数据的集中(部分集中)管理，最重要的前提条件便是需要一个快速、稳定、安全的通讯线路，将各类的数据上传至分中心和中心服务器。这样的要求，在高速公路通讯网络建立以前是很难满足和实现的，因此也无法试行集中管理。随着高速公路建设的不断深入，网络通信模式将由原先租用DDN专线方式转为基于光纤传输的SDH同步数字通信方式;对于收费数据的传输采用SDH 2M带宽，大大满足收费业务数据传送需求。光纤通信具有如下特点：

a)频带宽，具有很大的传输容量，主干网的速率达到2.5Gb/s，本地网速率也可达2Mb/s，可以满足各类数据的传输要求;

b)通信质量好，不受外界电磁干扰;

c)通信距离可长可短，符合高速公路通信业务分布特点。因此，稳定可靠的高速公路光纤专用通信网为实现数据集中管理模式创造了必要条件;

5.4.2服务器系统软硬件平台

当前的企业服务器主要分作两大类，其中一类是以IBM、HP等公司为代表的小型计算机服务器，如IBM RS/5000 M80，M85小型机，另一类便是目前正在使用的以普通的PC为基础的PC服务器。小型机虽性能较PC服务器强，但同样价格也高出甚多。采用数据集中管理模式后，对拆帐中心、分中心的服务器处理能力和运行速度及可靠性要求很高，首先应能满足整个路段各收费站的各种业务需求，在充分考虑功能需求的基础上，对所需设备的主频、内存、存储空间、传输率及可靠性等方面进行具体分析，并通过模拟实际的使用环境对设备的处理能力、数据吞吐量等作详细地计算后才能确定选用服务器类型，且莫一味的追求高性能，造成投资浪费。同样考虑到今后的车流量等数据的增加，还应留有一定的富余量，避免出现设备与应用问可能出现的“大马拉小车”、“小马拉大车”的问题，避免设备购置的盲目性。

随着高速公路路网的不断形成，联网收费系统对计算机网络安全性和可靠性的要求较高，因此对于服务器操作系统和数据库的选用也非常重要。目前服务器最为普遍采用的操作系统有Windows NT、Unix、Linix等。按照中心和分中心服务器的设计要求和作用，应首要从系统的安全性和稳定性方面人手考虑，建议优先采用以Unix为核心的操作系统。同样当前可采用的数据库软件平台众多，如：SQL Server、ORACLE、SYBASE、INFORMIX和INGRES、DB2等，各有所长，建议选用的原则应从以下几个方面人手：支持客户/服务器体系结构;支持高性能的并发控制和联机事务处理;支持主要网际互连协义(TCP/IP、APPC等)和局域网协议(如TCP/IP、SPX/IPX);支持SQL标准;考虑安全性、灾难恢复和事务完整性;具有良好的可移植性和可扩展性;支持大量的第三方产品，能满足不断发展中的各类业务要求;支持Cluster系统，并能自动实现任务均衡和任务切换;支持SMP系统;至少支持PowerBuilder、Delphi、Microsoft Visual C++等RAIDG开发工具，具备完善的Intemet开发工具以及确保系统升级时可移植性等等。

5.4.3冗余独立磁盘阵列RAID等安全措施

采用数据集中管理模式，对设备的安全、稳定性方面的要求特别高，应充分考虑服务器的冗余备份问题。建议同时采用双机热备份服务器和磁盘阵列方式，当前很多服务器无须磁盘阵列柜就可构成磁盘阵列，磁盘阵列内置于主机中，如HP6000高档服务器，将数据库系统和应用系统放在阵列磁盘上，这样相当于有了双重硬件防护。确保在硬盘损坏时，磁盘阵列起作用，当主机出现除硬盘外的故障时启动备机，确保收费业务的不间断运行。

第五篇：关于德国高速公路收费系统的报告

一、背景

在欧洲，高速公路不收费的国家屈指可数，德国便是其中的一个。由于地理位置处于欧洲中心，高速公路发达，所以东西欧国家的载重卡车来往时就首选德国，既经济又快捷。这就给德国高速公路带来了巨大压力：公路拥挤，路面毁损严重，而公路维修费用高昂，给德国政府造成了巨大的经济负担。90年代初期高速公路蓬勃发展之时，德国政府就决定了要使用先进科技手段，按照载重量和在高速公路上行驶的里程数向过往的载重卡车收费的政策。

2003年8月26日，德国在比利时的布鲁塞尔与欧盟运输委员会达成共识，德国将从11月开始对在其境内高速公路上行驶的载重汽车征收附加费用。所有超过12吨的货车(含挂车)，不论所属国籍，不论是否空载，都必须为行驶过的高速公路路段付费。付费金额根据车辆载荷及尾气排放情况分6个档次，每行驶1公里收费10至17欧分。收费系统将经过两个月的试行期后，于2003年的11月2日正式运行。但在验收时出现重大技术问题而无法达到验收标准，最终无法通过验收。

2005年1月1日，德国正式推出针对总重12吨以上卡车的高速公路自动收费系统。

二、该收费系统的优点

由于德国只对高速公路上的货车进行收费，没有其他经验可以借鉴，德国政府决定采用世界上第一个由卫星定位控制的全自动收费系统，这样做的好处在于：

1、可以自动鉴别高速公路与国道，只计算车辆在高速公路上行驶的公里数。

2、车辆通过监测点时，自动与计算中心结算，免除了收费站点前排队堵车的局面。

3、收费合理，新型的全自动收费系统以实际行驶公里数为结算基准。

4、这项技术同欧洲其他国家使用的微波技术相比，优点更为突出，尤其是在面积较大的国家运用。因为，微波技术依赖标杆传感的支持，每隔一段距离就要建一个标杆，而通过卫星和移动信号控制的系统，则不必建标杆。

三、该收费系统的设计实施 重载货车卫星收费系统的核心技术是全球定位系统和全球移动通讯系统技术，它可以利用车载设备中的高速公路路段地理信息和费率，自动计算车辆所行驶的路段和应缴纳的费额，通过短消息将车辆的相关信息和应缴纳的养路费数额自动回传到收费中心，形成缴费记录，每天按缴费记录从运输公司或营运货车的银行账户中自动划款完成缴费，同时将每天收到的所有资金转交给联邦货运局。自动收费的具体申请流程是运输公司或运营货车向收费系统的开发、维护公司申请注册，每辆车得到一张卡片，卡上存有该车的主要资料，如车轴数、

载重量、排放级别等，货车凭卡在特约服务商那里安装车载单元。 未配有车内仪器的车辆可选择手工结算的方式，包括利用自助终端预缴费系统和互联网预缴费两种方式。 自助终端预缴费系统是为方便不经常使用德国高速公路的大货车用户设立的。在德国各地的加油站和高速公路的休息区等地方，共设有3600个手工的自动终端。终端上有德语、英语等多种服务式可以选择，用户通过电脑触摸屏输入出发地和目的地后，电脑就能计算出最短的路程和所需付的费用。同时支持汽油卡、信用卡、银行卡或是现金等多种支付方式。互联网预缴费则需要用户先通过互联网进行注册，得到个人的电子用户名和密码，缴费信息和用户资料都是高度保密的。

四、缴费监控以及对违规行为的制裁

为了保障养路费足额、准时缴纳，一整套固定式自动检查和移动路上检查相结合的、完善的监控系统得到广泛应用。该监控系统包括固定式监控(固定站点检查)和移动式监控(沿高速公路线)。 德国的高速公路上共建有300座监控桥，能够进行固定式无人监控，车辆距桥15米时安装在检测桥上的红外传感器就会检测到。

移动式检查主要是指联邦货运局的约900名工作人员，利用270辆流动监控车，将全国高速公路分成21个监控区进行缴费稽查。监控车工作时，一般配备两名工作人员，一人负责开车，一人负责监控。为了方便现场处罚，每辆车上还配备了手持的红外DSRC显示设备。

在300个固定式监控桥中，还有150个检测桥安装有无线局域网设备，能覆盖监控桥附近的一些高速公路服务区，方便联邦货运局的工作人员进行检查。利用这种检查方式时，可以将监控车开到检测桥覆盖的服务区内。一个工作人员在车上通过无线网将车载计算机登录到检测桥上，如果监控桥发现有违规车辆，通过无线网就会把车辆图片立刻传递给车载计算机并显示在屏幕上，经车上工作人员确认，就会用步话机通知事先安排好的已经站在路边的另一位工作人员拦截下该车，让其进入服务区进行进一步的检查，并对证实违规的车辆施以罚款。

联邦货运局还会抽查各运输公司的经营账目，来检查他们有无依法交纳养路费。

如果货车没有及时交纳养路费，又无法确定真实行车里程，可以事后按照500公里的行车里程进行补交。如果货车司机有逃避养路费、不(及时)出示缴费收据、不配合检查等违规行为时，可以处以最高20，000欧元的罚款。

五、该系统实施的困难和存在的问题

1、它离不开美国的GPS定位系统。假如美国政府出于某种目的做出决定，关闭GPS系统，德国高速公路收费系统将会立即陷入瘫痪。又如，假如美国人为改变GPS导航精度，使定位精度偏差100米，那么该收费系统便分辨不出被监控的卡车是行驶在高速公路上，还是行驶在联邦公路上。目前，GPS的导航精度约为10米，但是在靠近城区的地段，因有建筑物干扰，存在导航盲区，如果运输公司对收费金额存有疑问，提出公司的卡车在柏林、法兰克福或慕尼黑没有走高速，收费管理公司就有可能拿不出确凿证据。

2、逃费车的管理。每天碾过德国高速公路的重型卡车达160万辆，只有少数车辆经移

动通讯信号检查过，尤其是外国车辆。将来，一旦实行收费，预计每年卡车的逃费金额可达数百万欧元之巨。一般来说，逃费车可以通过车牌照找到，司机也会收到补交款通知书。但是，对于那些匆匆过境而去的外国车辆，补交款通知书的寄送和具体处理还没有好的办法。

六、该技术在中国的展望

随着中国汽车工业现代化的发展，高速公路的成长速度也十分惊人。到2004年年底，中国高速公路已超过3万公里，位居世界第二。据中国交通部公布的发展计划，2007年以前，中国的高速公路将超过7万公路。面对这一发展势头，中国不得不考虑修路和养路的代价。在借鉴了许多国家的不同系统之后，中国专家将眼光停驻在德国由卫星导航的收费系统上。

正象当年引入德国的磁悬浮列车一样，这回中国看好的也是一项由德国开发的世界领先技术。这项技术同欧洲其他国家使用的微波技术相比，优点更为突出，尤其是在面积较大的国家运用，因为，微波技术依赖标杆传感的支持，每隔一段距离就要建一个标杆，而通过卫星和移动信号控制的系统，则不必建标杆。