高速公路電子不停車收費系統(tǒng)仿真測試實踐

趙　旭，谷博濤，王　焱（交通運輸部科學研究院，北京 100029）

高速公路電子不停車收費系統(tǒng)仿真測試實踐

趙旭，谷博濤，王焱
（交通運輸部科學研究院，北京 100029）

為測試驗證高速公路電子不停車收費系統(tǒng)是否滿足用戶需求，提出了一種新的仿真測試方法和工具。對高速公路電子不停車收費系統(tǒng)運行環(huán)境進行建模，通過交通仿真模擬測試用例場景行為，基于傳感器仿真模型生成測試數(shù)據(jù)，對部署在等效虛擬機環(huán)境上的被測系統(tǒng)實施測試。以某省真實高速公路不停車收費系統(tǒng)作為應(yīng)用案例進行測試，試驗結(jié)果表明，仿真測試有效地驗證了被測高速公路電子不停車收費系統(tǒng)的功能和性能指標，且測試過程無需使用任何傳感器及車輛等設(shè)備，有效降低了測試成本，測試工具操作便捷易用，可實現(xiàn)自動或半自動化測試，提高了測試效率。

交通信息化；軟件測試；建模仿真；高速公路電子不停車收費系統(tǒng)；交通物聯(lián)網(wǎng)；仿真測試工具

第1卷 第1期|2015年2月

0　引言

電子不停車收費系統(tǒng)（Electronic Toll Collec?tion System，簡稱ETC）是利用車輛自動識別技術(shù)（Automatic Vehicle Identification，簡稱AVI）、專用短程通信技術(shù)（Dedicated Short Range Communica?tions，簡稱DSRC）并配合車道控制終端和收費管理中心實現(xiàn)的不停車自動收取道路通行費的交通信息系統(tǒng)[1]。相比于傳統(tǒng)人工收費系統(tǒng)，ETC系統(tǒng)具有緩解停車收費擁堵、降低收費管理成本、提高服務(wù)水平的優(yōu)勢。目前，我國正在大力發(fā)展并推廣高速公路ETC系統(tǒng)，但在應(yīng)用實踐過程中也存在諸如扣費錯誤、無法跨省收費等一系列問題，因此，有必要對高速公路ETC系統(tǒng)進行測試驗證，以確定系統(tǒng)是否與應(yīng)用需求一致，進而保證其上線質(zhì)量。

測試ETC系統(tǒng)，除了要對其硬件設(shè)備，如路側(cè)單元（Road Side Unit，簡稱RSU）、車載單元（On Board Unit，簡稱OBU）、射頻識別單元（Ra?dio Frequency Identification，簡稱RFID）等進行出廠測試[2]、電子兼容性測試[3]、DSRC協(xié)議測試[4]外，更重要的是需要對系統(tǒng)整體進行測試驗證，例如在不同車輛、不同交通環(huán)境下對系統(tǒng)整體進行功能或性能測試。然而，從技術(shù)角度看，ETC系統(tǒng)屬于典型的物聯(lián)網(wǎng)技術(shù)在智能交通系統(tǒng)中的應(yīng)用，它嵌入式、網(wǎng)絡(luò)化、大規(guī)模的技術(shù)特征也給其系統(tǒng)測試帶來了新的困難和挑戰(zhàn)。傳統(tǒng)的系統(tǒng)測試方法常需在實際中使用ETC測試平臺[5-6]，但測試平臺需要購買、部署并安裝支持ETC系統(tǒng)運行的各種硬件設(shè)備和交通車輛，測試成本過高。同時，若在真實的生產(chǎn)環(huán)境下進行測試，可能會給現(xiàn)有運行的ETC系統(tǒng)帶來潛在的安全風險。

為解決上述問題，本文提出一種針對高速公路ETC系統(tǒng)的仿真測試方法，設(shè)計實現(xiàn)了相應(yīng)的仿真測試工具（該測試工具已獲軟件著作權(quán)專利，專利號為2014SR185734），并以某省高速公路ETC系統(tǒng)測試為應(yīng)用案例對仿真測試方法和工具的有效性進行了驗證。

1　高速公路ETC系統(tǒng)仿真測試

1.1高速公路ETC系統(tǒng)簡介

從技術(shù)實現(xiàn)的角度，高速公路ETC系統(tǒng)利用專用短程通信技術(shù)或非接觸式的射頻識別技術(shù)，通過安裝在高速公路出入口收費站上的路側(cè)單元RSU 或RFID讀卡器，自動識別安裝有車載單元OBU或RFID標簽的通行車輛，并自動完成通行扣費、抬桿通車、路徑識別、賬單查詢、收費管理、銀行結(jié)算等功能。目前，我國已制定并發(fā)布了收費公路聯(lián)網(wǎng)電子不停車收費技術(shù)要求標準[7]。下面對高速公路ETC系統(tǒng)進行簡介。

高速公路ETC系統(tǒng)體系結(jié)構(gòu)如圖1所示。

圖1　 高速公路ETC系統(tǒng)體系結(jié)構(gòu)

由圖1可知，高速公路ETC系統(tǒng)是典型的分布式系統(tǒng)，數(shù)據(jù)中心為服務(wù)器端，車輛注冊子系統(tǒng)及收費站/標識站為其客戶端，其中標識站架設(shè)在高速公路高架橋上。收費站車道程序是典型的嵌入式系統(tǒng)，除與路側(cè)單元RSU或RFID讀卡器通過網(wǎng)口或串口連接外，還通過專用的IO板控制車道設(shè)備，如欄桿、雨棚、交通燈等。路側(cè)單元RSU或RFID讀卡器通過專用短程通信或無線射頻與安裝在通行車輛上的車載單元OBU或RFID標簽實現(xiàn)通訊。

1.2高速公路ETC系統(tǒng)運行環(huán)境仿真建模

為實現(xiàn)對高速公路ETC系統(tǒng)的仿真測試，需對其運行環(huán)境仿真建模。ETC系統(tǒng)運行環(huán)境模型包括兩部分：一是交通場景仿真模型；二是傳感器仿真模型。

交通場景仿真模型類似于傳統(tǒng)的微觀交通仿真模型，選擇Groovenet仿真工具[8]來實現(xiàn)。在本次仿真中，首先在該省真實場景OpenStreetMap格式地圖[9]中標記收費站位置，其次設(shè)計并實現(xiàn)交通仿真場景模型文件，例如對仿真車輛從第一個站點（入口收費站）出發(fā)駛向其余不同站點（出口收費站）的設(shè)置，其可視化仿真界面如圖2所示。

圖2　交通仿真運行可視化界面

傳感器仿真模型主要描述被測系統(tǒng)中使用傳感器的數(shù)據(jù)結(jié)構(gòu)和邏輯行為，可通過傳感器建模描述語言SensorML[10]來定義。對于高速公路ETC系統(tǒng)，傳感器設(shè)備包括車載單元OBU或RFID標簽、路側(cè)單元RSU或RFID讀卡器，其仿真模型規(guī)格編輯界面如圖3所示。

圖3　車載和路側(cè)傳感器仿真模型規(guī)格編輯界面

對于車載傳感器仿真模型，試驗中考慮的測試用例包括不同類型的車輛，如普通車、公務(wù)車、凍結(jié)車輛、余額不足車輛等，測試其在通過收費站時的行為是否符合預(yù)期。不同類型車輛對應(yīng)于不同的OBU或RFID標簽號，因此將標簽類型及其編號作為車載傳感器仿真模型的輸入項。行為邏輯和交互接口均通過腳本函數(shù)定義，其中，行為邏輯函數(shù)根據(jù)預(yù)先定義的故障模型將輸入數(shù)據(jù)轉(zhuǎn)換為傳感器輸出數(shù)據(jù)，并根據(jù)測試用例設(shè)置了路側(cè)傳感器接收數(shù)據(jù)不完整的故障模型；交互接口函數(shù)用于交通場景仿真模型識別和傳感器仿真模型調(diào)用。對于路側(cè)傳感器仿真模型，其目的在于為不同編號的收費站程序指定不同的接收數(shù)據(jù)端口號。

2　交通物聯(lián)網(wǎng)仿真測試工具設(shè)計與實現(xiàn)

為便于對高速公路ETC系統(tǒng)進行仿真測試，設(shè)計并實現(xiàn)了仿真測試工具，并將其推廣至針對交通物聯(lián)網(wǎng)系統(tǒng)的軟件測試工具。

從功能角度，仿真測試工具能夠?qū)崿F(xiàn)：①在交通物聯(lián)網(wǎng)系統(tǒng)運行環(huán)境不完整或不可用的情況下依然實可施測試；②可視化顯示系統(tǒng)拓撲結(jié)構(gòu)及其測試運行狀態(tài)和結(jié)果；③在同類系統(tǒng)測試過程中快速復(fù)用傳感器仿真測試樁模塊。這里所謂“運行環(huán)境不完整或不可用的情況”，是指被測的交通物聯(lián)網(wǎng)系統(tǒng)在尚未接入傳感器設(shè)備，或接入的傳感器難以模擬大規(guī)模或極端條件下數(shù)據(jù)輸入的情況。

測試工具支持并更適用于：①模擬正常或異常環(huán)境條件下的軟件功能測試；②交通物聯(lián)網(wǎng)系統(tǒng)多傳感器負載壓力測試；③上述功能和性能測試的回歸測試驗證。

從實現(xiàn)角度，仿真測試工具按模塊可劃分為四個部分，分別是：傳感器仿真模型創(chuàng)建與管理、數(shù)據(jù)采集場景可視化建模與編輯、軟硬件數(shù)據(jù)交互控制、測試執(zhí)行與管理（例如測試執(zhí)行與狀態(tài)監(jiān)測、測試結(jié)果分析與導(dǎo)出等）。系統(tǒng)基本模塊及其相互關(guān)系如下頁圖4所示，其中各模塊的技術(shù)特征如下。

（1）傳感器仿真模型使用自定義裁剪的Sen?sorML語言[10]建模。SensorML是由開放地理組織（OGC）定義的用于描述通用傳感器模型的可擴展標記語言，結(jié)合交通行業(yè)特征和測試需求，實現(xiàn)其中關(guān)于數(shù)據(jù)結(jié)構(gòu)和行為邏輯定義部分的子集。

（2）場景可視化建模與編輯選擇第三方QT 庫[11]編寫。QT是一種支持多種編程語言、跨平臺的應(yīng)用程序開發(fā)框架，常用于GUI界面的開發(fā)，項目主要實現(xiàn)在GUI界面中進行二維模型可視化與編輯的功能。

（3）測試及數(shù)據(jù)交互框架選擇在STAF框架[12]基礎(chǔ)上擴展。STAF框架是一個支持多種編程語言、跨平臺的分布式測試框架，提供遠程通信管理、時間/事件驅(qū)動等多種服務(wù)和功能。

（4）測試腳本選擇Python語言[13]編寫。Python是一種運行在不同平臺的腳本編程語言，具有用戶數(shù)量多、易于掌握、簡潔高效、豐富的第三方庫等優(yōu)點。

圖4　交通物聯(lián)網(wǎng)仿真測試工具模塊及原理示意圖

3　試驗設(shè)計與驗證

3.1試驗設(shè)計

為驗證本文提出的仿真測試方法和工具的有效性，選擇真實的交通物聯(lián)網(wǎng)系統(tǒng)——某省高速公路不停車收費系統(tǒng)作為被測系統(tǒng)。該ETC系統(tǒng)同時支持安裝有國標OBU標簽或無線射頻RFID標簽的車輛通行，可與人工收費系統(tǒng)MTC協(xié)同運行，支持不同類型車輛的靈活收費策略。性能方面，相比人工收費系統(tǒng)平均8s的出票時間，ETC系統(tǒng)可大幅提高車輛通行能力4～6倍，收費站收集所轄車道產(chǎn)生的收費數(shù)據(jù)時間小于0.5s，允許車輛以至少20km/h的速率通行收費站。

試驗主要關(guān)注被測ETC系統(tǒng)整體軟件功能的正確性以及被測系統(tǒng)運行環(huán)境性能指標。具體使用交通物聯(lián)網(wǎng)仿真測試工具執(zhí)行測試的試驗步驟有以下三個。

步驟1：測試準備。為避免測試影響生產(chǎn)環(huán)境安全，將被測系統(tǒng)軟件部署在相同配置的虛擬機上，并設(shè)置相關(guān)配置文件。試驗中，在服務(wù)器虛擬環(huán)境中分別部署1套數(shù)據(jù)中心程序、1套入口收費站程序、3套出口收費站程序。

步驟2：測試設(shè)計。包括設(shè)計高速公路ETC系統(tǒng)交通場景仿真模型、車載和路側(cè)傳感器仿真模型以及測試腳本。

步驟3：測試執(zhí)行。運行交通物聯(lián)網(wǎng)仿真測試工具，輸入設(shè)計完成的交通場景仿真模型、傳感器仿真模型、測試預(yù)言和測試腳本。設(shè)置交通仿真運行參數(shù)和測試數(shù)據(jù)生成策略，執(zhí)行仿真測試自動生成仿真測試數(shù)據(jù)。執(zhí)行測試腳本，將仿真測試數(shù)據(jù)輸入被測系統(tǒng)，并收集其輸出信息和狀態(tài)信息，與測試預(yù)言對比生成測試結(jié)果。

3.2結(jié)果分析

測試執(zhí)行過程中，交通物聯(lián)網(wǎng)仿真測試工具的主界面如圖5所示：左上方的“測試執(zhí)行管理”區(qū)域?qū)崿F(xiàn)測試輸入管理和測試執(zhí)行控制功能；右上方的“仿真測試控制”區(qū)域?qū)崿F(xiàn)了交通物聯(lián)網(wǎng)仿真和測試設(shè)置相關(guān)功能；左下方的“測試執(zhí)行過程”區(qū)域用于輸出測試中間過程和結(jié)果信息；右下方的“被測系統(tǒng)狀態(tài)”區(qū)域?qū)⑤敵霰粶y系統(tǒng)的性能數(shù)據(jù)，包括CPU占用率和內(nèi)存占用率。

圖5　交通物聯(lián)網(wǎng)仿真測試工具運行主界面

在輸入仿真模型并完成參數(shù)設(shè)置后，點擊仿真測試控制“運行”按鈕，彈出交通仿真可視化界面，如圖2所示。按照設(shè)定的場景仿真，三臺仿真車輛從起始站點出發(fā)駛向另外三個收費站。仿真車輛在經(jīng)過仿真收費站時，產(chǎn)生收費交易通行的仿真事件，仿真事件中包含根據(jù)測試策略生成的仿真測試數(shù)據(jù)。為避免仿真運行時間過長，可通過仿真時間變速因子加快生成仿真測試數(shù)據(jù)。

在執(zhí)行測試腳本后，測試腳本根據(jù)收費交易通行仿真事件將仿真測試數(shù)據(jù)按照約定的接口形式自動發(fā)送至被測系統(tǒng)，即高速公路ETC系統(tǒng)的入口、出口收費站程序。通過分布式測試框架STAF收集被測系統(tǒng)輸出和被測系統(tǒng)狀態(tài)，其中，被測系統(tǒng)的輸出數(shù)據(jù)用于與規(guī)格說明測試預(yù)言對比并得出測試結(jié)論，被測系統(tǒng)狀態(tài)信息反映了被測系統(tǒng)執(zhí)行測試過程中的運行情況。最終，試驗設(shè)計的測試用例執(zhí)行結(jié)果如表1所示。

表1　試驗設(shè)計測試用例執(zhí)行結(jié)果

表1　（續(xù)）

由表1測試結(jié)果可知，試驗設(shè)計的7條用例有兩條未能通過。通過進一步分析得知，被測的高速公路ETC系統(tǒng)未能支持OBU類型標簽車輛通行的原因是其客戶端版本未及時更新，替換最新版本客戶端程序后該用例通過。對于最后一條用例，通過故障模型設(shè)置傳感器接收不完整數(shù)據(jù)后，收費站仍有一定幾率允許通車的原因是收費站程序并沒有對數(shù)據(jù)所有字段（如時間、LRC碼字段）校驗。當數(shù)據(jù)不完整故障出現(xiàn)在非報頭、標簽等其他字段時，程序允許該車輛通過收費站，為此需要進一步完善修正其收費站程序的數(shù)據(jù)校驗功能。

通過交通物聯(lián)網(wǎng)仿真測試工具可進一步改變交通行為邏輯，進而實現(xiàn)對其他交通場景情況的測試。通過仿真測試發(fā)現(xiàn)，被測的高速公路ETC系統(tǒng)無法對同一車輛重復(fù)通過同一收費站、同一車輛在很短時間范圍內(nèi)通過兩個相距較遠收費站的情況識別并報警。

此外，仿真測試工具可監(jiān)測被測系統(tǒng)運行環(huán)境的性能指標，如圖6所示。由測試執(zhí)行過程中的監(jiān)測結(jié)果可知，在試驗設(shè)定的仿真測試場景下，數(shù)據(jù)中心服務(wù)器運行環(huán)境的內(nèi)存占用率一直超過60%以上，分析原因是數(shù)據(jù)中心在部署Oracle數(shù)據(jù)庫后3Gb內(nèi)存配置略顯不足，建議提高數(shù)據(jù)中心服務(wù)器的內(nèi)存配置。其余客戶端運行環(huán)境的CPU和內(nèi)存占用率均在合理范圍內(nèi)。

圖6　 被測系統(tǒng)運行環(huán)境CPU和內(nèi)存占用率

除了可有效發(fā)現(xiàn)被測的高速公路ETC系統(tǒng)的上述系統(tǒng)級軟件缺陷外，在整個仿真測試過程中，測試人員無需部署任何硬件（如車載或路側(cè)單元）、交通工具，有效降低了測試人力、物力的成本投入。仿真測試也無需在真實環(huán)境下執(zhí)行，避免了測試影響生產(chǎn)環(huán)境安全的責任和風險。交通物聯(lián)網(wǎng)仿真測試工具提供了便捷統(tǒng)一的操作界面，測試人員只需關(guān)注被測系統(tǒng)的仿真環(huán)境建模、測試用例設(shè)計和腳本實現(xiàn)等工作，即可自動或半自動化地完成測試工作，更便于診斷系統(tǒng)故障，提高了系統(tǒng)測試效率。

4　結(jié)語

本文提出了一種針對高速公路ETC系統(tǒng)仿真測試的方法，在此基礎(chǔ)上實現(xiàn)了交通物聯(lián)網(wǎng)仿真測試工具，并以真實被測系統(tǒng)——某省高速公路ETC系統(tǒng)為應(yīng)用案例，試驗驗證了仿真測試在降低測試成本、保障測試過程中生產(chǎn)環(huán)境安全、發(fā)現(xiàn)被測系統(tǒng)軟件缺陷等方面的優(yōu)勢。文中所提出的方法和工具在交通行業(yè)信息化質(zhì)量保障工作中具有推廣的實用價值。

[1]劉志偉，程琳.不停車收費系統(tǒng)（ETC）的概況研究[J].科技創(chuàng)新導(dǎo)報，2008（2）：11.

[2] 劉國強.OBU出廠前測試方法及流程簡析[J].中國交通信息化，2012（8）：70-71.

[3]張北海.聯(lián)網(wǎng)環(huán)境下電子收費系統(tǒng)的兼容性[J].公路交通科技，2003，20（4）：109-113.

[4]沈進，張衛(wèi)，熊鵬.OBU設(shè)備DSRC協(xié)議一致性測試技術(shù)[J].計算機工程，2009，35（10）：248-250.

[5]張茗紅.電子不停車收費系統(tǒng)設(shè)備控制研究[J].中國防偽報道，2009（3）：48-50.

[6] 潘勇，王榮.國標體系下ETC區(qū)域聯(lián)網(wǎng)測試方案探討[J].中國交通信息產(chǎn)業(yè)，2009（11）：108-109.

[7]交通運輸部公路科學研究院.收費公路聯(lián)網(wǎng)電子不停車收費技術(shù)要求[M].北京：人民交通出版社，2011.

[8]Mangharam R,Weller D S,Rajkumar R,et al.GrooveNet：A Hybrid Simulator for Vehicle-to-Vehicle Networks[C]// Second International Workshop on Vehicle-to-Vehicle Com?munications.San Jose,USA:IEEE,2006:1-8.

[9]Haklay M,Weber P.OpenStreetMap： User-Generated Street Maps[J].Pervasive Computing,IEEE,2008,7(4):12-18.

[10]開放地理空間實驗室.OGC與OGC標準[EB/OL].(2014-05-11)[2014-11-28].http://lab.osgeo.cn/7139.html.

[11]Blanchette Jasmin,Summerfield Mark.C++GUI Qt 4編程[M].閆鋒欣，曾泉人，張志強，等，譯.北京：電子工業(yè)出版社，2013.

[12]Rankin C.The Software Testing Automation Framework[J]. IBM Systems Journal,2002,41(1):126-139.

[13]Turnquist G L.Python Testing Cookbook[M].Birmingham, UK:Packt Publishing,2011.

Simulation Testing for Expressway Electronic Toll Collection System

ZHAO Xu,GU Bo-tao,WANG Yan
(China Academy of Transportation Sciences,Beijing 100029,China)

In order to test whether the expressway ETC(Electronic Toll Collection)system meets the us?ers′requirement,a new simulation testing method and tool was proposed.The ETC system runtime envi?ronment was first modeled to simulate traffic behaviors and generate test data from simulated sensors. Then the ETC system was tested on the equivalent virtualization environment.Experiment on the realworld ETC system shows that the simulation testing method can effectively test the ETC system without deploying any devices.The simulation testing tool can be easily used to support test automation,and can reduce the cost and improve the efficiency of test.

traffic informatization;software test;simulation of environment model;expressway ETC (Electronic Toll Collection);internet of things;simulation testing tool

U495

B

2095-9931（2015）01-0066-06

10.16503/j.cnki.2095-9931.2015.01.012

2014-12-01