流程驱动型高速公路联网收费车道平台架构设计

曾 勇， 徐延军，2

（1.中海网络科技股份有限公司，上海200135；2.同济大学，上海200092）

0 前 言

高速公路收费系统作为回收高速公路建设投资的主要工具，一直被业主高度关注。其中，车道软件作为系统交易的数据源，是高速公路联网收费系统的基础。现阶段，车道软件主要面向收费流程的自动化，随着新技术、新功能、新需求及新的收费模式的不断涌现，其局限性越来越明显。

1.车道设备厂家、品牌众多，硬件设备升级换代快，业主因管理提升不断调整需求，各省之间业务流程差别巨大等因素，导致现有车道软件大都通过修改核心代码进行定制开发，版本更新频繁，可扩展性、可维护性、兼容性和稳定性都很差。

2.随着新功能、新技术的不断应用，收费流程日益复杂，需要进一步整合优化。

3.不停车电子收费系统（Electr onic Toll Collection，ETC）、自助刷发卡、便携机等新的收费模式不断出现，车道软件整合困难，造成多套软件并行，维护成本极高。

为满足高速公路运营管理不断发展的需求，基于流程驱动的思想，设计并开发一套扩展灵活、稳定性强、兼容性好、易维护的车道平台软件，显得尤为迫切。

1 需求分析

目前，国内高速公路收费模式主要包括公路半自动车道收费系统（Manual Toll Collection，MTC）和ETC两种。

1.MTC出入口车道软件需要对各类车辆进行入口发卡、出口收费处理，同时需要接收各类收费参数、上传收费流水。其软件功能需求见图1。

图1 MTC出入口车道软件功能需求图

2.ETC出入口车道软件主要用于满足电子不停车收费的要求，即通过RSU和OBU之间的通信来代替MTC车道入口发卡和出口收卡的过程。车辆可在车道快速通过，实现入口自动刷卡、出口自动收费。其软件功能需求见图2。

图2 ETC出入口车道软件功能需求图

2 架构设计

2.1 总体目标

1）扩展灵活：在新技术出现时，允许导入新技术，从而对现有系统进行功能和性能上的扩展。软件必须能够在用户的使用率、用户的数目增加很快的情况下保持合理的性能。

2）基于软件平台模式的定制开发：在软件平台的基础上进行业务流程的定制开发，新的业务流程模块要能通过插件方式注册和应用于软件平台，降低软件设计和开发的技术难度，缩短项目开发周期，降低系统错误率，提升软件质量，维护、升级方便。

3）分层设计：分散关注、松散耦合、逻辑复用、标准定义。

4）稳定可靠：在软件发生故障时，把故障造成的危害限制在模块内；建立进程运行状态监控机制，可以及时发现程序异常，以使系统恢复到正常的工作状态。

5）良好的用户体验：采用WPF进行全新的界面开发，分离开发与设计人员的工作，利用多媒体交互用户图形界面，增强展示效果。

2.2 逻辑架构设计

基于车道软件自身的特点，综合传统的“客户端—服务器”以及3层架构（UI－BLL－DAL，表示层－逻辑层－数据层）2种软件设计模式，车道软件架构采用5层架构（第1层为表示层、第2层为业务逻辑层、第3层为数据层、第4层为设备接口层、第5层为数据传输层）。该软件逻辑架构见图3。

2.2.1 表示层

系统的UI部分负责用户与整个系统的交互。在该平台软件中，UI采用WPF绘制，实现了UI逻辑的真正分离，为用户创建更好的视觉效果。

2.2.2 业务逻辑层

业务逻辑层是系统架构中最核心的部分，与系统所对应的领域逻辑有着密切的关系。其关注的重点主要集中在业务流程的实现、业务规则的制定等与业务需求有关的系统设计上。该逻辑层处于分层架构的中间位置，在数据交换中发挥承上启下的作用。对于数据层而言，它是调用者；对于表示层而言，却是被调用者。

图3 车道平台逻辑架构图

与大型的业务系统相比较，本平台软件的业务并不复杂，但包含了诸多的交易流程、合法性判断流程、文件处理流程以及其他流程，比如ETC入口交易流程和出口交易流程，具体流程见图4、图5。

图4 ETC入口交易流程图

图5 ETC出口交易流程图

通过对比ETC入口交易、出口交易流程可知，二者相似度很高。该业务逻辑层从平台软件各流程的实际特点出发，采用了流程驱动的方式对各流程进行处理，充分考虑了流程自由组合的灵活度，使其在新增流程或现有流程发生变化时能灵活扩展；同时，为增加代码的复用度，将流程中的各步骤封装成了一个个独立的状态，多个状态可以自由组合成一个新的流程，同时也可以灵活地对某个流程中的步骤进行增加或裁剪。

流程驱动的方式在该层中具体采用状态模式予以实现，封装了对各种状态变化的处理。状态模式的具体实现见图6。

图6 业务逻辑层状态模式结构图

2.2.3 数据层

数据层负责数据库的访问，即实现对数据表的查询、插入、更新以及删除操作。在系统中，数据层通过采用开源ORM框架NHiber nate来实现。采用NHibemate具有以下优点：

（1）由于ORM可以自动对Entity对象和数据库中的Table进行字段与属性的映射，所以开发人员无需再编写一个带有大量SQL语句的庞大的数据层，加快了程序员开发系统的速度；

（2）采用ORM框架能够很方便地进行多种数据库的转换和迁移，减少了代码维护工作量和出错的几率；

（3）NHibemate通过将数据表中的数据映射到对象中、以对象作为传输媒介，能更好地在各层传输数据。

2.2.4 设备接口层

设备接口层利用简单工厂设计模式和反射机制，采用“面向接口编程”的思想，使得每种类型的设备都会抽象出来接口，脱离了与具体设备的依赖，利于具体设备的迁移。同时，在每种类型的设备模块中，都有一个工厂类来负责具体设备对象的创建，便于业务逻辑的访问。其结构图见图7。

2.2.5 数据传输层

数据传输层在整个平台中起着上传下达的作用，将车道平台产生的流水、图片以及特殊事件等数据根据通信协议以TCP的方式传输到上级中心；同时，将配置参数等数据从上级中心根据通信协议以TCP的方式下载到本地。

图7 设备接口层简单工厂模式结构图

3 系统实现

平台软件基于.Netfra mewor k4.0进行开发，车道类型、业务流程都可以通过配置实现，具有灵活组合、易于扩展、松散耦合等优点。

MTC出口车道软件是平台软件的一个主要子系统，这里以MTC出口车道软件为例来阐述具体实现。

3.1 抽象类的定义与实现

3.2 具体状态类的实现

抽象类定义完成后，通过创建不同的具体状态类来继承该抽象类（见图8）。

接下来就可以实现对具体状态的调用，核心代码为：

／／创建MTC出口刷卡状态对象并等待刷通行卡

Lane Context.State＝ new Exit Swipe Car d State（LaneContext）；

将App.config配置文件中的Lane Type项配置为MTC出口车道软件，具体配置为：

＜add key ＝"Lane Type"val ue＝"2"／＞＜！－－1－MTC入口；2－MTC出口；3－ETC入口；4－ETC出口－－＞

启动平台软件，登录系统后，其主界面见图9。

图8 具体状态派生类实现图

图9 MTC收费主界面

4 结 语

针对面向收费流程自动化的车道软件在新技术、新功能、新需求及新的收费模式不断涌现的情况下存在的局限性，提出了一种基于流程驱动的高速公路联网收费车道平台架构设计，并在.Netframewor k4.0平台下进行了研发。研究表明，该平台具有松散耦合、扩展灵活、不同类型车道软件共享平台资源、易维护等诸多优势。目前，该平台已成功试用于宁夏高速公路电子不停车收费系统，效果良好。今后将根据业务特点不断优化平台结构，使系统性能更加完善、应用更加广泛。

［1］ 周家才，李维勋，吴映辉.不停车电子收费系统在高速公路收费中的应用［J］.科技广场，2009（1）：165－166.

［2］ 郑颖.高速公路车道收费软件的设计与实现［D］.西安：西安电子科技大学，2010.

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

［4］ 温昱.软件架构设计［M］.北京：电子工业出版社，2007.

［5］ （美）George Fairbanks.恰如其分的软件架构［M］.武汉：华中科技出版社，2013.

［6］ （美）弗里曼 .Head First设计模式［M］.北京：中国电力出版社，2007.

［7］ 程杰.大话设计模式［M］.北京：清华大学出版社，2007.

［8］ 邓建波.公路车道收费软件的设计和开发［D］.成都：电子科技大学，2005.

［9］ 王胜华.高速公路电子不停车收费系统的分析与设计［D］.昆明：云南大学，2012.

［10］ 徐延军，唐又林.构件技术在高速公路车道软件中的应用［J］.上海船舶运输科学研究所学报，2009，32（1）：43－49.