曾 勇， 徐延軍，2

（1.中海網絡科技股份有限公司，上海200135；2.同濟大學，上海200092）

0 前 言

高速公路收費系統作為回收高速公路建設投資的主要工具，一直被業(yè)主高度關注。其中，車道軟件作為系統交易的數據源，是高速公路聯網收費系統的基礎。現階段，車道軟件主要面向收費流程的自動化，隨著新技術、新功能、新需求及新的收費模式的不斷涌現，其局限性越來越明顯。

1.車道設備廠家、品牌眾多，硬件設備升級換代快，業(yè)主因管理提升不斷調整需求，各省之間業(yè)務流程差別巨大等因素，導致現有車道軟件大都通過修改核心代碼進行定制開發(fā)，版本更新頻繁，可擴展性、可維護性、兼容性和穩(wěn)定性都很差。

2.隨著新功能、新技術的不斷應用，收費流程日益復雜，需要進一步整合優(yōu)化。

3.不停車電子收費系統（Electr onic Toll Collection，ETC）、自助刷發(fā)卡、便攜機等新的收費模式不斷出現，車道軟件整合困難，造成多套軟件并行，維護成本極高。

為滿足高速公路運營管理不斷發(fā)展的需求，基于流程驅動的思想，設計并開發(fā)一套擴展靈活、穩(wěn)定性強、兼容性好、易維護的車道平臺軟件，顯得尤為迫切。

1 需求分析

目前，國內高速公路收費模式主要包括公路半自動車道收費系統（Manual Toll Collection，MTC）和ETC兩種。

1.MTC出入口車道軟件需要對各類車輛進行入口發(fā)卡、出口收費處理，同時需要接收各類收費參數、上傳收費流水。其軟件功能需求見圖1。

圖1 MTC出入口車道軟件功能需求圖

2.ETC出入口車道軟件主要用于滿足電子不停車收費的要求，即通過RSU和OBU之間的通信來代替MTC車道入口發(fā)卡和出口收卡的過程。車輛可在車道快速通過，實現入口自動刷卡、出口自動收費。其軟件功能需求見圖2。

圖2 ETC出入口車道軟件功能需求圖

2 架構設計

2.1 總體目標

1）擴展靈活：在新技術出現時，允許導入新技術，從而對現有系統進行功能和性能上的擴展。軟件必須能夠在用戶的使用率、用戶的數目增加很快的情況下保持合理的性能。

2）基于軟件平臺模式的定制開發(fā)：在軟件平臺的基礎上進行業(yè)務流程的定制開發(fā)，新的業(yè)務流程模塊要能通過插件方式注冊和應用于軟件平臺，降低軟件設計和開發(fā)的技術難度，縮短項目開發(fā)周期，降低系統錯誤率，提升軟件質量，維護、升級方便。

3）分層設計：分散關注、松散耦合、邏輯復用、標準定義。

4）穩(wěn)定可靠：在軟件發(fā)生故障時，把故障造成的危害限制在模塊內；建立進程運行狀態(tài)監(jiān)控機制，可以及時發(fā)現程序異常，以使系統恢復到正常的工作狀態(tài)。

5）良好的用戶體驗：采用WPF進行全新的界面開發(fā)，分離開發(fā)與設計人員的工作，利用多媒體交互用戶圖形界面，增強展示效果。

2.2 邏輯架構設計

基于車道軟件自身的特點，綜合傳統的“客戶端—服務器”以及3層架構（UI－BLL－DAL，表示層－邏輯層－數據層）2種軟件設計模式，車道軟件架構采用5層架構（第1層為表示層、第2層為業(yè)務邏輯層、第3層為數據層、第4層為設備接口層、第5層為數據傳輸層）。該軟件邏輯架構見圖3。

2.2.1 表示層

系統的UI部分負責用戶與整個系統的交互。在該平臺軟件中，UI采用WPF繪制，實現了UI邏輯的真正分離，為用戶創(chuàng)建更好的視覺效果。

2.2.2 業(yè)務邏輯層

業(yè)務邏輯層是系統架構中最核心的部分，與系統所對應的領域邏輯有著密切的關系。其關注的重點主要集中在業(yè)務流程的實現、業(yè)務規(guī)則的制定等與業(yè)務需求有關的系統設計上。該邏輯層處于分層架構的中間位置，在數據交換中發(fā)揮承上啟下的作用。對于數據層而言，它是調用者；對于表示層而言，卻是被調用者。

圖3 車道平臺邏輯架構圖

與大型的業(yè)務系統相比較，本平臺軟件的業(yè)務并不復雜，但包含了諸多的交易流程、合法性判斷流程、文件處理流程以及其他流程，比如ETC入口交易流程和出口交易流程，具體流程見圖4、圖5。

圖4 ETC入口交易流程圖

圖5 ETC出口交易流程圖

通過對比ETC入口交易、出口交易流程可知，二者相似度很高。該業(yè)務邏輯層從平臺軟件各流程的實際特點出發(fā)，采用了流程驅動的方式對各流程進行處理，充分考慮了流程自由組合的靈活度，使其在新增流程或現有流程發(fā)生變化時能靈活擴展；同時，為增加代碼的復用度，將流程中的各步驟封裝成了一個個獨立的狀態(tài)，多個狀態(tài)可以自由組合成一個新的流程，同時也可以靈活地對某個流程中的步驟進行增加或裁剪。

流程驅動的方式在該層中具體采用狀態(tài)模式予以實現，封裝了對各種狀態(tài)變化的處理。狀態(tài)模式的具體實現見圖6。

圖6 業(yè)務邏輯層狀態(tài)模式結構圖

2.2.3 數據層

數據層負責數據庫的訪問，即實現對數據表的查詢、插入、更新以及刪除操作。在系統中，數據層通過采用開源ORM框架NHiber nate來實現。采用NHibemate具有以下優(yōu)點：

（1）由于ORM可以自動對Entity對象和數據庫中的Table進行字段與屬性的映射，所以開發(fā)人員無需再編寫一個帶有大量SQL語句的龐大的數據層，加快了程序員開發(fā)系統的速度；

（2）采用ORM框架能夠很方便地進行多種數據庫的轉換和遷移，減少了代碼維護工作量和出錯的幾率；

（3）NHibemate通過將數據表中的數據映射到對象中、以對象作為傳輸媒介，能更好地在各層傳輸數據。

2.2.4 設備接口層

設備接口層利用簡單工廠設計模式和反射機制，采用“面向接口編程”的思想，使得每種類型的設備都會抽象出來接口，脫離了與具體設備的依賴，利于具體設備的遷移。同時，在每種類型的設備模塊中，都有一個工廠類來負責具體設備對象的創(chuàng)建，便于業(yè)務邏輯的訪問。其結構圖見圖7。

2.2.5 數據傳輸層

數據傳輸層在整個平臺中起著上傳下達的作用，將車道平臺產生的流水、圖片以及特殊事件等數據根據通信協議以TCP的方式傳輸到上級中心；同時，將配置參數等數據從上級中心根據通信協議以TCP的方式下載到本地。

圖7 設備接口層簡單工廠模式結構圖

3 系統實現

平臺軟件基于.Netfra mewor k4.0進行開發(fā)，車道類型、業(yè)務流程都可以通過配置實現，具有靈活組合、易于擴展、松散耦合等優(yōu)點。

MTC出口車道軟件是平臺軟件的一個主要子系統，這里以MTC出口車道軟件為例來闡述具體實現。

3.1 抽象類的定義與實現

3.2 具體狀態(tài)類的實現

抽象類定義完成后，通過創(chuàng)建不同的具體狀態(tài)類來繼承該抽象類（見圖8）。

接下來就可以實現對具體狀態(tài)的調用，核心代碼為：

／／創(chuàng)建MTC出口刷卡狀態(tài)對象并等待刷通行卡

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 具體狀態(tài)派生類實現圖

圖9 MTC收費主界面

4 結 語

針對面向收費流程自動化的車道軟件在新技術、新功能、新需求及新的收費模式不斷涌現的情況下存在的局限性，提出了一種基于流程驅動的高速公路聯網收費車道平臺架構設計，并在.Netframewor k4.0平臺下進行了研發(fā)。研究表明，該平臺具有松散耦合、擴展靈活、不同類型車道軟件共享平臺資源、易維護等諸多優(yōu)勢。目前，該平臺已成功試用于寧夏高速公路電子不停車收費系統，效果良好。今后將根據業(yè)務特點不斷優(yōu)化平臺結構，使系統性能更加完善、應用更加廣泛。

［1］ 周家才，李維勛，吳映輝.不停車電子收費系統在高速公路收費中的應用［J］.科技廣場，2009（1）：165－166.

［2］ 鄭穎.高速公路車道收費軟件的設計與實現［D］.西安：西安電子科技大學，2010.

［3］ 周楊.高速公路收費系統MTC車道軟件設計與實現［D］.西安：西安電子科技大學，2012.

［4］ 溫昱.軟件架構設計［M］.北京：電子工業(yè)出版社，2007.

［5］ （美）George Fairbanks.恰如其分的軟件架構［M］.武漢：華中科技出版社，2013.

［6］ （美）弗里曼 .Head First設計模式［M］.北京：中國電力出版社，2007.

［7］ 程杰.大話設計模式［M］.北京：清華大學出版社，2007.

［8］ 鄧建波.公路車道收費軟件的設計和開發(fā)［D］.成都：電子科技大學，2005.

［9］ 王勝華.高速公路電子不停車收費系統的分析與設計［D］.昆明：云南大學，2012.

［10］ 徐延軍，唐又林.構件技術在高速公路車道軟件中的應用［J］.上海船舶運輸科學研究所學報，2009，32（1）：43－49.