基于B/S架构的高速公路联合稽查系统设计与实现

刘捷，胡倩

0 引言

随着高速公路联网收费通车路网规模的不断扩大，通车里程的不断增加，单车单次交费的费额急剧上升，偷逃通行费所带来的高额利润导致该行为愈演愈烈，偷逃手段不断翻新,流失费额触目惊心，收费管理、稽查水平的提高迫在眉睫[1]。目前所存在的几种逃费手段主要包括：采取不法手段对抗计重收费、非正常行驶、换卡逃费、假“绿通”、泛滥、假军警牌和假证件逃费、暴力抗费和无牌车冲岗[2]。对一些逃费行为的确认，需要跨路段调取现场图像，如何快速便捷地调取流水数据及现场图像，是稽查能否成功的一个关键。

为了更好地解决上述问题，满足稽查工作的实际需求，特设计了该高速公路联合稽查系统，目标在于实现收费抓拍图像的跨路段查询、实时性查询以及可疑车辆的联合稽查处理。

1 跨路段联合稽查的工作内容及存在的难点

联合稽查系统主要是针对正常收费的车牌不符车辆、正常收费的有理由超时车辆、闯关车辆、车型不符时间段连续出现车辆、免费车及入口信息、免费车车牌查询等特殊事件进行稽查。在稽查的过程中，主要通过对流水信息和图像的人工对比来完成。

目前，各个路段属于不同的业主，各自独立运营。每个收费站每日所产生的流水记录汇总到各个路段中心进行保存，而图像信息则保存于各自收费站。出于安全方面的考虑，各路段中心并不对外开放读权限，而是设置路段代理，路段代理负责接收外部请求，经过安全检查之后再转交给路段中心处理，并将处理结果返回给访问者。同样的，收费站也设置有收费站代理，负责处理对于图像的访问请求。

当一次特殊事件涉及不同路段的收费站为出入口时，典型的查询流程如图1所示：

图1 旧架构下的查询流程

当路段A的收费中心发现从路段B进入的疑似逃费车辆时，需要查询B路段的收费信息和图像数据，就需要向区域管理点代理发出查询请求，由区域管理点代理通过区域管理点查询服务向路段B的查询系统进行查询，在路段B数据库返回图像信息后，再由区域管理点代理将图像返回给路段A的收费中心，这时路段A的收费中心才能进行稽查。整个查询流程冗长，交换机制复杂，响应速度低下，难以适应目前稽查工作的要求。

2 基于B/S架构的高速公路联合稽查系统

2.1 系统拓扑结构

为了解决上述问题，该高速公路联合稽查系统采用星型结构，系统拓扑结构图如图2所示：

图2 系统拓扑结构图

底层结构仍保持原有结构，在此基础上建立区域数据中心。区域数据中心存储整个区域的流水信息以及全部路段所有路段代理的信息。数据中心定时从各路段中心数据库中抽取流水信息，确保数据的同步。

当稽查人员进行查询时，需要将查询条件发送到应用服务器。应用服务器收到查询请求后，一方面将流水信息查询语句传递给中心数据库，由中心数据库查询后返回查询结果；另一方面将路段代理查询语句传递给中心数据库，然后根据所返回的路段代理信息向路段代理发送图像调取请求。路段代理从对应车道终端调取监控图像并返回。最终应用服务器集合流水信息和图像，组合成统一的页面供稽查人员使用。

另外，基于B/S架构开发的该高速公路联合稽查系统，程序代码运行在服务器（Server）上，用户只需使用浏览器（Browser），即可进行访问和操作，系统更加容易维护和升级。

2.2 功能设计

为了满足稽查工作的实际需求，针对稽查工作的业务流程，该高速公路联合稽查系统设计了以下几个部分的功能：

（1）自动筛选：区域中每天新增的流水记录数量巨大，而特殊事件只是其中的小部分。如果每次稽查时，都需要从全部流水表中查找，无疑是低效的。因此，系统应能在新增流水记录中自动识别出具有特殊事件的部分，并将其转存到特定的数据表中，则能提供查询效率。

（2）特殊事件过滤：稽查员在进行稽查时，不可能逐条流水进行稽查，通常是分工合作，每人负责某几个类型的特殊事件。因此，系统应能根据稽查员的需要，在输入入口车道、出口车道、操作时间、特殊事件等信息后，过滤出符合条件的流水记录以供稽查。

（3）流水比对：在稽查的过程中，稽查员需要将出口流水记录中的信息与入口流水记录中的信息进行对比，观察其是否存在差异，以确定是偶然事件还是疑似事件。因此，系统在响应查询时，应能将相关的出口流水记录和入口流水记录进行关联查询，并在页面中进行对比显示。

（4）图像比对：与流水比对类似，系统应能在响应查询时，自动调取图像并进行对比显示。

（5）三级稽查。三级稽查分为收费站稽查、路段稽查、区域稽查，最终由区域中心形成稽查结论。区域中心的稽查结论为最终裁定。

（6）证据保存：当发现违法逃费行为时，系统应能将流水记录及图像进行转存，以便将来使用，避免因硬盘空间重用导致的信息丢失（特别是收费站保存的图像）。

2.3 模块划分

根据以上分析，该高速公路联合稽查系统划分为6个模块，如图3所示：

图3 系统模块图

其中：

（1）卡动态查询模块包括：按卡号精确查询、按部分卡号模糊查询、按车牌及车型精确查询、按车牌模糊查询。

（2）交易记录查询模块包括：入口记录查询、出口记录查询、粤通卡出口记录查询、标识站记录查询。

（3）特殊事件定位模块包括功能：驶入口特殊事件定位、驶出口特殊事件定位、驶入口绿色通道特殊事件定位、驶入口车种不符特殊事件定位、驶入口车型不符特殊事件定位、驶出口绿色通道特殊事件定位、驶出口车种不符特殊事件定位、驶出口车型不符特殊事件定位。

（4）特殊事件稽查模块包括功能：驶入口特殊事件稽查、驶出口特殊事件稽查、驶入口绿色通道特殊事件稽查、驶入口车种不符特殊事件稽查、驶入口车型不符特殊事件稽查、驶出口绿色通道特殊事件稽查、驶出口车种不符特殊事件稽查、驶出口车型不符特殊事件稽查。

（5）流水比对模块包括功能：入口流水比对、出口流水比对、粤通卡出口流水比对、标识站出口流水比对、入口特殊事件比对、出口特殊事件比对。

（6）数据导出模块包括功能：入口流水导出、出口流水导出、粤通卡出口流水导出、标识站出口流水导出、驶入口特殊事件导出、驶出口特殊事件导出。

2.4 系统实现

在系统的实现上，分为两个部分：数据库实现和代码实现。其中，数据库实现包括了数据库表的设计与实现、存储过程的设计与实现、大数据量查询优化；代码实现包括了输入界面设计与实现、输出界面设计与实现、稽查界面设计与实现、比对界面设计与实现、查询结果导出。

2.4.1 数据库实现

该高速公路联合稽查系统使用微软SQL Server 2008进行数据存储，建立了各个模块所需的数据表。为了加快查询速度，还建立了存放查询结果的临时表。数据表如表1所示：

表1 系统数据表

考虑到流水信息的体量，如果在代码中实现查询操作，将无法达到所需的响应时间。为了满足稽查工作中的实时性要求，该系统采用存储过程来实现具体的查询操作。通过调用SQL Server的内置功能，能够极大地提高查询效率。存储过程如表2所示：

表2 系统存储过程

2.4.2 代码实现

该高速公路联合稽查系统基于.NET平台进行实现，采用了ASP.NET MVC 3框架，使用Visual Studio 2010进行开发，页面上使用了jQuery、jQuery EasyUI实现动态效果。

MVC是Model-View-Control的简称，即模型-视图-控制器。它是一个存在于服务器表达层的模型，它将应用分开，改变应用之间的高度耦合。MVC是在 20 世纪 80 年代发明的一种软件设计模式，至今已被广泛使用[5]。

（1）模型

本系统所用模型通过Entity Framework自动完成数据库-代码的映射，经过映射之后，数据表对应代码中的实体类，存储过程对应代码中的复杂函数和复杂实体类。在后续的编码中可以直接对实体类进行查询、新增、修改、保存、删除，Entity Framework自动完成数据库映射；存储过程经过映射后以复杂函数的形式供代码调用，查询结果以复杂实体类的形式返回，简化了操作。

（2）视图

本系统采用了ASP.Net MVC3新增的Razor视图引擎。Razor提供了流畅的专注于代码的模版方案；编码工作流快速、富有表现力并有趣；语法简练并节省按键次数，同时还提升了代码的可读性。视图包括了与用户进行交互的页面。页面分为 3种，主页面（如 InList.cshtml），明细页面（如GetInListDetail.cshtml），比对页面（如 InListCompare.cshtml）。页面中大量采用了AJAX插件实现动态效果，如EasyUI的Layout、DataGrid、Dialog、Tree 等控件。

（3）控制器

本系统的控制器用 C#进行编写。控制器中的方法根据返回类型不同分为两种：返回页面或返回数据。当调用返回页面的方法时，新页面或者替换旧页面，或者在新窗口中打开。返回数据的页面供AJAX插件使用，用于页面的局部更新。

系统包图如图4所示：

图4 系统包图

图4中，控制器按功能进行组织，负责权限的检查、参数的处理、存储过程的调用、查询结果的封装与返回。模型是使用ADO.NET Entity Framework自动生成的、与数据库对应的模型代码。工具是各个模块共用的辅助工具类，用于完成特定的辅助功能，提高代码的重用性。页面是系统对用户可见的各种动态页面。页面模板是框架性模板，可供其它功能页面调用，提高代码的重用性。脚本是系统所用到的jQuery、jQuery UI、EasyUI等AJAX插件、以及按项目需要所编写的JS代码文件。资源是系统所用到的样式定义文件、图片文件和动画文件。

驶出口特殊事件定位时，用户点击输入界面的“查询”按钮之后，调用控制器中的Query方法，并最终返回查询结果的流程图，如图5所示：

图5 驶出口特殊事件定位流程图

2.5 系统测试

编码完成之后，在调试环境下进行了完整的功能性测试，包括人工测试页面效果、工具测试逻辑流程，最终确保所有设计的功能都正确地被实现。

3 总结

在完成功能性测试之后，系统最终部署到了数据中心，并在实际环境中运行。实际运行环境中，数据中心采集了区域内所有路段6个月的流水数据，入口流水、出口流水、粤通卡出口流水、标识站流水的记录数均在千万级别，特殊事件的记录数也近千万。最终测试结果显示，流水相关的操作均能在1.5秒内完成响应，特殊事件相关的操作均能在5秒内完成响应，达到用户的实际需要。

[1] 李锐,徐俊.逐步完善联网高速公路收费稽查工作[J].中国交通信息产业,2006(04): 50-53.

[2] 曹虹.浅议高速公路收费稽查的违章现状及整治对策[J].财经界(学术版),2012(12): 282-283.

[3] S.K.Singh(著).何玉洁,王晓波,车蕾(译).数据库系统:概念、设计及应用[M].北京:机械工业出版社,2010.

[4] jQuery EasyUI Documentation[K/OL].http://www,jeasyui.com/documentation

[5] Jon Galloway, Phil Haack, Brad Wilson,等(著). 孙远帅(译). ASP.NET MVC 3高级编程[M].北京:清华大学出版社,2012.